On 8/17/2017 4:09 AM, Bron Gondwana wrote:
On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
<br...@fastmailteam.com <mailto:br...@fastmailteam.com>> wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMARC
p=reject aware, you can't use ARC on a DMARC p=reject domain
without rewriting the sender. Otherwise that site will bounce the
email.
Goodness, it's a wonder that we've ever successfully deployed
anything incremental around here. ;-)
-MSK
I laugh as well, but it's more than p=reject isn't enough in the ARC
world, because it doesn't distinguish between:
a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should
never appear in ARC chains that don't also pass DKIM.
You assume that mailing lists are the only corner case that ARC might
address. It’s quite possible that this is not true. It's also not clear
what you mean by "direct messages". When an agent does an MX lookup, it
has no way of knowing whether the indicated MX host is the final
destination or whether there are additional internal (to the
administrative domain) or external hops beyond the initially indicated
MX host. That's one of the things that makes the wonderful wacky world
of email so interesting. While mailing lists are important to many, they
are the tail and not the dog in the email world.
The existing behaviour of p=reject is (b) for receivers that don't
support ARC - so the question becomes: are we defining ARC to
changing the behaviour of p=reject to (a)? If so, will we define a
different (b) later, when we could instead have
defined a different p= for (a).
This is absolutely an incorrect statement. Policy within DMARC, as
expressed by p=, is a request by the sending domain and can always be
ignored or overridden by local policy. Using ARC as an input is no
different than any other input that a mailbox provider/validator
considers in making delivery decisions.
The interesting question is what happens at non-updated sites in each
case, because the answer is either "valid emails that should have been
accepted are rejected by old policy engine" or "spoofed emails that
should have been rejected are accepted by old policy engine"
In the DMARC world, emails are only valid in the sense that they pass
either SPF or DKIM validation. A decision to accept or reject any given
email involves many choices beyond simply passing DMARC validation for a
given from domain. Spoofing may involve emails which pass DMARC
validation but contain spoofing in the From display name, or any number
of other ways.
Mike
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
