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

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 00:37:12 +0200

Hi, all

in the light of the discussion about draft-ietf-dkim-mailinglists I'd 
like to propose an alternative way to solve the MLM dilemma on how to 
deal with original DKIM signature/message versus sending out a modified 
version of the message. This proposal may be impractical or hard to 
realize, but I'd just thought I had to share it with you.

The proposal is to preserve the original message + DKIM signature and to 
add the new (probably partially rewritten) output message, combined into 
a multipart/alternative structure. The combined message is sent by the 
MLM to the recipient. For the original message + DKIM signature, we 
could register a Content-Type of e.g. message/dkim-original-message with 
IANA. The output message would be the other part of the 
multipart/alternative, with the normal MIME structure of the MLM output 
message. A sample message sent by an MLM (or more in general, by a 
re-signer) would look like:

From: "Rolf E. Sonneveld"<[email-masked]>
To: DKIM List<[email-masked]>
Date: Mon, 02 Aug 2010 11:43:39 +0200
Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion

--boundary1234
Content-Type: message/dkim-original-message

... original version of message including all original headers and _original DKIM signature_ goes here ...

--boundary1234
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII

... output message of MLM goes here ...

--boundary1234--

As per MIME  RFC 2046 (par. 5.1.4) multipart/alternative provides a 
means of presenting multiple versions of the same information, where the 
receiving MUA can decide which one to display to the recipient. In a 
sense we can view the original message and the one, that is being sent 
out by the MLM, more or less as two incarnations of the same message, 
and as such I think the multipart/alternative can be used. As the 
message/dkim-original-message subtype will not be recognized by MUA's, 
we can be sure that the end user will be presented by the MLM rewritten 
version of the message.

The advantages of using this approach are:

- the original DKIM-signature is preserved. The verifier can verify both 
the original DKIM signature of the author domain, as well as the DKIM 
signature of the MLM domain.
- any FBL can use the message/dkim-original-message information to send 
the feedback to the proper place
- no need to rewrite From address (and Sender, Reply-To)
- this approach can be used for other 're-signing' mail agents in the 
chain between sender and recipient
- it can also be used when there is more than one re-signer in the chain 
(nested multipart/alternative structure) to provide a generic solution

Disadvantages of this approach are:

- it requires the verification paragraph of DKIM to be rewritten
- the size of MLM redistributed messages is doubled roughly (hey, nobody 
complained about the extra size of text/plain + text/html messages ;-))
- it will probably require more changes in MLM software than the other 
proposals

I'm sure there is a whole lot more to say about this proposal, more 
pros, more cons etc. I solicit your comments!

/rolf

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

---

From: Steve Atkins <[email-masked]>
Date: Mon, 2 Aug 2010 15:56:52 -0700

> re-signer) would look like:

Does this mean that anyone can take their own content and
a message DKIM signed by someone else, and then send it out
such that their content will be displayed, but the (non-displayed)
signed message will be checked?

If so, this seems like exactly the reply attack that DKIM was designed
to prevent.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 3 Aug 2010 00:36:11 -0000

>MLM to the recipient.

Once again, I can only see this as screwing up the 99+% of users for
whom the lists work just fine for the <1% who consider themselves so
important that they need to mark their list mail with ADSP.

Imagine you're a list manager.  Your list has 1000 subscribers.  Two
of them demand that you do something to prevent address forgery due to
forged unsigned messages, a problem that you have never observed to
happen on your lists.  What do you do?  I know what I'd do.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 10:50:41 +0200

> signed message will be checked?

No, it means that for both message parts a DKIM signature is checked for 
presence and the results of both are made available to the receiver 
('receiver' as in Murrays draft defined in par. 3.1). So effectively it 
means that in the situation you described, the 'own content' is 
displayed but lacks a verified DKIM signature and as such should be 
treated as a message without DKIM signature. The proposal just means to 
provide a way to tunnel the original contents of a message + DKIM 
signature and enable the verifier to verify not only the DKIM signature 
provided by the resigner, but also the original DKIM signature as well.

The A-R results of the original DKIM signature, provided by the resigner 
as part of the new DKIM signature can only be trusted if the 
verifier/receiver trusts the resigner. With the original DKIM signature 
+ message present, there is no need for this trust relation; the 
verifier itself can verify.

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 12:03:29 +0200

On 08/03/2010 02:36 AM, John Levine wrote:
> whom the lists work just fine for the<1% who consider themselves so

I did not have ADSP in mind when writing this proposal. Let me be clear 
about ADSP: IMO domains that publish adsp=discardable and yet send mail 
with that domain via mailing lists, get what they deserve: problems.

> happen on your lists.  What do you do?  I know what I'd do.

In a nutshell the problem of the combination DKIM + MLM can be 
summarized (and simplified) as follows.

On the plus side:

1. the mail that is received by a subscriber to a mailing list carries 
(most of the time) the original From.
2. the original DKIM signature can still be present in the message (if 
we recommend the MLM authors to not remove DKIM-Signatures)

However...

3. the MLM rewrites the Subject (in many cases)
4. the MLM adds a footer (many cases)
5. see par. 3.3 of Murrays draft for more things MLMs do to messages

That means, we have a signature + From, but we no longer have a reliable 
copy of the message to verify them.

6. we can tell the MLM authors to change their code to no longer do 3., 
4. and 5. but, as Murray describes in par. 3.4:

<quote>
However, the practice of applying headers and footers to message
bodies is common and not expected to fade regardless of what
documents this or any standards body might produce.
</quote>

With this situation in mind, I wrote my proposal, to provide the 
verifier on the receiving side with a means to verify the original DKIM 
signature.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Tue, 03 Aug 2010 08:02:34 -0400

Rolf,

It seems much easier for MLS (Mail List Servers) to preempt 
restrictive ADSP Domains from subscribing and from submitting mail to 
the list enabled with DKIM resigning.

Follow the specification and apply it accordingly using engineering 
sense. No Subjective concepts. We need persistent expectations across 
the board. The problem here is that list managers what to sign 
everything with disregard to policy.  There is no way you going to get

      DKIM+POLICY+MLS

correct.  Something has to give.  Support policy is an answer, getting 
rid of it is another so that at least everyone can work under the same 
plane.

It would easy to add new common sense options to our list server such:

List DKIM/ADSP options:

   [X] DKIM Sign this list

       [CLICK FOR DKIM SIGNING OPTIONS]

   [X] Disallow ADSP DISCARDABLE domains from subscribing.
   [X] Disallow ADSP DISCARDABLE domain list submissions.

   [X] Send Notification to domain for ADSP=DISCARD Policy
       restricted subscription or submissions.

       [EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE]
       [EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE]

The template #1 would probably say:

   Dear {MSG.FROM}

   Sorry, but you can not subscribe to this list using
   a restricted ADSP DKIM=DISCARDABLE policy for your
   domain. If we had accept your subscription,  there is
   risk of harming the subscription status of other members
   already on the list. We don't wish to do that.

   Remedies:

   1) Remove the DKIM=DISCARDABLE ADSP policy or change
      ADSP policy to DKIM=ALL and reapply to subscribe
      to the list.

   2) Use another domain that isn't ADSP restricted.

The template #2 would probably say:

   Dear {MSG.FROM}

   Sorry, message submission to this list is restricted to
   domains with non-ADSP DISCARDABLE policies only.
   If we had accepted it,  there is risk of harming the
   subscription status of other members of the list. We don't
   wish to do that.

   Remedies:

   1) Remove the DKIM=DISCARDABLE ADSP policy or change
      ADSP policy to DKIM=ALL and resubmit your message.

   2) Use another domain that isn't ADSP restricted.

I can't remove popular features even if I wanted to and I seriously 
doubt any RFC will change this for most systems:

   [X] Add [LIST] Tag to Subject Line
   [X] Add Footer                   [EDIT FOOTER TEMPLE]
   [X] Set Reply-To to List address
   [_] Strip HTML
   [_] Strip Attachments

and all other inherent integrity breaking ideas in MLS software and 
used by MLM (Mail List Managers).

We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into 
DKIM/POLICY.  -1 towards ideas of altering 5322.From lines which will 
only open a nasty can of worms.  We would be breaking all kinds of 
Authorship From expectations, including touching base with copyright 
related issues.

Or get rid of POLICY if its hurting DKIM implementation for list 
servers. Working it to standardization yet list managers with DKIM 
resigners intentionally ignoring it is not going to work very well. 
Not supporting it is one thing, yet allowing ADSP domains to submit 
mail is another thing.  It doesn't mix well.

If this becomes the behavior what will happen is SMTP systems will be 
force to accept mail to discard it.  They won't be be able to reject 
mail at the transport level because that will promote a bounce towards 
the list server and this will hurt members of the list.

We can't dictate to SMTP developer and operators not to employ session 
level rejections.

-- 
HLS

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 14:56:19 +0200

> We can't dictate to SMTP developer and operators not to employ session

My proposal was and is _not_ aimed at ADSP and _not_ at policies in 
general. The proposal only identifies a means to make MLMs (and 
re-signers in general) in a way 'transparant' for receivers of a mail. 
Nothing more, nothing less.

/rolf

---

From: <[email-masked]>
Date: Tue, 3 Aug 2010 08:13:06 -0400

When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is [email-masked] and if I bothered to check adsp for [email-masked] I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator. If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that [email-masked] is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution.
thanks, now back into lurk mode
Bill

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 15:30:17 +0200

On 08/03/2010 02:13 PM, [email-masked] wrote:
> When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is [email-masked] and if I bothered to check adsp for [email-masked] I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator.

Again, I am not talking about ADSP.

> If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that [email-masked] is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution.

Trusting the MLM may be possible for you personnly for this particular 
mailing list, but your choice is not scaleable to the Internet at large. 
Or is the general consensus that (in the long run) the reputation of the 
MLM domain is sufficient for the verifier/receiver of MLM distributed 
mail? I don't read that in the draft.

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 3 Aug 2010 10:06:02 -0400

> the list enabled with DKIM resigning.

This would also give you the use case to deal with of restrictive ADSP 
published after someone has already subscribed.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Aug 2010 07:59:20 -0700

Rolf,

When we wrote our dkim implementation, we did a bunch of work within the
existing DKIM framework (using l= and z=) that allowed us to get most
original signatures to reverify through mailing lists (~95%). No work
needed on the mailing list software at all. What you're proposing would
be close to 100% reverify rate of the lists that choose to implement
what you're proposing. Right now that's 100% * 0% :) But even if it
was accepted and caught on, it would still be a *very* long time before
you got to anywhere close to what we achieved. Maybe this would be good
for the pathological cases, but it probably wouldn't be good enough to
trust for, say, ADSP-discardable or any other indicator/service that
said that you should treat unsigned/broken signatures harshly.

I guess the meta question here is what the purpose is you have in mind.

Mike

---

From: <[email-masked]>
Date: Tue, 3 Aug 2010 09:45:02 -0400

I trust the reputation and blame the reputation of the MLM as a single standalone author. I have no interest in the contributors reputation. As a receiver who is on many lists I unsubscribe when the list no longer meets my viewing needs. As a admin of mail systems I dont want to interrupt that flow unless virus or spam is egregious

---

From: "John R. Levine" <[email-masked]>
Date: 3 Aug 2010 11:57:44 -0400

> mailing list, but your choice is not scaleable to the Internet at large. Or 
> is the general consensus that (in the long run) the reputation of the MLM 
> domain is sufficient for the verifier/receiver of MLM distributed mail? I 
> don't read that in the draft.

How do you sort list mail now?  By List-id, or by individual From lines? 
Everyone I know sorts by the list.  In a few cases I do bozo filtering to 
dump individual messages, but that's on genuine mail from bozos, so 
signatures aren't an issue.

If people expect mail recipients to stop treating a list as a single 
mail stream and instead as unrelated messages from the contributors, it'd 
be helpful if they explained why 30 years of practice is going out the 
window.  To me this looks very much like the drunk searching for his keys 
under the streetlight.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Aug 2010 09:14:36 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Tuesday, August 03, 2010 6:30 AM
> To: Bill Oxley @ Cox
> Cc: [email-masked]
> Subject: 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
> 

That's definitely my forward-looking view, but it's hard to include text in a document that points to something in the future with any degree of certainty.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Aug 2010 09:15:46 -0700

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, August 03, 2010 7:59 AM
> To: Rolf E. Sonneveld
> needed on the mailing list software at all.

But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing?

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Aug 2010 09:20:35 -0700

> But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing?

Sorry, I don't understand.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Aug 2010 09:40:58 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2010 9:21 AM
> To: Murray S. Kucherawy
> Cc: Rolf E. Sonneveld; [email-masked]
> > But didn't we also say that such reverified signatures don't get any
> > additional meaning with 'z=' reprocessing?
> 

I guess I don't either.  You're saying use of "l=" and "z=" got your mail-through-lists signature verification statistics up to 95%.  However, RFC4871 says "Copied header field values are for diagnostic use" which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a "z=" tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., "This signature failed, and via the 'z=' we know why... but it still failed.").

-MSK

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Aug 2010 09:53:32 -0700

> I guess I don't either.  You're saying use of "l=" and "z=" got your mail-through-lists signature verification statistics up to 95%.  However, RFC4871 says "Copied header field values are for diagn…

Yeah, well, sue me for flipping that MUST NOT the bird. It works, z= is signed
by the originator, and it's probably as high a recovery rate that you'll ever
get going through mailing lists. We weren't proposing that it be part of any
standard, and our reasons had nothing to do with ADSP either. All I'm saying is
that if you want mailing list signature recovery, we've already done that and
wrung out about as much as can be hoped for.

As I asked earlier, what is the purpose of this anyway? We were doing it to
deal with spear-phishing attacks. Maybe I've missed the motivation for the
mime thingy.

Mike

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 19:34:55 +0200

On 08/03/2010 06:53 PM, Michael Thomas wrote:
>> I guess I don't either. You're saying use of "l=" and "z=" got your 
>> mail-through-lists signature verification statistics up to 95%. 
>> However, RFC4871 says "Copied header field values are for diagnostic 
>> use" which I interpret to mean (and I think discussion on the list 
>> back then also agreed) that the information in a "z=" tag isn't 
>> supposed to contribute to the canonicalization algorithms, but 
>> instead can only be used for diagnostic purposes (i.e., "This 
>> signature failed, and via the 'z=' we know why... but it still 
>> failed.").
>

The motivation was the MLM draft document, par. 3.4. I quote:

<quote>
Changes that merely add new header fields, such as those specified by
[LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to
a DKIM-participating email infrastructure in that their addition by
an MLM will not affect any existing DKIM signatures unless those
fields were already present and covered by a signature’s hash or a
signature was created specifically to disallow their addition (see
the note about "h=" in Section 3.5 of [DKIM]). The shortest path to
success for DKIM would be to mandate that all MLM software be redesigned
or re-configured with that goal in mind.

However, the practice of applying headers and footers to message
bodies is common and not expected to fade regardless of what
documents this or any standards body might produce. This sort of
change will invalidate the signature on a message where the body hash
covers the entire entire message. Thus, the following sections also
investigate and recommend other processing alternatives.

</quote>

It was my intention to add one such 'processing alternative'. Now the 
question is: does it cover the remaining 5% or not? And if so (if we 
could get to 100%), is it worth the (huge) effort to rewrite DKIM?

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 03 Aug 2010 19:54:22 +0200

> I guess I don't either.  You're saying use of "l=" and "z=" got your mail-through-lists signature verification statistics up to 95%.  However, RFC4871 says "Copied header field values are for diagn…

Furthermore, the use of "l=" is discouraged in RFC4871 and in the MLM draft:

par. 3.5:
<quote>

        INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
            allow display of fraudulent content without appropriate
            warning to end users.  The "l=" tag is intended for
            increasing signature robustness when sending to mailing lists
            that both modify their content and do not sign their
            messages.  However, using the "l=" tag enables attacks in
            which an intermediary with malicious intent modifies a
            message to include content that solely benefits the attacker.
            It is possible for the appended content to completely replace
            the original content in the end recipient's eyes and to
            defeat duplicate message detection algorithms.  Examples are
            described in Security Considerations (Section 8  <http://tools.ietf.org/html/rfc4871#section-8>).  To avoid
            this attack, signers should be extremely wary of using this
            tag, and verifiers might wish to ignore the tag or remove
            text that appears after the specified content length.

</quote>

and

<quote>
A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the body hash, but this
not workable for [MIME] messages and moreover has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
</quote>

/rolf

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Aug 2010 10:59:13 -0700

> investigate and recommend other processing alternatives.

That's not really answering my question, unfortunately. I'm asking
what you intend to use the original signature's verification status
for with the knowledge that you will have a non-zero false positive
rate. We did our experiment with spear-phishing in mind: ie, can we
tag mail purporting to originate from us with a bad/missing signature
with an acceptable false positive rate. It was pretty close. I don't
know what problem your proposal is intending to solve.

Mike

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 04 Aug 2010 11:56:11 +0100

> mail? I don't read that in the draft.

It's the MLM that sent the message. Therefore any judgement of 
trustworthiness must be made with regard to the MLM.

If the sender domain wants to make some assertion about the message that 
will survive the MLM, then it needs to sign something that the MLM isn't 
going to change. Perhaps, in addition to a full strength DKIM signature, it 
could add a signature of the From:, Date: and Message-ID headers. If the 
signing MTA knows that the email is going to a list, it could even sign the 
list-post header that's going to be added. The point is to offer a 
signature that satisfies ADSP, while reducing the opportunity for replay 
attacks. Of course, if you're publishing ADSP discardable policies, you 
probably don't want to offer any opportunity for replay attacks. But there 
is, at least, a way of making DKIM, ADSP and lists work together if the 
sender wants to do that.

For MLM managers, they should simply reject at SMTP time if they are about 
to break ALL the DKIM signatures of a message from a discardable domain.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 04 Aug 2010 12:11:14 +0100

--On 3 August 2010 19:34:55 +0200 "Rolf E. Sonneveld" 
<[email-masked]> wrote:

> an MLM will not affect any existing DKIM signatures unless

So, in an ideal world, mail clients would expose the List-* headers 
(especially the unsubscribe* header) in ways that are useful to the user, 
and obviate the need for MLMs to mess with subject lines and bodies.

*In my view, MLMs are required in UK law to add unsubscribe information in 
a way that users can easily find it. The List-unsubscribe header isn't 
adequate, only because very few clients display it.

---

From: Graham Murray <[email-masked]>
Date: Wed, 04 Aug 2010 15:22:32 +0100

> adequate, only because very few clients display it.

There is not always even the need to expose these to the user. Some mail
clients (such as gnus), when they detect List-* headers add an
unsubscribe menu (and because it is emacs, keyboard) action.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 Aug 2010 15:50:01 -0400

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

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 09 Aug 2010 12:16:17 +0100

--On 4 August 2010 15:22:32 +0100 Graham Murray <[email-masked]> 
wrote:

>> (especially the unsubscribe* header) in ways that are useful to the
>> user,  and obviate the need for MLMs to mess with subject lines and
>> bodies.
>>
>> *In my view, MLMs are required in UK law to add unsubscribe information
>> in  a way that users can easily find it. The List-unsubscribe header
>> isn't  adequate, only because very few clients display it.
>

Yes, that's what I meant by 'expose in ways that are useful to the user', 
though I should have been more explicit.