[Top] [All Lists]

Re: [ietf-smtp] Address literals

2016-07-31 08:11:42

--On Sunday, July 31, 2016 14:22 +0200 "Peter J. Holzer"
<hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:

On 2016-07-31 10:07:12 +0200, Alessandro Vesely wrote:
SMTP provides for:

    address-literal  = "[" ( IPv4-address-literal /
                     IPv6-address-literal /
                     General-address-literal ) "]"
                     ; See Section 4.1.3

    Mailbox        = Local-part "@" ( Domain /
    address-literal )

However, it is not clear how mailboxes containing an address
literal are to be treated by an MTA when they appear in the
envelope.  Specifically, I have three questions, assuming a
recipient is indicated using an address literal:

I asked a similar question about CNAME records about 2 years
ago, and the consensus was that a relaying MTA must not change
the recipients address while the receiver MTA may treat the
address any way it pleases.

I think it is safe to generalize that to address literals.

Let me say that a little more strongly: the intent of the SMTP
specs is that relays are not permitted to mess with or alter
addresses in any way.  They are strictly an issue for the
delivery (final receiving) MTA.  There are two areas of
flexibility about that (but only those two): (i) a submission
server can do whatever it needs to do to conform to sender
requirements and to ensure that addresses (and mesasges) that
are being sent out on the public Internet are SMTP-valid and
(ii) in today's world of clustered, multi-machine delivery
servers and SMTP-receivers at enterprise or other administrative
boundaries, "final delivery MTA" may need to be interpreted
somewhat liberally, but the notion is that any such server be
under the control of the receiving user or some system(s) to
which that user has explicitly delegated control.

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

 -- The local-part, even to map case, substitute
        "equivalent" characters, or mess with quoting.
 -- 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)
 -- Address literals, even to substitute
        presumably-equivalent addresses, reverse-map to domain
        names and substitute them, convert IPv4 addresses to
        IPv6 ones, etc.

The Robustness Principle does not alter the above: either the
submission server or originating MUA process gets things right,
the delivery server/process fixes it up, or the expectation
should be that the message is delivered unchanged or rejected /

I think the above is entirely consistent with Peter's responses
to the individual questions.

If 5321 is not clear enough about the above, errata submissions
and/or specific text suggestions would be welcomed.


ietf-smtp mailing list