Subject: [ietf-smtp] Address literals

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Jul 2016 10:07:12 +0200

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:

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?

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?

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.  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.  OTOH, dropping 
precludes another rDNS attempt, which could work at the peer if its internal 
DNS view provided for an rDNS delegation which was not granted globally.  To 
drop or not to drop?

TIA

Ale
--

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 31 Jul 2016 14:22:56 +0200

On 2016-07-31 10:07:12 +0200, Alessandro Vesely wrote:
> 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.

> 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.

> 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?

In any case the MTA needs to determine whether it is the receiver or a
relay. If it is the receiver it must try to deliver it locally (of
course "local delivery" might result in forwarding the to a different
address).
Otherwise it must relay it by connecting to the specified address.

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?"

> 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.

        hp

-- 
   _  | Peter J. Holzer    | A coding theorist is someone who doesn't
|_|_) |                    | think Alice is crazy.
| |   | [email-masked]         | -- John Gordon
__/   | http://www.hjp.at/ |    http://downlode.org/Etext/alicebob.html

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 Jul 2016 09:11:30 -0400

--On Sunday, July 31, 2016 14:22 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

>> 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.
> 

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 /
bounced.

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.

     john

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2016 13:29:35 -0000

>address while the receiver MTA may treat the address any way it pleases.

Yes.  On the other hand, on today's internet, if you get mail sent to
an address literal other than 127.0.0.1, the chances of it being something
you want to deliver are so low that I wouldn't worry about it, and I'd
just reject or discard it.

R's,
John

PS: I was going to say that I might make an exception for status messages
from IoT devices, but anything with enough software to do SUBMIT has enough
software to configure a DNS name.

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2016 13:35:47 -0000

>MUST NOT alter: ...

>	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.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 Jul 2016 11:33:25 -0400

--On Sunday, July 31, 2016 13:35 +0000 John Levine
<[email-masked]> wrote:

>> That means --as examples, not a comprehensive list-- that
>> relays MUST NOT alter: ...
> 
> 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.

John,

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 
    foo.example.com. IN CNAME bar.example.com.
    bar.example.com. IN MX 0 smtpserver.example.com.

there might be a reasonable expectation that
[email-masked] and [email-masked] 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 

    foo.example.com. IN MX 0 smtpserver.example.com.
    bar.example.com. IN MX 0 smtpserver.example.com.

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
preferences.

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.

    best,
     john

---

From: Ned Freed <[email-masked]>
Date: Sun, 31 Jul 2016 08:39:51 -0700 (PDT)

> > address while the receiver MTA may treat the address any way it pleases.

When does this case even arise? If I relay on a message to an address involving
some random IP literal, that's pretty much the definition of an open relay. So
that's going to be blocked, and if it isn't, you have a problem that
transcends address rewriting issues.

In fact about the only relay case left that crosses between ADMDs is
secondary MXes, and that doesn't apply to IP address literals by definition.

And as for what happens inside of an ADMD, I'm afraid I really don't give a
damn what the standards say should or should not be done to addresses involving
IP addresses within my own infrastructure. I'll forward with rewriting, bounce,
discard, or do whatever I like with them as I choose. And my choices will
almost certainly be driven by security considerations more than anything.

> just reject or discard it.

Exactly.

> software to configure a DNS name.

Indeed. If an IoT device wants to send a status message, you have to be able to
configure an address as part of that. So even if you don't have a DNS stub
resolver, you simply have "IP address of SUBMIT server" instead of "name of
SUBMIT server" parameter. In neither case does it avoid the need to have an
"address to send to" parameter.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 31 Jul 2016 12:21:50 -0400

> obtain A or MX records ...

No, I meant this part of RFC 1123:

       5.2.2  Canonicalization: RFC-821 Section 3.1

          The domain names that a Sender-SMTP sends in MAIL and RCPT
          commands MUST have been  "canonicalized," i.e., they must be
          fully-qualified principal names or domain literals, not
          nicknames or domain abbreviations.  A canonicalized name either
          identifies a host directly or is an MX name; it cannot be a
          CNAME.

I think we all agree that was a mistake, and CNAMEs are fine in MAIL and 
RCPT and you shouldn't mess with them, but I can't find any place this 
advice has been explicitly deprecated.

R's,
John

PS: Even 5321 says the EHLO argument can't be a CNAME.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 31 Jul 2016 18:31:11 +0200

