Hi,
I've been using your service for near a week now and I'm very happy with the way it's working out!
But I've a suggestion, hence my posting
The logs are good, but I still find it quite difficult to match the incoming and outgoing of mail. Is there a way of clearly matching an incoming message with an outgoing message?
I'm not quite sure how it can be done, maybe an ID tag for each message, but the best I can see at the moment in matching the time.
Is this possible?
Thanks and keep up the great work!
Logs
Moderator: Moderators
-
- Site Admin
- Posts: 598
- Joined: Wed Nov 17, 2004 10:05 pm
- Location: Nevada
- Contact:
We filter a little differently than everyone else, which makes solving the problem not a cut and dry one. The filtering all takes place in the SMTP session phase, before the queue. While the filter is doing its job the message is effectively anonymous, as it may not be accepted at all. The only identifiers available during an SMTP session are: IP address, recipient address, HELO name, and sender address.
The logs make it to the right account because we know the recipient domain name, but that's all we have to tie them together. We might be able to group the log entries generated by the mail filter, or add a tracking number to the headers that can be associated to other filters (like the content filter, which happens after the basic filter).
It's something I've been thinking about for a while, but I've been working on other stuff since it's mostly a display issue. The log display will eventually be cleaned up to make correlating messages easier.
The logs make it to the right account because we know the recipient domain name, but that's all we have to tie them together. We might be able to group the log entries generated by the mail filter, or add a tracking number to the headers that can be associated to other filters (like the content filter, which happens after the basic filter).
It's something I've been thinking about for a while, but I've been working on other stuff since it's mostly a display issue. The log display will eventually be cleaned up to make correlating messages easier.
Technical Support support@rollernet.us
Roller Network LLC
Roller Network LLC
Hi Glendale2x,
Do you have any idea when you plan to look at/change the logs?
That's good news that it'll eventually be looked at. I really like the whole system and it appears to work well, it's just I find it hard to work with the logs due to the separation and not really being able to compare one against the other.glendale2x wrote:It's something I've been thinking about for a while, but I've been working on other stuff since it's mostly a display issue. The log display will eventually be cleaned up to make correlating messages easier.
Do you have any idea when you plan to look at/change the logs?
-
- Site Admin
- Posts: 598
- Joined: Wed Nov 17, 2004 10:05 pm
- Location: Nevada
- Contact:
I'm still trying to think of a way to tie a single message together in the logs; the problem really boils down to the filtering all happening before the queue inline with the SMTP session, at which point it's not actually a message. I can easily group outbound messages, since they have a queue number, it's the inbound entries that don't have any unique identifying information.
Technical Support support@rollernet.us
Roller Network LLC
Roller Network LLC
-
- Site Admin
- Posts: 598
- Joined: Wed Nov 17, 2004 10:05 pm
- Location: Nevada
- Contact:
All the (non-content) filters have is what happens during the SMTP session, which is:
IP address, HELO or EHLO, MAIL FROM, and RCPT TO
Which is all that is needed for non-content based filtering. We don't know what the content (DATA) is, and might not even care, since it could be rejected. The rejection usually happens after each RCPT TO. For example, to check against a DNSBL, all we need is the IP address and your domain from the RCPT TO command.
We can generate a unique ID on a per-filter process instance, but there's no garuantee that it would only be related to a single recipient domain.
IP address, HELO or EHLO, MAIL FROM, and RCPT TO
Which is all that is needed for non-content based filtering. We don't know what the content (DATA) is, and might not even care, since it could be rejected. The rejection usually happens after each RCPT TO. For example, to check against a DNSBL, all we need is the IP address and your domain from the RCPT TO command.
We can generate a unique ID on a per-filter process instance, but there's no garuantee that it would only be related to a single recipient domain.
Technical Support support@rollernet.us
Roller Network LLC
Roller Network LLC
-
- Site Admin
- Posts: 598
- Joined: Wed Nov 17, 2004 10:05 pm
- Location: Nevada
- Contact:
We've added some additional logging information, including the message queue ID. The full list of changes is here:
http://forums.rollernet.us/viewtopic.php?t=312
http://forums.rollernet.us/viewtopic.php?t=312
Technical Support support@rollernet.us
Roller Network LLC
Roller Network LLC