On 10/13/11 3:30 PM, Murray S. Kucherawy wrote:
On Thursday, October 13, 2011 3:18 PM, Keith Moore wrote:
Before we invest any significant amount of energy in this idea, I'd
like to hear from a few large mail service operators who think they'd
implement this (on client and/or server ends) and benefit from it.
I've asked. Waiting to hear back from any of them.
When our systems were heavily over-loaded, it was difficult to know the
number of failed connections since this was not seen in MTA logs. By
adding additional MTAs, only then did such connection failures become
apparent. When we introduced a temp error strategy, there were a few
non-complaint MTAs that would immediately retry. There were others
using compliant MTAs that still retried too soon. When we asked why,
they said it was necessary to flush their outbound queues.
It seems doubtful any information added to temp error codes will prove
beneficial. Even when receivers know when in the future they will be
willing to accept questionable traffic and wish to accommodate those
that adhere to their requested retry intervals, this strategy would be
based on a questionable assumption the MTA carry the state to make the
determinations. Spammers will call their bluff.
When inbound systems are overloaded, DKIM will not offer relief either.
If it did, spammers would mimic any allowance some profile provided.
Without an upfront light weight AUTHENTICATION scheme, only white-listed
domains considered "too big to block" have a chance. Everyone else will
need to seek their services. The current snafu benefits the larger
providers where there is minimal overall reduction in spam.
-Doug