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 <alice(_at_)example(_dot_)com>, 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
<alice(_at_)example(_dot_)com> 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp