Not a big deal, since the sender would have received an NDR when we quarantined anyway, but I thought I'd pass it along.

 

As for the greylisting server, we got the client to turn that off. The server was a SmarterMail box, and it seems to greylist based on sender email address, not IP. That's a bizarre way of doing things, but it explains why the 451 came after the Rcpt To.

That scenario is indeed a bit unusual. With the new builds, SpamFilter places the sender "on hold" while SpamFilter tries to make sure the destination SMTP server accepts the recipient. SpamFilter actually issues an RCPT TO command to your destination SMTP server, and if the email address specified is accepted, then everything proceeds normally. If your SMTP server rejects the recipient, then SpamFilter issues a 550 SMTP error code back to the sender to notify them of the delivery problem. If your destination SMTP server is offline, SpamFilter won't be able to even connect to the server to send the RCPT TO command to begin with, so in this case the email will be accepted from the sender (assuming it passes all filtering rules), and is placed in a queue for later delivery whenever your SMTP server is back online.

Back to this specific case now however. Your customer's SMTP server implemented greylisting, but it did not reply with a 451 error right away when SpamFilter connected to it (this would have indeed caused the email to be queued for re-delivery, as SpamFilter would not have been able to connect to your server to begin with). The 451 greylisting error was sent by the SMTP server after SpamFilter connected and sent the HELO command (which indicates a successful connection), specifically the 451 error was sent only after SpamFilter issued the RCPT TO command to verify the existence of the recipient. Since the SMTP server rejected this recipient, this caused the bounce you saw.

We could in theory have SpamFilter only respond to 5xx errors when it comes to verifying recipients, and ignore any 3xx and 4xx error codes - we'll look into this to see if this could cause any kind of other issues.

 

One of the clients we filter for had managed to enable greylisting on their server (We told them to fix that by the way). But in tracing emails, the Logsat behavior was a bit unexpected. When SF tried to deliever an email and was given the 451 "try again later" error, it returned a 550 permanent error to the sending server and dropped the email. Here's the logfile line...

 

08/25/10 10:26:36:333 -- (620) Some recipients do not exist, sending 550 to sender SMTP server. The destination SMTP server said:sales@redacted.com: 451 Greylisted, please try again in 300 seconds

 

So my questions are:

 

1) If the receiving server issues a 451 temporary SMTP error, I realize at some point SF needs to give up and return a 550 but can I request a feature where you can set the number of retries rather than giving up on the first attempt? That seems a bit harsh.

2) What if the receiving server is offline? Does this new routine mean that mail will be dumped if the receiving server happens to be down?

 

Thanks in advance!

Thanks for helping me out. This post can be closed.

If you can zip and email us SpamFilter's activity logfile for a day this happened, and let us know the to/from email addresses involved, we'll take a look to try to see what is happening. Please also include your SpamFilter.ini file, and the entire \SpamFilter\Domains directory tree. If you are storing any of your blacklist/whitelist files outside that Domains directory, please include those as well.

If the zip file is over 8MB in size, I'll send you a PM with the info on how to FTP the file to us.

Please see this section of the manual for the "Unfiltered Emails" whitelist. Does this apply to you?

 

We use Spamfilter-ISP 4.1.2.812.

We use AutoWhiteListForceDelivery.txt to whitelist domains or individual mail addresses.

For those whitelisted e-mails, some of them get tagged in the subject and others don't. When tagged, the subject is preceded with "[*probably spam*]:"

(spamfilter.ini has 'SPAMTagPrefix=[*probably spam*]:).

In the filter settings, we did not tick "Tag spam in subject & deliver".

Do you know why some of the e-mail still get tagged?

 

Kind regards,

 

Peter.