Subject: Re: [ietf-smtp] Address literals

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Aug 2016 12:24:39 +0200

Thanks a lot to all who replied!

On Sun 31/Jul/2016 14:22:56 +0200 Peter J. Holzer 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.

A difference is that the delivery MTA ("receiving server") pretty much has to 
know all of the domains under which it will receive mail, while it can miss 
DNAT numbers, especially in the misconfigurational barrier case that address 
literals are designed to bypass.

>> 1. If the host can resolve the address and obtain a domain name, it can
>> replace it so as to obtain a regular mailbox.  Right?
>
> No. If a relay receives an email for <alice@[192.0.2.34]>, it cannot
> rewrite it to <[email-masked]>, just because it finds a PTR record
> «34.2.0.192.in-addr.arpa PTR example.com».
>
> Of course the receiver MTA may deliver mail for <alice@[192.0.2.34]> and
> <[email-masked]> to the same mailbox, and it might do that
> canonicalizing the domain part first. But that's local policy.

Fine.  Ned's description of what happens inside of an ADMD is clear and comforting.

I couldn't find any occurrence of the term "literal" in RFC 6409, but 
generalizing Section 8.7 "Resolve Aliases" yields that MSAs are allowed to 
rewrite them.  Now, since one cannot lookup secondary MXes of an address 
literal, an MTA getting RCPT TO:<alice@[192.0.2.34] must be either a submission 
or a delivery server.  Rewriting is allowed in both cases.

>> 2.
>
> Determining whether the MTA is the receiver is local policy. There is
> probably no general rule like "does this IP address match one of this
> host's interfaces?"

Relying on configuration settings to define a super-duper local policy doesn't 
seem to be a viable option, for a couple of reasons.  First, to avoid the 
misconfigurational oxymoron above.  Second, more flexibility brings more bugs, 
so it can hardly be afforded for a rarely used feature.

Of all the non-configured elements that a receive-or-relay decision can be 
based on, only two come to my mind:

* Does the client have relay privileges?

* Does the address literal have a reverse name?

>> 3. If in case (2) the server relays, it can either drop or keep the domain
>> part when it issues RCPT TO to its peer.
>
> No. It must not change the recipient address, and just dropping the
> domain part would in any case result in a syntactically invalid address.

My bad.  I was thinking of <postmaster@[192.0.2.34]> and failed to bring into 
the cache that, in general, local names are not accepted in the envelope. 
Rewriting with the greeting name obtained on connecting to the server would 
probably create more problems than it might solve, wouldn't it?

Any other ideas?

Ale

---

From: Tony Finch <[email-masked]>
Date: Mon, 1 Aug 2016 14:22:20 +0100

> replace it so as to obtain a regular mailbox.  Right?

I think an MTA should not use the DNS at all to handle an address
literal.

> 2. If the host cannot resolve the address, it can either try to relay it or
> try to deliver it locally.  What is the recommended behavior?

The literal either refers to one of the MTA's interface addresses, in
which case it should apply its own local rules (which might include
rejecting), or it refers to another host, in which case the MTA should
relay the message to the specified address if that is allowed.

I recommend that relaying attempts using address literals should always be
rejected, and local address literals should only allow postmaster as the
local part, and the MTA should treat it the same as bare <Postmaster>.

> part when it issues RCPT TO to its peer.  Dropping is conservative, as the
> address literal has already be used, so it won't be used again in case the
> peer is the server itself connected through a NAT or transparent proxy.

(a) don't relay :-)

(b) you should never rewrite addresses that don't belong to you

(c) if you want to make this work with NAT too then, um, why are you
    trying so hard to make something work that no-one will ever use? :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southwest Forties, Cromarty, Forth, Tyne, Dogger: Westerly or northwesterly,
becoming variable, 3 or 4. Slight or moderate. Showers. Good.