[ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Hector Santos
hsantos at isdg.net
Wed Aug 4 12:50:01 PDT 2010
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
More information about the ietf-dkim
mailing list