On 2016-07-31 08:39:51 -0700, Ned Freed wrote:
> When does this case even arise?

Pretty rarely, I guess. And it should almost always be avoidable.

> If I relay on a message to an address involving some random IP
> literal, that's pretty much the definition of an open relay.

I don't think it makes a difference whether the relay relays to random
domain names or random ip addresses. Outbound MTAs are generally
expected to send mail anywhere. But they aren't open because they
restrict who can send.

> secondary MXes, and that doesn't apply to IP address literals by

Well, I could subscribe to this list as
<hjp-ietf-smtp@[2001:15c0:65ff:8763::d]>. I bet I would get less spam at
this address than at <[email-masked]> ;-). Not sure whether the
mailing list software would handle that, though.

> discard, or do whatever I like with them as I choose.

Right. 

        hp

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 Jul 2016 14:17:10 -0400

> 	The domain names that a Sender-SMTP sends in MAIL and
> 	RCPT commands MUST have been  "canonicalized," i.e.,
> 	they must be fully-qualified principal names or domain
> 	literals, not nicknames or domain abbreviations.  A
> 	canonicalized name either identifies a host directly or
> 	is an MX name; it cannot be a CNAME.

> I think we all agree that was a mistake, and CNAMEs are fine
> in MAIL and RCPT and you shouldn't mess with them, but I can't
> find any place this advice has been explicitly deprecated.

Try Section 2.3.5 of RFC 5321 (or its predecessor in 2821, which
was a tad less explicit):

# Only resolvable, fully-qualified domain names (FQDNs) are
# permitted when domain names are used in SMTP.  In other
# words, names that can be resolved to MX RRs or address
# (i.e., A or AAAA) RRs (as discussed in Section 5) are
# permitted, as are CNAME RRs whose targets can be resolved,
# in turn, to MX or address RRs.  Local nicknames or
# unqualified names MUST NOT be used.  There are two

> PS: Even 5321 says the EHLO argument can't be a CNAME.

Yes, that is the bulleted first exception pointed to above.

With apologies to those with whom I just went through this on
another list, the only ambiguity I can find in that is whether
CNAME chains, e.g., 

      a.example.com.  CNAME b.example.com.
      b.example.com.  CNAME c.example.com.
      c.example.com.  MX 0 smtp.example.com.

is permitted    My sense is that it would be at least, a dumb
practice even if the above text does not prohibit it.  But I
think the intent of the above-quoted text is, in fact, to
prohibit it or at least to justify SMTP clients and servers
treating the situation, if encountered, harshly.

Section 1.2 of RFC 5321, second full paragraph, is also fairly
explicit about its relationship to RFC 1123 mail transport
material.  So, with the CNAME chain question as a possible
exception, I think we really did manage to be explicit enough in
this particular case.  YMMD, in which case specific suggestions
for what needs to be fixed and how to fix it would be welcome.

best,
    john

---

From: "John R Levine" <[email-masked]>
Date: 31 Jul 2016 14:32:03 -0400

> for what needs to be fixed and how to fix it would be welcome.

Putting on my nitpicky lawyer hat, I note that RFC 1123 is a full 
standard.  RFC 2821 is a proposed standard obsoleted by RFC 5321 which is 
a draft standard which updates but does not obsolete 1123.

So my reading is that while 5321 tells me that it's OK to use a CNAME in 
MAIL FROM/RCPT TO, 1123 still tells me that it's better to resolve those 
CNAMEs first.

I hope that nobody who matters believes this, but if you look at the two 
documents it's not a totally ridiculous way to reconcile them.  Should we 
open up 5321 again, I think a sentence specifically revoking the CNAME 
advice in 1123 wouldn't hurt.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 Jul 2016 16:14:11 -0400

--On Sunday, July 31, 2016 14:32 -0400 John R Levine
<[email-masked]> wrote:

>>> in MAIL and RCPT and you shouldn't mess with them, but I
>>> can't find any place this advice has been explicitly
>>> deprecated.
>> 
>> Try Section 2.3.5 of RFC 5321 (or its predecessor in 2821,
>> which was a tad less explicit):
> 
>> this particular case.  YMMD, in which case specific
>> suggestions for what needs to be fixed and how to fix it
>> would be welcome.
> 
> Putting on my nitpicky lawyer hat, I note that RFC 1123 is a
> full standard.  RFC 2821 is a proposed standard obsoleted by
> RFC 5321 which is a draft standard which updates but does not
> obsolete 1123.

