[Top] [All Lists]

Re: [ietf-smtp] Address transformations

2016-07-31 10:33:45

--On Sunday, July 31, 2016 13:35 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:

That means --as examples, not a comprehensive list-- that
relays MUST NOT alter: ...

-- The domain-part, even to substitute names that are
     believed to be equivalent, convert from A-labels and
     U-labels or back (or to try to substitute "variants" or
     apply case or other mappings, including normalization)

How about resolving CNAMEs?  That's been kind of ambigous in
the past, particularly back when there was a widespread
assumption that CNAMEs were just temporary forwards while
people updated their address books and bookmarks.


If by "resolving CNAMEs", you mean doing DNS resolution to
obtain A or MX records to figure out where to open a connection
to direct the message next, then absolutely, and the "final
names" language in 5321 is quite explicit about that.   If you
mean "once the results of that resolution are obtained, rewrite
the domain-part of the relevant address before issuing a command
that contains that address, my recollection is that we made a
clear decision in DRUMS to not allow that.   The reason was the
other side of the above -- that with IN CNAME IN MX 0

there might be a reasonable expectation that
user(_at_)foo(_dot_)example(_dot_)com and user(_at_)bar(_dot_)example(_dot_)com 
might go to
different mailboxes or at least through different filters.

As a matter of good (or "best") practices, I'd much prefer to
see IN MX 0 IN MX 0

rather than the above, just as I would rather, for many reasons,
never see another address literal (consistent with your earlier
comment about things one would want to deliver), but that isn't
an SMTP problem until and unless someone starts writing and
promoting BCP or A/S documents that define and require such

At least IMO, the fundamental problem is that, for various
reasons, we've developed a variety of different, and
not-quite-consistent, assumptions about what DNS aliases are for
or about.  Those aasumptions are not quite consistent.   They
include the "temporary forwards" model you mention above,
notions of fairly-permanent "short" or alternate names (a
concept that really comes from the host table format and that
predates temporary-anything), and a number of ideas about
alternate expressions or orthography for labels or subtrees that
are considered the same (e.g., RFC 3743 variants).   However,
those are really DNS issues, not SMTP ones, and the best thing
SMTP can do is to avoid rewriting address strings.


ietf-smtp mailing list