Subject: Re: [dmarc-ietf] interoperability draft for review

From: [email-masked]
Date: Sun, 01 Feb 2015 17:58:10 -0800 (PST)

> Hi all,

> Frank, Eliot, and myself have finished up a first cut at the WG’s 1st real deliverable:
> 	• Document describing interoperability issues with DMARC and indirect mail flows and possible methods for addressing them.

> Please review at your convenience and submit comments, feedback, and suggestions for text to this list.  Frank and/or Eliot will be folding in edits.  A serious effort to cast issues in the language of RFC 5598 was made.

> Find it here:  https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

> Our aim is to have this document ready for publication by end of February.

<chair hat off>

A few quick comments:

The introduction classifies message transformations as a type of indirect mail
flow. This takes a little getting used to, to say the least. For example, if
someone's mail always traverses a relay which incorporates boundary filtering
functionality that breaks DKIM signatures, and this in turn prevents them from
performing DMARC checks, you may have a hard time convincing them that there's
anything "indirect" about the path.

Of course it all works if you define "indirect" as anything more complex than
an agent that incorporates a DKIM signer sending directly to the agent that
verifies the signature. (And even this could involve a transport encoding
change that breaks a DKIM signature.) I admit there's some temptation to define
things this way - but do we really want to go there?

There also really needs to be a distinction made between indirect paths that
involve final delivery and subsequent resubmission and those that do not. I for
one don't have much expectation that if I resend a message that's been
delivered to me without changing the From: field that it will pass muster.
Message that fail because of the involvement of a simple alias are another
matter. 

The last sentence in section 2.1 doesn't really make sense to me. There is no
problem with having multiple SPF records point at the same server IP address or
addresses, so multiple mail streams are not issue. Of course this doesn't
make this sort of thing a good idea. Selecting the host name for use in
HELO/EHLO do that SPF checks will pass, while theoretically possible, is
entirely contrary to the purpose of the parameter and thus bad operational
practice. Indeed, I have to question why this is in the draft.
Are people actually doing this?

Section 2.2 is incorrect in regards to how SPF mismatches on forwarders occur.
Essentially all forwarders change the 5321.HELO/EHLO, but simple alias exansion
usually does not change the 5321.MailFrom. In these cases the issue isn't that
the 5321.MailFrom doesn't match the 5322.From, but rather that the SPF check
may fail because the list of allowed IPs does not include the forwarder.

Section 2.3 needs considerable expansion, and needs to talk about the
differences between simple and relaxed canonicalization.

3.1.2.1 conflates at least two different meanings of the word encoding.
Further, only changes to the transport encoding fall under the purview 
of an MTA; charset transcoding is a gateway function and needs to move
to the proper section for that.

3.1.2.2 ismispositioned. An MTA that modifies, adds, or removes content isn't
just an MTA, it's also performing the function of a gateway, boundary filter,
mediator. etc. And once you get into such functions, AS/AV checks are but one
possible action among many.

I guess my suggestion would be to talk about AS/AV checks and message
modification under boundary filter. That's where RFC 5598 positions such
things. (I note in passing that a brief mention of AS stuff is already in
section 3.2.5. Merging this section in there seems like a good idea to me.)

I also don't see how outright blocking is relevant to the matter at hand. Sure
boundary filters reject or discard messages all the time, but how are such
cases relevant to DMARC interoperability? DMARC validation can't fail for a
message that never made it to the validator.

Section 3.1.2.3 "invalide" -> "invalidate"

In section 3.1.3, Sieve is in no way limited to messing around with headers.
For example, sieve extensions exist that can delete or modify message parts.

That said, since Sieve operates on or around the time of final delivery, such
modifications are supposed to be happening at a point past where DMARC checks
have been performed. It's only when messages are reintroduced into the
transport infrastructure with the same From: field that issues may arise, and
this needs to be noted.

What is the first sentence of section 3.2 supposed to mean?

Section 3.2.3 really needs to talk about why mailing lists perform the message
modifications they typically perform.

I don't believe the use of X-Original-From is described in any RFC currently.
If we're going to talk about it in section 4.3 we need to talk about how
it's actually used or refer to some place that does.

The Internet is a big place, and none of us are in a position to fully assess
the state of play in every nook and cranny out there. As such, I'm very
reluctant to make statements like "there is very little reason to modify the
encoding of a message". What if there are good reasons to somwhere? Do we 
really want another round of the charset wars in this context?

And as for transport encodings, like it or not, the standards say that if 
you're in possession of an 8bit message and the system you're sending it
to doesn't support 8bitMIME, you either downgrade or bounce. Of course you
can argue that this is obsolete, but do we really want to open this 
particular can of worms in this document?

And on a similar note, try selling what 4.4.1.2 says to a financial institution
that is bound by laws saying what must be and cannot be in the messages it
emits as well as what's inbound messages destined for employees. I'm sure
they'll find it amusing.

That's it for now.

</chair hat off>

				Ned

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2015 02:31:11 -0000

In addition to other comments:

Section 3.1.2.3 is just wrong.  EAI specifically does not allow for
downgrading of messages in transit from UTF-8 headers to ASCII
headers.  The only place the header downgrade is allowed is when a
non-EAI MUA picks up mail via POP or IMAP, but that would be long
after any DMARC tests were applied.  You were probably confused
because the early experimental version of EAI did allow downgrades in
transit, but they worked so poorly that we took them out of the
standards track version.

One place it might happen is when mail is relayed through a mailing
list, but that's really the same issue as any other modifications a
mailing list makes to mail that passes through it.  See RFC 6783.

