On Wed, 15 Feb 2012, Andrew McGlashan wrote:
On 15/02/2012 7:20 PM, Matthew Cengia wrote:
On 2012-02-15 19:03, Jason White wrote: [...]
based on a few minutes of reading, I couldn't find anything in RFC2821 that would require it.
And it's odd that Andrew would claim otherwise. It's not even a sane thing to put into the relevant standards.
FYI, this is obsoleted by RFC5321 now (and updated by 5336).
Okay, well it doesn't appear to be part of the standards, but it is painful for greylisting. Although I can understand that one IP may become blocked or have issues, whilst an alternate (sending) IP might be fine.
Perhaps the standard needs to be amended to ensure that if there is 451 or other TEMPORARY type error that the mail server should be able to expect further communication from the same sending SMTP host using the original IP if possible -- this would help significantly with greylisting.
And make it impossible to implement certain types of highly available MTA clusters. What happens when the MTA that sent out the email that you have greylisted, then crashes before it gets a chance to try again? Should no other MTA in the cluster be allowed to pull the message off the spool on shared storage and retry itself? The specific implementation of your greylisting is not of concern to people running big MTAs. There are many implementations of greylisting and spam filtering in general. Pick another one that works for the kinds of email from the kinds of people you expect to receive. -- Tim Connors