[Top] [All Lists]

Re: SMTP traffic control

2011-10-28 18:39:07

On 10/28/11 2:07 PM, Steve Atkins wrote: On Oct 28, 2011, at 1:49 PM, Carl S. Gutekunst wrote:
Steve Atkins wrote:
It would be nice if the server could say "give me a minute to get my stuff together 
and come back", have the client retry in 60 seconds and get the mail accepted for 
delivery - with a delay of a minute or so, rather than a delay of 30 minutes. The server 
gets to shed load, the client gets to dump a message out of it's queue and the human 
correspondents see fast, in-order mail delivery rather than slow, out-of-order delivery.

That's the end-user visible part of the thought behind anyway.
I'd support that proposal. I might even implement it.

Unfortunately, the dominant conversation seems to be around an SMTP response 
that only applies to greylisting. I'd never use that or support it, it's such a 
teeny-tiny corner case, especially in the B-to-B world where I live.
Me too.

But that's the thing with an open mailing list - people who are really interested in one niche 
aspect of a subject or a broad generalization of one can easily dominate the conversation. And a 
broad, general blue-sky idea will always provoke more discussion than a trivially simple one. 
I'd suggest changing the title and spinning off a sub-thread to discuss just the "SMTP 
traffic control" aspect, but that didn't work too well last time…

Let me spin up a new thread, with an implicit "no, I don't mean greylisting" 
subtext. :)
In the past, when there was an unexpected growth of incoming traffic, delays occurred when clients were unable to establish connections where the event was not noted in receiving SMTP logs. One solution was to deploy more servers or impose more restrictive firewalls.

What does this mean for IPv6?

Geoff Huston offers a perspective:
The graph clearly indicates IPv6 is seeing geometric growth.
What happens when IPv6 interfaces represent the new acceptance granularity?

Total address space spanned by table (/64s): 246,300,931,457,031 or 246,301 billion. When divided by 3.8 billion of unicast IPv4 addresses, the result is 65k greater in size. It also seems growth will see a six fold near term increase. Expecting IPv6 CIDRs to remain larger than /64 also seems doubtful since there will be business demands for allowing /128 exceptions. :^(

Attempting to use DKIM as a basis for acceptance is not practical. DKIM mandates inclusion of invalid signatures. Even when a valid signature is found, it is not intended to verify the entity issuing the message nor their intended recipients. As such, DKIM fails to offer enough information to establish accountability. Attempting to establish accountability based upon message content devoid of who sent a message and to whom would not permit consistent policies.

The alternative of depending upon IP address authorization in the face of RFC6333, RFC5969, and shared MTAs needed in the IPv4 to IPv6 transition is illogical. Especially when prevalent authorization schemes attempt to resolve all IPv4 and IPv6 hosts for an entire base domain using macro expansions that defeat DNS caching at each SMTP connection.

A desire to establish new reputation systems as a solution should first impose authentication as a baseline requirement. Otherwise, the defense of a domain's reputation is impossible.

Our system makes use of dynamic temporary errors as a triage strategy, not as a method to determine whether a sender is able to retain state. Sources currently seen emitting spam are more likely to be temporarily blocked. The duration depends entirely on the source.

Should we add a comment to please stop spamming before attempting a retry? How would that help?

A reasonable control strategy might follow the structure reviewed in RFC6281. Perhaps leveraging Kerberos and DNS/DANE services that offers long term tickets for SMTP senders. Such a strategy could quickly eliminate the vast amount of abuse currently responsible for much of today's delays. It would also ensure delivery through any Internet infrastructure.

Perhaps restoring accountability to SMTP would reduce a desire to use proprietary social networking where often the client software affords poor security. Just as it is no longer safe to use FTP, SMTP suffers from openness that can no longer be sustained. Rather than attempting to track billions upon billions of potential IP sources that are increasingly shared, a vetted authentication scheme can easily handle even a high estimate of 130 million legitimate sources.

The upside of this added complexity that is not really more complex when considering the scale needed to resolve accountability at the IP address. SMTP could become dramatically safer and easier to deploy with much better throughput. By focusing on outbound MTAs, users are more likely to be notified when their account or system is compromised.



<Prev in Thread] Current Thread [Next in Thread>