In section 3.2.1, there are certainly vanity domains (I have lots of
them) but I think you're more referring to stable addresses from
professional associations or alumni associations, e.g., I will always
be [email-masked] regardless of where I get my mail.  Some
rewording would likely help to clarify what you're talking about, and
the fact that most of them do not offer MSAs but expect you to use the
one provided by your current mail system.

In 4.4.1.1 the main reason to recode is if a message arrives via an
8BITMIME channel and leaves via a 7 bit channel so it has to change
from 8bit to quoted-printable or base64.  Every curent MTA can handle
8BITMIME but there are still a fair number of dusty old ones.

Section 4.4.1.3 is wrong for the same reason that 3.1.2.3 is wrong.
If you send an EAI message, it'll either be delivered as EAI or
bounce.  There is some ambiguity about what a DKIM signature on an EAI
message would look like (is the domain in d= a U-label or A-label) but
they should not be a big deal to work out.

In section 4.5.1, another mailing list workaround is to rewrite the
From: address into another address with an aligned signature that
forwards to the original address.  LISTSERV does this by rewriting to
some random looking address in the list's domain, I do it by appending
a local domain such as DMARC.FAIL.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Feb 2015 02:33:57 -0600 (CST)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Monday, February 2, 2015 6:31:11 PM
> Subject: Re: [dmarc-ietf] interoperability draft for review
> 

Yes not in transit, but the downgrade is likely to happen at the source be it the human or the MUA (I have not seen an implementation of such yet and I do have an EAI). Reworded to be clearer.

> one provided by your current mail system.

ok

> 8BITMIME but there are still a fair number of dusty old ones.
Ned spoke about it

> they should not be a big deal to work out.

same as above
> a local domain such as DMARC.FAIL.
Do we really want to create a non existing domain, without standardization? It is a bit the same as the group syntax, it just remove information to assess email reputation. I think this is not cool in these days of serious breaches due to email attacks.

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Feb 2015 02:33:52 -0600 (CST)

----- Original Message -----
> From: [email-masked]
> To: "Tim Draegen" <[email-masked]>
> Cc: "dmarc" <[email-masked]>
> Sent: Sunday, February 1, 2015 5:58:10 PM
> > 	• Document describing interoperability issues with DMARC and indirect mail
> > 	flows and possible methods for addressing them.
> 
> > Please review at your convenience and submit comments, feedback, and
> > suggestions for text to this list.  Frank and/or Eliot will be folding in
> > edits.  A serious effort to cast issues in the language of RFC 5598 was
> > made.
> 
> > Find it here:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
> 

at ESPs or domain hosters, dedicated IP address often comes at a premium, if possible. At google/microsoft/... email domain hosting, you get the google/microsoft/... hostname not something in your own domain. (if not mistaken)

> may fail because the list of allowed IPs does not include the forwarder.

I think we speak of something else here the alignment, but your point is valid too. Adding some text.

> differences between simple and relaxed canonicalization.

done

> to the proper section for that.

done

> section 3.2.5. Merging this section in there seems like a good idea to me.)

merged

> transport infrastructure with the same From: field that issues may arise, and

done

> What is the first sentence of section 3.2 supposed to mean?

that we stole some text.

> modifications they typically perform.

done

> it's actually used or refer to some place that does.

it is RFC5703

> really want another round of the charset wars in this context?

Like the blue ribbon ASCI footer? :P

In my personal experience when I pointed that an MTA was doing encoding and therefore breaking DKIM, the option was removed, nobody came back to me and said I cannot do that.

toning down the language nevertheless

> particular can of worms in this document?

well, in this day and age with security vulnerabilities every week, how far do we have to support legacy mail systems?

> emits as well as what's inbound messages destined for employees. I'm sure

I think we had in mind the AV that adds "scanned by Great AV, you should buy it".

Can you give some samples of what you have in mind?

I suppose a financial institution would add a disclaimer on all emails, but before DKIM. Also I don't think they would operate a mailing list or forwarder lightly...

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Feb 2015 02:40:59 -0600 (CST)

Latest diff is at https://github.com/dmarc-ietf/id/commit/d7b1a401f3c171c27df926bd6a0c5a2ba06eec9b

May be the xml diff (at then end) is best to read. Github is not very nice with RFC formatting...

---

From: "John R Levine" <[email-masked]>
Date: 10 Feb 2015 16:52:13 +0800

>> headers.  ...

> Yes not in transit, but the downgrade is likely to happen at the source 
> be it the human or the MUA (I have not seen an implementation of such 
> yet and I do have an EAI). Reworded to be clearer.

That makes no sense.  If you send mail to a different address, that's what 
will get signed and it has no DMARC issues.

> Do we really want to create a non existing domain, without 
> standardization? It is a bit the same as the group syntax, it just 
> remove information to assess email reputation. I think this is not cool 
> in these days of serious breaches due to email attacks.

Again, that makes no sense.  I'm not aware of anyone advocating a "non 
existing domain."  Could you explain what you mean here?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Feb 2015 09:43:52 -0800

> > it's actually used or refer to some place that does.

That's Original-From, so I guess just mention that the X- version was the
pre-standardization name and might still be in use in some places.

Aside: I'm surprised that RFC5703 doesn't include the registration template
required by RFC3864.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Feb 2015 13:02:57 -0600 (CST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "Tim Draegen" <[email-masked]>, "dmarc" <[email-masked]>,
> [email-masked]
> Sent: Tuesday, February 10, 2015 9:43:52 AM

> On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin < [email-masked] >
> wrote:

> pre-standardization name and might still be in use in some places.

I'll check the text but there is something like this. 

> Aside: I'm surprised that RFC5703 doesn't include the registration template

It is listed here: https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers