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!

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.

 

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.

 

Had another issue today. Customer's exchange server started sending 400 errors back and SF didn't hold the mail, it bounced it. Logfile sample below...

 

03/03/11 08:02:54:481 -- (3728) Sending email from mailto:sender@example.com - sender@example.com to mailto:recipient@domain.com - recipient@domain.com -- 03/03/11 08:02:54:684 -- (3728) EMail from: mailto:sender@example.com - sender@example.com to: mailto:recipient@domain.com - recipient@domain.com --  was returned to sender - server error - x.x.x.x:25 said: 4.3.1 Out of memory -- 03/03/11 08:02:54:809 -- (3728) Error-email from mailto:sender@example.com - sender@example.com to mailto:recipient@domain.com - recipient@domain.com --  was forwarded to a.b.c.d:25 03/03/11 08:02:54:809 -- (3728) server error - x.x.x.x:25 said: 4.3.1 Out of memory --