Re: Microsoft takes over British Telecom

On 10/26/11 5:04 AM, Alessandro Vesely wrote:
>  On 25/Oct/11 22:41, Douglas Otis wrote:
> > On 10/24/11 2:40 AM, Alessandro Vesely wrote:
> >>
> >> With two policies out of two that choke on forwarding, I'd
> >> suspect the culprit is the latter. Indeed, forwarding implies
> >> that target addresses are being kept on a server. Hence, such
> >> server must have some sort of authorization for using them. Why
> >> don't we check that?
>
> > Efforts aimed at determining an "IP address authorization" based
> > upon some "message element" is flawed for two reasons:
>
>  I assume you mean SPF. Flawed as it may be, it'd still be better
>  than nothing.

Not when SPF authorization is considered a basis in which to assess a 
domain's reputation.  This occurs at a time when large scale NATs (LSNs) 
are deployed by ISPs to support IPv6 transitions.  The inability to 
defend authorizations against reputation poisoning will foster 
dependence on providers protected by their "too big to block" status.  
The growing environment of shared outbound sources makes simple 
authorization fully unsuitable.

In addition, each email transaction demands DNS resolve all IPv4 and 
IPv6 hosts used by any globally recognized domain.  These DNS 
transactions may extend beyond 100 in the effort to authorize all 
outbound MTAs used by a single domain.  This exercise can lead to DDoS 
against domains not a party to either end of the specific email 
transaction.  SPF macro expansions defeat DNS caching and result in 
easily two orders of traffic amplification. :^(

There are many methods that might be used to authenticate outbound MTAs, 
such as SMTP Auth.  Ideally SMTP would include DANE extensions used in 
conjunction with Kerberos.  If it were not for DKIM ignoring prepended 
headers, it would have merit as an anti-phishing strategy.  Since DKIM 
does not verify who sent what to whom, it can only identify domains 
considered "too big to block" as well.

> > A sensible solution is a cryptographic method to authenticate the
> > domain of the outbound MTA. DKIM does not authenticate the
> > outbound MTA, and remains prone to abuse in a manner similar to IP
> > address authorization.
>
>  Ditto.

What do you think is standing in the way of SMTP authentication?

> > Perhaps a new type of SMTP needs to be developed, where the
> > protocol remains unchanged with the exception of MTA
> > authentication requirements. Call it AMTP for Authenticated Mail
> > Transport Protocol.
>
>  Why not call it SMTP-AUTH? Indeed, it's much stronger than SPF or
>  DKIM.

In the past, some of the objections had been cert costs.  DANE should 
remedy the cost issue, and ensure domains support DNSsec.  The increased 
overhead related with DNSsec demands greater attention given protocol 
dependent upon DNS that might lead to indirect high gain DDoS attacks.

> > Once the MTA can be authenticated, the guesswork and mistakenly
> > purported domain issues go away. There would not be any need to
> > grey list recipients once receivers are able to maintain and
> > control who they permit to issue messages.
>
>  Yep.
>
> > This may mean new domains need to solicit intended recipient
> > domains to request inclusion.
>
>  No, not only new domains. Whenever someone prompts you for your
>  email address and your consent for using it, according to various
>  laws, it could/should store some form of auth token along with it.
>
>  That way, I'd address forwarded mail only. That is, more or less,
>  what policies such as SPF and ADSP seem to be unable to handle
>  properly --I called it the culprit in the top quoted paragraph
>  above.

Expectations any outbound MTA mitigate abusive accounts where reputation 
is based upon authentication of the MTA would have a profound outcome.   
Users in possession of compromised accounts/systems would be made aware 
and categorization of mail content (as you suggest) becomes moot.  Don't 
expect recipients are able to sort compromised accounts of large 
senders.  Placing that burden on recipients never scales.

>  Direct personal messages, where recipient addresses are set as part
>  of the message composition, need no authorization. Of course, black
>  spammers will pretend to write personal messages, thereby breaking
>  the law, but grey spammers won't.

Or allow new domains to quickly obtain the same status of any domain 
that quickly mitigates abuse.

> > Such a process predicated on authentication scales far better and
> > would be less disruptive than reactive blocking of any "purported"
> > abuse.
>
>  I concur. The ability to mechanically tell legitimate messages will
>  then allow spam reporting to be a well defined activity.

Hopefully spam reporting will also play a reduced role as well.

-Doug