Release 1.0.0: Emulating a true SMTP process?

[karolyi]

Hey @reinhard-mueller, I have doubts about "emulating the true SMTP process".

Right now in the current planned major release you helped with, the module will probe through all MX hosts, collect information about delivery status and only bail out with an early positive if one of the MX hosts is positive.

This brings up an issue: in a (super-rare) case of a primary MX host being negative and a secondary positive, the module will still indicate positive.

Problem is, the way I've seen (with postfix at least), it's not the real-world scenario. Postfix will go through all MX hosts and bail out early on the first negative. This could lead to a problem of bounced emails where a secondary MX host (a relay) will accept the email and try to deliver to the primary MX host that fails, and then respond with a bounce notification email to the sender. Hence, I think it's not the proper functionality.

Can you add your 2 cents here? Not sure what MTA you use but if we want to be precise, the current planned functionality is not 100% accurate, at least not in the case of the postfix MTA.

[reinhard-mueller]

I agree with you. I think the correct thing to do would be:

1. Check the SMTP servers in order of priority instead of random order.
2. Collect SMTPServerDisconnected exceptions in __temporary_errors instead of __communication_errors (RFC 5321 says unexpected disconnect should be treated like a 451 status).
3. Exit early by directly raising CommunicationError on the first 5xx SMTPResponseException.

That would mean that on any 5xx status, the check result would be immediately negative, while on any 4xx status the further MX servers would be tried. I think this comes to standard mail server behaviour as close as we can get.

And having said all that, I agree that the situation that one MX creates a 5xx message and the other one accepts the same address is an extremely rare case, I think it can only happen through a misconfiguration. Anyway exiting early on 5xx is probably better anyway, since it saves time and bandwidth.

If we agree on the 3 changes above, I can include them in the upcoming PR.

[karolyi]

Absolutely, this is exactly what I meant and also what I've seen from a practical standpoint using my own server with postfix.

The case can happen when a bigger email provider has their primary servers failing but the backup, relay only servers still work, collecting the emails for the meantime and relaying it when the primary servers start working. Either they are in the position of reaching some kind of an internal resource and wait until said primary servers start to work (and thus providing the proper functionality without the outside world being able to see it), or they would try to relay immediately and then come up with bounces to the sender.

Either way, your changes would be the appropriate ones. We can't release 1.0.0 as is, if we want to be precise.