Re: SMTP traffic control

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 
> > > https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/ 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:
http://bgp.potaroo.net/v6/as6447/
The graph clearly indicates IPv6 is seeing geometric growth.
What happens when IPv6 interfaces represent the new acceptance granularity?
http://bgp.potaroo.net/v6/as6447/report.txt

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.
-Doug

**