ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature

2010-08-04 14:52:54
Charles Lindsey wrote:

But this assumes that the author is in a position to apply those 
remedies. If he is a lowly employee of some large security-conscious 
organization (say Paypal) there is probably a company rule that 
everything goes out under the company domain name, and employees are 
forbidden from sending emails with From: set to anything else (at least 
when sent from company equipment in company time).

But it may still be in the company's interest for ite employees to 
subscribe to mailing lists (e.g. list discussing security - such as this 
one).

Yes, the company has shot itself in the foot, but in the Real World (TM) 
that is a Regular Situation, and it is probably more useful to devise 
schemes that work in spite of foot shooting than to waste effort trying 
to stop the foot shooting in the first place.


Charles,

I think we need to put more faith in the domains wanting and declaring 
ADSP policies.

Why would an individual, company, corporation, especially major one
with a high value branded domain implement two technologies (SPF and
ADSP) for the main purpose to publicly expose and declare to the world
a highly exclusive and restrictive mail operations policies and
yet then still think or expect there would be permissible
corporate "loopholes" for external usage of their domain which would 
be end up 100% conflictive with their stated policies?

If Paypal or anyone explicitly declares restrictive policies with no
subjective considerations (its not soft, its not neutral, its not
sometimes signed, but always sign with hard policies), then I don't 
think it is expected by them the ADSP aware receivers are going to 
ignore faulty paypal.com messages and just pass it on.

paypal.com stated very strongly:

    SPF:  -ALL policy,       only their machines can send mail
    ADSP: DKIM=DISCARDABLE   only paypal signs as 1st party

They specifically declared:

    If the sending machines are not ours, don't trust it and
    reject it. If the message is invalid (no signature or not signed
    by paypal), get rid of it.

You can get any more explicit than this publicly exposed policy.

I'm sure paypal.com knew what it was doing when they internally
discussed and consciously decided to create those very exclusive and 
restrictive policies.  IMO, it also creates a DISCLAIMER for themselves.

Whats the point in 2nd guessing an restrictive SPF and/or ADSP domain? 
  The are not neutral in this declaration. They are very specific. 
They don't want you to resign it.

That is why, IMO, it is far easier for a MLS to preempt all 
restrictive ADSP
domains. This solves all MLS conflicts related to ADSP domains.

-- 
HLS



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

<Prev in Thread] Current Thread [Next in Thread>