Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joi

  On 9/30/10 8:15 AM, Steve Atkins wrote:
>  On Sep 30, 2010, at 4:05 AM, Charles Lindsey wrote:
> > On Wed, 29 Sep 2010 18:52:01 +0100, John Levine <johnl(_at_)iecc(_dot_)com>
> > wrote:
> >
> > > I was thinking of the various proposals to rewrite From:
> > > addresses, to outlaw subject tags and message footers, and
> > > otherwise change the behaviors that MLM users expect in order to
> > > make them conform to various ideas of how DKIM and/or ADSP are
> > > supposed to work.
> > But nowhere has anyone suggested REQUIRING any MLM to do any of
> > those things.
> > They are all offered as suggestions for things MLMs MIGHT do do
> > get themselves out of such DKIM-caused troubles as they find
> > themselves in.
>  There are no DKIM-caused troubles they could possibly get themselves
>  into.
>
>  If you mean ADSP, say ADSP. If you really mean DKIM you need to
>  expand on what sort of troubles you're talking about.
Agreed.  Those receiving benefits from a protocol change have an 
incentive to make additional efforts.   Companies who employ email in 
their services are finding customers will discontinue the service when 
inundated with phishing attempts.  The impact of this is more 
significant than fraud losses related to phishing.

ADSP's use of From header fields to establish signature compliance is 
incompatible with third-party services, unlike SPF's use of MailFrom 
parameters for authorization compliance.  Unfortunately, since SPF 
compliance is based upon unseen header fields, it can not mitigate 
receipt of phishing attempts and its authorizations fail more often than 
DKIM validations.

The problem is clearly related to ADSP and not DKIM, although domains 
publishing ADSP assertions can exclude phishing messages on behalf of 
their customers.  It is counter productive to suggest mailing-lists 
should make changes when these services are not commonly used in 
phishing attempts for several reasons.

Annotations applied by most mailing-lists allow sorting and recognition 
of messages not received directly from the identity within the From 
header field.  Although the actual source of these messages is seldom 
confirmed, the typical segregation of mailing-list messages from other 
direct sources help prevent these services from becoming a likely 
phishing exploitation vectors.  Recommending that mailing-lists to 
discontinue their annotations will cause problems, since these messages 
often lack source authentication, and without annotations, recipients 
will be unable to discern which are from less trustworthy sources.

Rather than suggesting changes to the From header field, it might be 
better to have third-party services include a Sender header field 
instead.  After all, this was a feature found in the original SSP 
draft,  expecting to leverage "on behalf of" notations made by Outlook.  
Changing the use of the From header field would require a number 
handling changes that seem counter productive.

Is there a safe way to shift DKIM signature compliance based upon the 
 From header field to that of the Sender header field?  The TPA-Label 
scheme would be one such method, which also allows the use of the 
List-ID header field as well.  The TPA-Label scheme also has the domain 
being phished making the greatest effort, as it should be.

Receivers that then implement this scheme benefit by having lower false 
positive detections of illegitimate messages, while not seeing the 
disruption of third-party services.  This also avoids a bad practice of 
using sub or cousin domains in attempts to limit protection rather than 
seeking comprehensive solutions.

-Doug











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