On 12/17/10 8:03 AM, John Leslie wrote:
Obviously, it is possible to authenticate differently, and Doug
has wrapped his mind around several different mechanisms over the
last five years. None of them, IMHO, work very well in the time
domain (delivering results that may be outdated, and struggling to
mitigate replay problems). But they are certainly better than
relying on IP addresses alone.
John,
DKIM has a limited basis for accruing reputations, since this protocol
neglects confirmation of destinations, which would not be a problem with
CSV. As a result, DKIM domains can not be applied against undesired
messages on the basis of destination alone. DKIM however inhibits
false-positives with anti-phishing filtering.
The principle in CSV was to have the sending SMTP client declare
its identity in HELO or EHLO, and have the receiving SMTP server
authenticate at SMTP time that the domain authorized that client
to send according to its policies. (Of course, those policies do
not necessarily match the policies of domains named in MAIL FROM or
any similar domains which will be visible to recipients.)
Now that v6 deployment methods have become apparent, using IP addresses
to confirm EHLOs is likely to become increasingly error prone. SPF will
equally fail, even with its many transactions involved. In addition,
when SPF is used in conjunction with SMTP transactions, this will also
represent a DoS concern, especially with DNSsec.
At the last MAAWG meeting, consensus was reached with a statement that
SPF can not be used to abate spam. SPF offers a method to determine
which IP address block-lists affect a domain's delivery, and secondly as
a method to qualify feedback streams. Sender-ID was considered unusable
and ineffective.
CSV relied on a weak but timely authentication; we have since
seen alternatives that are stronger but less timely -- the principle
of authenticating the SMTP client talking to you is more important
than the exact balance between strength and timeliness.
Likely some extension of RFC4954 will be needed, where public keys are
used to confirm hashed and signed challenge responses. This might use
DKIM's public key or whatever resource is created by the keyassure wg.
There must also be conventions about the name determined.
In principle, it may be possible to build a business model with
even-weaker authentication by IP-address and unknown timeliness;
but I wouldn't want to be the one trying to build it.
Terabytes of logs processed daily for just v4 is already staggering.
The same approach with v6 simply won't work. SMTP needs simple and
stable handles that don't involve transport addresses. That is not to
say there can't be a transition strategy using existing conventions as a
means to confirm server/mail-domain names.
Being able to combine v6 and v4 into common reputation queries with a
destination basis for undesired messaging would tremendously aide SMTP's
transition into v6, while also improving the state of SMTP in general.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg