I have a question about the way you handle "550 - Recipient not here" errors. It appears that after you receive this kind of error from the SMTP server, you abort the email and then try to send an error email back to the sender.

However, if the email has multiple recipients and only one is bad, the message is not getting sent to the good recipients.

When I look at the communication between my outlook client and my SMTP server, the way it handles this situation is that Outlook receives replies for each recipient, some 250 - sender ok, and a 550 - Recipient not here, but it still continues on to the DATA section and delivers the message.

When SpamFilter forwards this same message to my SMTP server, after it receives even a single "550 - Recipient not here", it just drops the connection. As a matter of fact, it doesn't even appear to send a "QUIT" message; it just kind of leaves the SMTP server hanging (though it appears to handle this by timing out, I assume).

My suggestion would be to continue processing and sending the email even if one of these 550 errors is received. You could store each error and make note of them in the error message.

One other suggestion would be to simply forward each 550 error back to the sending SMTP server as they happen and let it handle them. Then you won't even have to worry about sending out the error email. My Outlook client sends me a nice message whenever it encounters these types of errors while sending a message; and this cuts down on overhead because it does not require sending out a second message.

Actually this behavior was by design. We thought that if spam email made it past SpamFilter, we could further help catch it if it had bad recipients. If an email has several recipients, and one of them causes a 550 invalid recipient from the destination server, odd are that it's an invalid email anyways, so we are rejecting the whole thing.

This was solely our decision, and it may be wrong. We are catching quite some spam this way, but the matter is open for discussion if this behavior is not liked.

As far as passing on the error to the sending SMTP server, that can't be done. Unlike other proxy's which process everything in memory, we actually receive the full message and cache it on disk. Once it's received and the remote server disconnects, we pass it on to the dest server. This too was by design as to have a copy of the messages in the queu in case the server crashes or any other foulup that can't be foreseen happen.

Roberto, I'm a bit concerned about the rejection of an entire message if a single recipient bounces with a 550.

Here's the scenario I'm concerned about. A message from a legitimate outside source is sent to ten recipients on our mail system, but the sender makes a simple keying mistake when entering the mail address of just one recipient ("jmerideth" instead of "jmeredith"). The sender receives a 550 from SpamFilter indicating that jmerideth is not a valid recipient. The sender sees her mistake, corrects the address, and resends the message to this ONE user only (since this is the ONLY address that the server indicated a problem with).

In the end, "jmeredith" receives the message, but the other nine original recipients do not receive it... because the server did not indicate any kind of problem with these recipients, and the sender did not wish to send a redundant message to the other recipients who had already (supposedly) received it.

When an email client sends a msg to multiple CCs, the outgoing smtp server usually does one of two things to deliver that email.

It can (1) connect to the recipient's smtp server and issue multiple RCPT TO commands in the same session, or (2) make individual separate connections, each one issuing a single RCPT TO command. (don't forget that the CC headers in an email msg is simply a header in the email message itself listing all the CCs...).

In case #1, a failure on a single recipient will cause the entire msg to be rejected. In case #2, only the incorrect recipient will be discarded.

We understand your concerns. While this behavior is by design, it can be undesirable. We'll then work to make this user-selectable. It will take some time to add it in as it will require some major changes in code.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum