On 7/16/13 8:46 PM, "Roland Turner" <[email protected]> wrote:
Any time an RFC and reality diverge, it it the RFC that is
reality-ignorant, not reality that is RFC-ignorant.
If it happens that the DMARC specification reflects reality better than
existing RFCs - even standards track ones - then once again, it is those
RFCs that are in error, not the DMARC specification.
I don't agree with the first generalization. RFCs specifying the format
of an Internet message have existed for a really long time. It's reality
that decided to diverge, largely out of laziness: Email generating code
would be sloppy and cut corners, and user pressure caused mail submission
agents and other services to tolerate it rather than be strict about it.
We're left with a system where lots of software now supports the lazy
implementations.
There's a draft making its way through the IETF now that describes this
situation, pleads with software to become strict once again, and then goes
into a list of common malformations and provides advice about how to
handle or interpret them. But even that advice about safe handling
doesn't render those messages compliant; they are still broken.
DMARC's acknowledgement of reality doesn't make those RFCs wrong, nor does
it excuse various components' lax enforcement of the rules.
Send dmarc-discuss mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dmarc-discuss digest..."
Today's Topics:
1. Re: multiple from (Douglas Otis)
2. Re: multiple from (Murray Kucherawy)
3. Re: options on multiple from (John Levine)
4. Re: options on multiple from (Franck Martin)
5. Re: options on multiple from (John R Levine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jul 2013 04:57:05 -0700
From: Douglas Otis <[email protected]>
To: Roland Turner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [dmarc-discuss] multiple from
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Jul 16, 2013, at 8:46 PM, Roland Turner <[email protected]>
wrote:
On 07/17/2013 12:15 AM, Douglas Otis wrote:
From a specification standpoint, it seems odd to invalidate email from
otherwise uninvolved domains that are technically RFC compliant. Wouldn't
such specifications make the DMARC specification RFC ignorant? RFC5322 is a
draft standard and RFC6854 is standards track. Requiring rejection of
otherwise valid messages is hostile to those following standards.
This viewpoint is incorrect and reflects an error in understanding that
senders frequently make.
An SMTP server (or the host that it runs on) is the property of a
receiver. When a sender offers a message for delivery, the sender is asking
the receiver to extend a delivery privilege, a privilege that the receiver
is free to decline for any reason or for no reason.
Dear Roland,
Respect the rights of receivers over that of senders? Absolutely!
There remains a need to defend receivers, and that is a clear reality.
Asserting negative reputations against questionable DKIM domains carries
significant risk because:
1) DKIM does not constrain message recipients.
2) DKIM does not constrain the initiating servers.
3) DKIM does not constrain the entire message.
4) DKIM can be replayed by design.
While DKIM is ideal for BULK senders, DKIM completely ignores what is
needed by third-parties to defend receivers.
On top of that, SPF expects receivers to make as many as 111 DNS
transactions to resolve Return Path authorizations which may include
un-cacheable macro expansions?
SPF macros are a rarely used option, when combined with DMARC, becomes an
obligatory role for receivers on behalf of senders.
To be more compliant, DMARC now wishes to couple Return Path authorization
with any number of DKIM signatures where alignment with either DKIM or the
Return Path must be determined for each of the FROM email domain(s)?
Unlike Server Authentication where XMPP offers a good and workable
example, DKIM, by its design, potentially permits abuse of receivers.
DMARC recommends acceptance using EITHER SPF or DKIM after checking policy
at domain(s) above the public suffix.
DMARC does not deal with the issue created by RFC6854 which can be easily
accommodated using the XMPP scheme of server authentication.
Add a scheme similar to that of ATPS, and this would represent a
defendable lightweight system able to defend receivers that DMARC/DKIM/SPF
is unable to accomplish. There remains a need to defend receivers this
remains a clear reality.
Regards,
Douglas Otis
------------------------------
Message: 2
Date: Wed, 17 Jul 2013 16:40:48 +0000
From: Murray Kucherawy <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [dmarc-discuss] multiple from
Message-ID:
<
c8869be93cf766409d9086a78338cee9388fd...@prn-mbx01-5.thefacebook.com>
Content-Type: text/plain; charset="us-ascii"
On 7/16/13 8:46 PM, "Roland Turner" <[email protected]> wrote:
Any time an RFC and reality diverge, it it the RFC that is
reality-ignorant, not reality that is RFC-ignorant.
If it happens that the DMARC specification reflects reality better than
existing RFCs - even standards track ones - then once again, it is those
RFCs that are in error, not the DMARC specification.
I don't agree with the first generalization. RFCs specifying the format
of an Internet message have existed for a really long time. It's reality
that decided to diverge, largely out of laziness: Email generating code
would be sloppy and cut corners, and user pressure caused mail submission
agents and other services to tolerate it rather than be strict about it.
We're left with a system where lots of software now supports the lazy
implementations.
There's a draft making its way through the IETF now that describes this
situation, pleads with software to become strict once again, and then goes
into a list of common malformations and provides advice about how to
handle or interpret them. But even that advice about safe handling
doesn't render those messages compliant; they are still broken.
DMARC's acknowledgement of reality doesn't make those RFCs wrong, nor does
it excuse various components' lax enforcement of the rules.
-MSK
------------------------------
Message: 3
Date: 17 Jul 2013 17:32:30 -0000
From: "John Levine" <[email protected]>
To: [email protected]
Subject: Re: [dmarc-discuss] options on multiple from
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
It seems to me that there is a fairly short list of ways that DMARC can
deal
with addresses with more than one address on the From line:
a) exclude them, anything with multiple addresses fails
b) if the two addresses are in the same domain, do the usual thing,
otherwise fail
c) evaluate separately, take the strictest result
d) evaluate seaparetly, take the loosest result
Fail would probably mean to apply the failure rule for each domain so a)
is in
practice pretty close to c)
I think it is reasonable to say that if you want to use DMARC, don't
use multiple addresses, since it's not a feature that is well
supported anywhere.
------------------------------
Message: 4
Date: Wed, 17 Jul 2013 18:13:58 +0000
From: Franck Martin <[email protected]>
To: John Levine <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [dmarc-discuss] options on multiple from
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Jul 17, 2013, at 10:32 AM, John Levine <[email protected]> wrote:
It seems to me that there is a fairly short list of ways that DMARC can
deal
with addresses with more than one address on the From line:
a) exclude them, anything with multiple addresses fails
b) if the two addresses are in the same domain, do the usual thing,
otherwise fail
c) evaluate separately, take the strictest result
d) evaluate seaparetly, take the loosest result
Fail would probably mean to apply the failure rule for each domain so a)
is in
practice pretty close to c)
I think it is reasonable to say that if you want to use DMARC, don't
use multiple addresses, since it's not a feature that is well
supported anywhere.
I'm not sure what fail means here?
1) bounce the email
2) dmarc test failed, so what policy to apply?
If fail means bounce the email, then it contradicts earlier RFCs where
multiple emails in From is ok (and even none at all in a recent RFC). So it
is hard to be normative here when you contradict previous RFCs. You can
only provide advice to receivers on how to handle such emails (aka BCP).
I encourage people to check their incoming mail streams and identify
emails with multiple addresses in From: and check which ones are valid
constructs or more caused by a buggy (or lazy as Murray said) MTA.
------------------------------
Message: 5
Date: 17 Jul 2013 14:59:22 -0400
From: "John R Levine" <[email protected]>
To: "Franck Martin" <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [dmarc-discuss] options on multiple from
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
a) exclude them, anything with multiple addresses fails
b) if the two addresses are in the same domain, do the usual thing,
otherwise fail
c) evaluate separately, take the strictest result
d) evaluate seaparetly, take the loosest result
Fail would probably mean to apply the failure rule for each domain so
a) is in
practice pretty close to c) ...
I'm not sure what fail means here?
1) bounce the email
2) dmarc test failed, so what policy to apply?
Um, it means what I said it means in the message you quoted.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
------------------------------
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well
terms (http://www.dmarc.org/note_well.html)
End of dmarc-discuss Digest, Vol 19, Issue 7
********************************************
