Yes, they are not downgraded in transit. I improved the solution section
in "receivers", but I realize the description of the problem is not
accurate. Fixing (and see below).
Really, there is no problem. DMARC works fine on EAI mail. Just delete
the section.
I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole
use as you describe it above. I wish it would say so. An MTA that has an
EAI message that tries to pass it to an MTA that do not support SMTPUTF8
will bounce the message.
Correct.
The MUA or MSA or user may then decide to change the message and use the
group syntax to transmit it to an non-EAI environment if it has a normal
email address to send to.
No. That is completely wrong. Nowhere in the EAI documents does it
contemplate that, and no mail system I know does that. If someone is
going to send ASCII mail, the only sane way to do so is to use an ASCII
From: address to which the recipient can reply. We do expect MUAs to be
configured with an EAI address for recipients that can handle it and an
ASCII address for recipients that can't.
There may be Chinese systems that try different addresses, but since it's
at the sending end, it's up to them to know what addresses they can use
and to send valid mail.
Even in your case when the MDA/MS gets such message with group-syntax
and forwards it, then an MTA will have to deal with it.
No. No, no no. The dowmgrade is only for POP/IMAP retrieval to non-EAI
clients, not anything else. If it's forwarded by sieve or the like, it'll
forward the original EAI message.
Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not
like to have a message with an RFC5322.From header field with no valid
domain in it.
Please don't invent stuff. In any event, the unlikely possibility that
someone might send mail with an empty From: group has nothing to do with
EAI or forwarding or anything else.
In the first long paragraph in 4.1.3.3, at this point I don't know
anyone adding .INVALID, but I know people rewriting the From: address
to a different valid address that forwards to the real author. Some
people do it the way I do, e.g. mari...@yahoo.com.dmarc.fail, or
LISTSERV invents a pseudo-random address in the list's domain.
You used to do it no? Anyhow this is just an example of suffix to use.
I think there is an important difference between invalid addresses and
valid ones.
The LISTSERV solution is a derivative of rewriting the RFC5322.From
header field to use your own domain. Not sure if we should describe it
too?
It's different because the address in the From: line is (indirectly) still
the real author, not the list.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
