(chair hat off)
> >Please submit "stuff" that needs to be fixed
> The worst problem is still section 3.1.2.3 which needs to be deleted,
> since most of what it says is wrong, and what little isn't wrong is
> irrelevant.
> RFC 6854 is not about EAI, since an ASCII MUA can create mail with an
> empty group From: as easily as an EAI MUA. The assertion that RFC
> 6854 allows empty groups "during the transition period to SMTPUTF8" is
> false.
RFC 6854 does mention EAI, but only as one of its possible uses. The primary
stated use is for "utomated systems that wish to send email but cannot handle
replies".
> Empty group syntax has nothing to do with DMARC since there is no
> domain on the From: line to check. From a DMARC point of view, there
> is no difference between a From: with an empty group and one with an
> address in a domain that publishes no DMARC record.
Agreed.
> This sentence is completely false. EAI MTAs never downgrade mail in transit:
> If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
> aware MTA, the EAI/SMTPUTF8-aware system may transform the
> RFC5322.From header field of the message to include group syntax to
> allow the non-aware MTA to receive the email.
Specifically, this sort of downgrading is only defined in the context of an
EAI-aware POP or IMAP server returning a message to a non-EAI-aware client.
While it's true that such a message can be resubmitted to the transport
infrastructure, at that point its a new message, with all that implies.
An MTA performing such a downgrade in the context of handling EAI mail is
engaging in an egregious standards violation. Talking about such standards
violations is an interoperability document is fine, but (1) The standards
violation aspect needs to be made clear and (2) There needs to at least some
evidence that such things are happening on a wide enough scale to care about.
As such, I agree with John: This section needs to be deleted.
> Section 4.1.2.3 is equally wrong for the same reasons and also needs to go.
Agreed.
> Section 4.1.3.1 doesn't mention rewriting the From: address to a valid
> forwarding address in a domain for which the list can sign. It's not
> just me doing it, LISTSERV can do that, it's widely implemented.
Our list server supports it as well, and it is being used this way. So: Agreed.
> Take
> out .invalid, nobody does that because (as I discovered and you
> mention) many spam filters dislike From: addresses with domains that
> don't resolve.
I don't mind mentioning .invalid as long as the problematic nature of
using this mechanism is made clear.
Ned
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
