Read all about it:
https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/
This is an updated version of a draft I wrote two years ago, that tries to nail
down the small changes to SPF, DKIM, and DMARC in EAI messages. This version
adds a section for the Authentication-Results header.
What it mostly says is that wherever you can have a domain name in a mail
message header it can be a U-label, and wherever there's a mailbox, the local
part can be UTF-8, while stuff in the DNS doesn't change and domains there are
A-labels, same as always. It's intended to be utterly unsurprising, but there's
enough ambiguity and well-intended bad advice in existing RFCs that I think this
is worth doing.
The interaction of this with downgrading as specified in RFC 6857 and RFC 6868
is ... interesting.
Downgrading a u-label to an a-label is of course the obvious thing to do, and
is what RFC 6857 specifies. But the handling of an non-ASCII local-part, while
specified, seems to assume that the syntax allows the insertion of a
group construct, which I don't think is allowed here. So this is a new
case for the RFC 6857 approach. I guess we could opt for an encoded-word ;-)
RFC 6858's approach of inserting an invalid local-part and/or domain
seems fairly unattractive for the domain-only case, but it does cover
all the cases here.
Anyway, I guesss I'm going to have to teach my downgrade code how to process
Authentication-Results fields one way or the other. Oh well.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp