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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg