Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

On 7/27/11 12:13 AM, Michael Deutschmann wrote:
> I have one comment to make which ties together both my stance on Otis'
> doublefrom crusade, and some reforms I have argued for in ADSP.
>
> Basically, at present the doublefrom trick is simply *unnecessary* for
> someone trying to pass me a forged mail.  My MTA, Exim-4.76, does not
> natively support ADSP.  It does support core DKIM, but without ADSP it's
> not reasonable for the DKIM result to have any effect on the message
> disposition.
>
> It probably wouldn't be *that* hard to cobble together some receiverside
> ADSP implementation using Exim's other features, but it's just not worth
> my while.
>
> I'm not afraid of any phish fooling me, but I am interested in anything
> that reduces the amount of "bad mail" reaching my inbox.  But while a
> lot of spam is forged, it's forged to be from some ordinary schlub, not
> Paypal.
>
> I keep records going back to 2007, and since the start of that year 254
> bad mails (spam and viruses) have gotten through to me.  They represent
> 210 alleged From: domains.  Of those domains, -absolutely none- of them,
> -today-, have ADSP records at all.  Not even a "dkim=unknown"! Thus
> retrospective analysis shows ADSP is unlikely to make any difference.
>
> I may well implement double-From: detection alone.  *It* would have
> blocked three spams from that interval (none of which bear any attempt
> at a signature).
>
>
> Now, all that aside, Paypal would probably still really like me to arm
> ADSP, just in case.  But while it may be worth *their* time to sail
> 100km to meet me (that is, by actually maintaining no-mailing-list
> discipline so they can use discardable), it's not worth *my* time to
> drive 1km from my hilltop home to the port to meet them.
>
> If ADSP were fixed so that it could be deployed meaningfully at ordinary
> domains, with users who post to mailing lists, this might change.
>
> I've already stated my fix -- add "dkim=except-mlist", which states that
> any message with broken/absent signatures should be considered bogus if
> it is known not to be a mailing list message.
>
> While merely adding a fake "List-Id:" header might let forgeries of
> except-mlist domains get through to many users, that will never work on
> me.  I recognize my mailing lists via other indicia that are harder to
> forge (the MAIL FROM:).
Michael,

Your fix will not control phishing or spoofing abuse and would expose 
these domains to open-ended sources.  Reactive methods will prove less 
and less effective as the name and address space grows.

DKIM should be viewed as a Work-In-Progress still missing a viable 
policy layer.  Key sharing will not scale well enough to solve the 
mailing list issue.  Not having a solution for open third-party services 
leaves ADSP suitable only for a tiny fraction of senders that could 
benefit from improved anti-phishing measures.

For DKIM's protections to be comprehensive, policy needs an 
authorization structure able to include open but trusted third-party 
services.  Such policies can be supported by a DNS zone of the domain or 
one referencing that of a reputation provider.  The authorization in 
either case can be resolved within a single and small transaction.

http://tools.ietf.org/html/draft-kucherawy-dkim-atps-03

Unfortunately, such a goal makes little sense when DKIM fails to 
validate input for valid DKIM signatures by ignoring multiple From 
header fields.   None of this will happen over-night, where indeed the 
eventual strategy must be easy for administrators to implement.  IMHO, 
easy should not always mean the use of TXT records however.

-Doug









_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html