Putting on a similar hat, there is a wart (actually a
wart-epidemic) in the IETF "obsoletes/updates" language and
definitions wrt these cases.  First, it has never been clear
whether a Proposed (or even Draft) Standard can obsolete or even
update a full Standard.  If the answer is "no", then I hope
everyone is still supporting explicit routes and the VRFY
command because, IIR, 821 requires them.  Second, there is no
mechanism at all for identifying a replacement for a section (or
set of sections) of a document and marking them obsolete.   The
sentence from 5321 that says "It obsoletes RFC 821, RFC 974, RFC
1869, and RFC 2821 and updates RFC 1123 (replacing the mail
transport materials of RFC 1123)." is, I contend, crystal-clear
as to intent.  But, if you argue, as the above implies, that
such a statement is invalid on its face because 5321 is only a
Draft Standard --or that "replacing the mail transport
materials..." cannot be considered as equivalent to obsoleting
those sections, my reaction isn't to disagree but to find other
ways to spend my time.

> So my reading is that while 5321 tells me that it's OK to use
> a CNAME in MAIL FROM/RCPT TO, 1123 still tells me that it's
> better to resolve those CNAMEs first.

See above and note that the sections of 1123 that tell you that
are among those presumably-replaced mail transport material.

> I hope that nobody who matters believes this, but if you look
> at the two documents it's not a totally ridiculous way to
> reconcile them.  Should we open up 5321 again, I think a
> sentence specifically revoking the CNAME advice in 1123
> wouldn't hurt.

See "warts" above.   The assumption in writing 5321 was that
"replacing the mail transport materials..." did specifically
revoke (a word that is not in the IETF standards status
vocabulary) anything about mail transport that 1123 says that is
inconsistent with 5321.   Certainly it is possible to read it in
other ways, but most of them lead to silly states (or at least
wart-infections or outbreaks).

For anyone who is curious, the near-certainty that we would need
to spend significant time on such status arguments has been a
major reason why the working drafts of 5321bis have not been
posted since, IIR, one snapshot around six years ago.  I have
significant doubts that the community really has the energy to
work through the technical issues and text to settle on 5321bis
and presumably advance it to Full Standard.  I am almost
positive that there is insufficient energy to engage in a
"status of documents" debate at the same time.  I am certain
that _I_ don't have the energy.

    john

---

From: Sean Leonard <[email-masked]>
Date: Sun, 31 Jul 2016 19:14:47 -0700

> On Jul 31, 2016, at 9:31 AM, Peter J. Holzer <[email-masked]> wrote:
> 

Probably (mailing list software would not handle that), because that is not even valid syntax (to say nothing of the other RFC 5321 text).

It should be:
<hjp-ietf-smtp@[IPv6:2001:15c0:65ff:8763::d]>

See RFC 5321 section 4.1.3.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Sun, 31 Jul 2016 19:25:23 -0700

(RFC 5321)
All this stuff brings up a very interesting point about deliverable email addresses in draft-seantek-mail-regexen:

What are the domain part limitations on deliverable email addresses, that are not encapsulated by the RFC 5321 ABNF?

Specifically:
The domain production is limited to 253 characters. I am sure of this.
Each sub-domain production is limited to 63 characters. I am also sure of this.

I strongly believe that domain productions cannot be parseable IPv4 addresses. (Note: they can never be parseable as IPv6 addresses, as that would require : which is not part of a domain production.)

Consider:

[email-masked]

The string “1.2.3.4” is a valid domain production. However, it is not (or *should not*) be considered a deliverable email address, because when passed to the famous function “gethostbyname”, that function will certainly return 1.2.3.4; it will not perform a lookup of the domain record with a top-level label of “4”. This is also supported by RFC 1912: “Labels may not be all numbers”. But an individual label can be a number, such as “411.org”.

I have tried “[email-masked]” -- Windows and Unix/Linux stacks will try to query the DNS for that string and not parse it as IPv4. So, it is syntactically a valid, deliverable email address. But foo@411 will get IPv4-parsed to 0.0.1.155, which means that “411” should not be considered a valid domain name for a deliverable email address.

True? Are there other limitations?

Sean