----- Original Message -----
> From: "John Levine" <jo...@taugh.com>
> To: dmarc@ietf.org
> Cc: t...@eudaemon.net
> Sent: Monday, February 2, 2015 6:31:11 PM
> Subject: Re: [dmarc-ietf] interoperability draft for review
>
> 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.
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 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 u...@computer.org 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.
ok
>
> 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.
>
Ned spoke about it
> 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.
same as above
>
> 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.
>
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.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
