Subject: [Emailcore] Comments on -09

From: "John R Levine" <[email-masked]>
Date: 5 Feb 2022 23:13:51 -0500

In 2.4:

     A few SMTP servers, in violation of this specification (and RFC 821)
     require that command verbs be encoded by clients in upper case.
     Implementations MAY wish to employ this encoding to accommodate those
     servers.

Is this still true?  It seems harmless but I cannot recall seeing an MTA 
that cared about command case in this millenium.

In 3.3:

     Restricted-capability
     clients MUST NOT assume that any SMTP server on the Internet can be
     used as their mail processing (relaying) site.

I would take that out.  I assume that what it meant by 
restricted-capability is what we now call submission.

In 3.4.2:

Now that I look at it again, I'm inclined to rip out almost the entire 
section and just say (perhaps as part of 3.4.1) that it is possible to 
forward one address to several, known as expanding or exploding, and that 
broadcast and discussion lists are typically managed by mailing list 
software that is beyond the scope of this spec.

The A/S can say something about when you change the bounce address while 
forwarding, with the advice that the goal is to get the bounces to someone 
or something that can act on them.

In 3.6.1:

     A relay SMTP server is usually the target of a DNS MX record that
     designates it, rather than the final delivery system.

I can't tell whether this is talking about a secondary MX or a large mail 
provider which uses separate gateway and delivery servers or what.

In 4.2.4.2 on Null MX:

     If, despite publishing
     the DNS entry, the server domain chooses to respond on the SMTP port,
     it SHOULD respond with the 556 code as well.

If I publish a null MX, what could have an SMTP port?  The DNS root 
doesn't have an A record.  The only part of 7505 not covered here is the 
enhanced codes to use, not sure what to do about that.

In 4.5.1:

Does it still make sense to include VRFY in the minimal list of commands? 
Nobody responds with anything other than 252 (or 502 if you're Yahoo) any 
more.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Feb 2022 11:22:19 +0100

Hi,

On Sun 06/Feb/2022 05:13:51 +0100 John Levine wrote:
> forward one address to several, known as expanding or exploding, and 
> that broadcast and discussion lists are typically managed by mailing 
> list software that is beyond the scope of this spec.

I think a distinction between /internal/ aliasing and forwarding to 
the public Internet can be worth.

> The A/S can say something about when you change the bounce address 
> while forwarding, with the advice that the goal is to get the bounces 
> to someone or something that can act on them.

Agreed, except that this actionability advice is such an important 
principle that deserves being published in 5321bis.

Rather than developing a minimal taxonomy of forwarding cases, the 
spec could state important principles like the above, which govern 
envelope data, and just mention some of the possible semantics of 
forwarding that determine their different handling.  For example, role 
aliases, secret addresses, vanity addresses, trash addresses, as well 
as discussion lists, newsletters, graymail and spam.

Best
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 6 Feb 2022 12:57:55 +0000

On 06/02/2022 04:13, John R Levine wrote:
> If I publish a null MX, what could have an SMTP port?  The DNS root doesn't have an A record.

My guess is that it's handling the situation of a sending MTA
spotting the null MX explicitly, ignoring it, and proceeding
to try the A for the domain.

Or never looking for an MX.
-- 
Cheers,
   Jeremy

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Feb 2022 11:05:01 -0500

> Or never looking for an MX.

John,

Yes.  Look at it from the standpoint of a server that is being
extra-cautious and whose implementers assume that support for
null MX in clients is not [yet] universal.   So, consider two
possible cases...

(1) Client is not only pre-RFC 7505 but pre-RFC 974, e.g., some
embedded thing that has not been updated to understand MX
records at all, much less conformance to 5321bis.   (I hope
there are few, if any, of those left.)  

(2) Client author has not read 7505, does a DNS lookup, finds a
null MX which its considers bogus, and, instead of paying
attention to

	"If MX records are present, but none of them are usable,
	this situation MUST be reported as an error." 

which dates from RFC 2821 (at least) and, instead, goes looking
for an address RR.

Now, there is no question in either case that the client is
non-conforming.  However, for better or worse, there is a long
tradition of SMTP receivers trying to figure out what is going
on with non-conforming SMTP senders and trying to get messages
through if at all possible.  My understanding of Jeremy's
reading of the situation (with which, fwiw, I agree) says being
able to respond on port 25 and quickly reply with a "5yz" code
is better than the alternatives.  And I note, in that regard,
that I can find nothing in RFC 7505 that prohibits advertising
null MX but still responding to port 25.  Interestingly, even if
we imposed such a rule in 5321bis, the "operational
requirements" text of Section 7.8 would still allow a server to
have that port available.

     john

---

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2022 12:30:51 -0500

> Agreed, except that this actionability advice is such an important principle 
> that deserves being published in 5321bis.

5321 is already too long and says the bounce address is where you send 
failure reports.  Can you explain why this detail is so important that it 
needs to make 5321bis even longer?

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2022 12:48:15 -0500

>> to try the A for the domain.

When I was working on 7505 I looked to see what existing MTAs do with a 
null MX.  Most of them failed immediately with a message that the MX is 
invalid, some eventually timed out.  We didn't say so in 7505 but one of 
the nice things about it was that in practice it mostly worked already, 
give or take the error message. I never saw one try to fall back to the A 
record.

> there are few, if any, of those left.) ...

I've never found it useful to try and guess how people who haven't read 
the spec will misimplement it.  Keeping in mind that 7505 is basically a 
performance hack to make mail fail quickly rather than timing out, I would 
expect that ancient MTA to try for a week, then send the bounce message, 
which the recipient will not read because she retired a decade ago.  This 
does not seem like a situation worth optimizing.

>> Or never looking for an MX.

By that logic, every host with an MX and an A should put a stub server 
sending 556 responses on the A hosts because who knows, someone might 
ignore the MXes and it is urgent that their users get failure messages 
right away rather than later.  Aw, come on.

I have nothing against people running 556 stub servers if they want to but 
that has nothing to do with null MX.

R's,
John

PS:
> And I note, in that regard, that I can find nothing in RFC 7505 that 
> prohibits advertising null MX but still responding to port 25.

As I said, that is because "." is not a host name, is not a host, and has 
no ports.  It equally does not forbid the root from running a gopher 
server or speculate about what people might do on hosts unrelated to the 
null MX.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 7 Feb 2022 09:51:01 +0100

On Sun 06/Feb/2022 18:30:51 +0100 John Levine wrote:
>>> while forwarding, with the advice that the goal is to get the 
>>> bounces to someone or something that can act on them.
>>
> failure reports.  Can you explain why this detail is so important that 
> it needs to make 5321bis even longer?

Let me explain a bit better.  I didn't mean to make it longer.  I 
proposed to *replace* the treatment of a couple of fixed cases, 
aliases and mailing lists, which don't cover all possible situations, 
with some general principles which are to be expanded in the A/S.

For example, Section 3.4.2.1 says aliases should never change the 
bounce address while there are cases where it is better to change it. 
  One such case is treated in Section 3.4.1, but without mentioning 
what to do with the bounce address in case the final address shall not 
be disclosed.

For anther example, let's consider a role alias which expands 
[email-masked] to [email-masked], [email-masked] and 
[email-masked].  If I were a marketing manager at example.com, I'd 
want a message to be considered delivered if it arrives at one or more 
team members.  Hence a bounce should be generated only if all three 
mailboxes bounce, unless positive MDN are also going to be generated.

My proposal is that 5321bis just says that the bounce address should 
be adjusted according to the actionability principle and information 
leaking considerations, according to the semantics of the alias.  That 
way the text would still be longer than by striking the whole Section 
3.4.2 away, but somewhat shorter than -09.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Feb 2022 13:28:12 -0500

--On Sunday, February 6, 2022 12:48 -0500 John R Levine
<[email-masked]> wrote:

> When I was working on 7505 I looked to see what existing MTAs
> do with a null MX.  Most of them failed immediately with a
> message that the MX is invalid, some eventually timed out.  We
> didn't say so in 7505 but one of the nice things about it was
> that in practice it mostly worked already, give or take the
> error message. I never saw one try to fall back to the A
> record.
> 
>> (1) Client is not only pre-RFC 7505 but pre-RFC 974, e.g.,
>> some embedded thing that has not been updated to understand MX
> I've never found it useful to try and guess how people who
> haven't read the spec will misimplement it.  Keeping in mind
> that 7505 is basically a performance hack to make mail fail
> quickly rather than timing out, I would expect that ancient
> MTA to try for a week, then send the bounce message, which the
> recipient will not read because she retired a decade ago.
> This does not seem like a situation worth optimizing.
> 
> By that logic, every host with an MX and an A should put a
> stub server sending 556 responses on the A hosts because who
> knows, someone might ignore the MXes and it is urgent that
> their users get failure messages right away rather than later.
> Aw, come on.
> 
> I have nothing against people running 556 stub servers if they
> want to but that has nothing to do with null MX.
> 
> R's,
> John
> 
> PS:
>> And I note, in that regard, that I can find nothing in RFC
>> 7505 that  prohibits advertising null MX but still responding
>> to port 25.
> 
> As I said, that is because "." is not a host name, is not a
> host, and has no ports.  It equally does not forbid the root
> from running a gopher server or speculate about what people
> might do on hosts unrelated to the null MX.

Sure, but I obviously was not clear about the case I had in
mind.  Clearly, a client would have to demonstrate a rather
extreme and creative level of stupidity to try to look up "."
and then open a connection to whatever host they think that
means.  Two things are more plausible: (i) the client gets the
MX record back after looking up the domain in the address, sees
"." in the data, doesn't understand the convention, and discards
the record.  At that point, it has run out of MX records and
5321 clearly says that it should stop and return a fatal reply
message.  That fact that most clients -- whether aware of 7505
or not -- are going to follow that "if there are one or more MXs
and all of them ore exhausted or eliminated, fail" rule is, I
assume, why you see the behavior you describe above.   A server
implementer who did not want the retry behavior you describe and
therefore wants to run a 556 stub server should not be
prohibited from doing that.  On the other hand, we don't need to
go out of our way to encourage that either.

So, let me back up a bit.  I think there are three questions
here.  One is why 5321bis says what it says (independent of
trying to guess at motivations or types of wrong behavior).  To
a considerable extent, I (and perhaps Jeremy) was responding to
that one but, for reasons you (indirectly) give, it isn't really
important.  The second is whether what it says is sufficiently
wrong that we need to change it by rewriting, adding, or
removing text and, if so, how.  And the third is what, if
anything can and should be clarified without changing the
substance of what is said.

And, fwiw, the cases I actually think are significant involves
an SMTP server that accepts mail for several domains but, of
course, does not act as an open relay or otherwise accept mail
for other domains, even domains within the same administrative
group, e.g., ones that might be supported by the same servers
for web or other purposes but not for email.  It cannot produce
a 556 reply at connection-opening because it doesn't yet know
what domains will appear in addresses in RCTP commands.  Now, it
would be entirely reasonable for whomever configures the DNS for
the relevant domain to put in a null MX record, but as several
of us have pointed out from time to time, DNS zone
administration and mail server administration and operations are
often separate people and even in separate groups, and assuming
good coordination may be unrealistic.  So here we have a server
that has a perfectly good reason to have something that responds
on the SMTP port even though it might reasonably want to reply
556 to a RCPT command (rather than a code about the specific
mailbox)** if it will not accept _any_ mail for that domain).
And getting into that situation does not require any client
misbehavior, only a bit of DNS mis-configuration, whether latter
is failure to include a null MX RR, an MX that points to the
server, or omitting any MX records and letting the client to the
address records intended for another purpose.

best,
   john

** I just noticed that 556 is not included in the list of
response codes for RCPT in Section 4.3.2.   Given the logic
above, should it be added or should we just rely on "usual
possible replies" in the first paragraph of that second as not
prohibiting and move on.  And, especially if it is added, should
the discussion of 556 in the second paragraph of Section 4.2.4.2
be modified to include that case?

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2022 18:00:06 -0500

It appears that John C Klensin  <[email-masked]> said:
>removing text and, if so, how.

I took another look and the sentence that bothers me is this one:

   ...  If, despite publishing
   the DNS entry, the server domain chooses to respond on the SMTP port,
   it SHOULD respond with the 556 code as well.  The details of the Null
   MX convention were first defined in RFC 7505 [46]; see that document
   for additional discussion of the rationale for that convention.

"The server domain" is confusing. I'd be OK with "hosts that are not
mail servers but are identified by A or AAAA records for the domain."

>group, ...

But this is the usual case. If I send mail to someone at hotmail.com,
the MX is hotmail-com.olc.protection.outlook.com and that server does
not accept mail for that domain (I checked.) I don't see any reason
why you would want to have different responses for "I don't accept
mail for that domain" and "I don't accept mail for that domain and I
don't think anyone else does either." It's just one more thing to get
wrong.

It doesn't tell the other party anything useful other than I suppose,
a hint that her mail system is broken. But of course the mail system
sending that code might be broken instead.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Feb 2022 21:11:15 -0500

--On Monday, February 7, 2022 18:00 -0500 John Levine
<[email-masked]> wrote:

>> trying to guess at motivations or types of wrong behavior).
>> To a considerable extent, I (and perhaps Jeremy) was
>> responding to that one but, for reasons you (indirectly)
>> give, it isn't really important.  The second is whether what
>> it says is sufficiently wrong that we need to change it by
>> rewriting, adding, or removing text and, if so, how.
> 
>    the DNS entry, the server domain chooses to respond on the
> SMTP port,    it SHOULD respond with the 556 code as well.
> The details of the Null    MX convention were first defined in
> RFC 7505 [46]; see that document    for additional discussion
> of the rationale for that convention.
> 
> "The server domain" is confusing.

In retrospect, agreed.

> I'd be OK with "hosts that
> are not mail servers but are identified by A or AAAA records
> for the domain."

I think that might be even more confusing for the case in which
the host is a mail server for some domain(s), just not that one
(including, I think, your example below).  How would you feel
about:

	"hosts that are not mail servers for a particular domain
	but are identified by A or AAAA records for that domain."

?

> But this is the usual case. If I send mail to someone at
> hotmail.com, the MX is hotmail-com.olc.protection.outlook.com
> and that server does not accept mail for that domain (I
> checked.)

For which domain?  Certainly it accepts mail for hotmail.com or
nothing would work.  Assume you tried to send mail to
[email-masked].  Nothing we have said implies that it is
obligated to accept mail addressed to
[email-masked] and would expect a
556 response it if got a RCPT command for that address.  So,
assuming that mailboxes exist for [email-masked] and
[email-masked] (see below) but not for [email-masked], I'd
expect (noting that the text with the reply is explanatory, not
necessarily what I'd expect from a server):

	RCPT TO:<[email-masked]>   250 OK
	RCPT TO:<[email-masked]>   550 No such mailbox
	RCPT TO:<[email-masked]>
	       556 No mail service for
	          hotmail-com.olc.protection.outlook.com
	RCPT TO:<[email-masked]>
	       556 No mail service for
	            hotmail-com.olc.protection.outlook.com
	RCPT TO:<[email-masked]>   250 OK
  	RCPT TO:<[email-masked]>
	       556 No mail service for
	            live-com.olc.protection.outlook.com

Noting, fwiw, that the MX for live.com points to
live-com.olc.protection.outlook.com. and that
  live-com.olc.protection.outlook.com. IN A 104.47.14.33
and
  hotmail-com.olc.protection.outlook.com. IN A 104.47.74.33
i.e., as far as TCP is concerned, hotmail.com and live.com are
supported by the same host.

Are we agreed so far?  

Do I think it makes a huge difference whether
  RCPT TO:<[email-masked]>
gets a 556 or 550 code (after all, if there is no service for
that domain, there is no mailbox either)?  Nope, but the former
seems more orderly.

I also note that there is no null MX record for
hotmail-com.olc.protection.outlook.com.  That is ok, AFAICT,
but, in its absence, the client has no way to know that, if it
sends a RCPT command containing that domain, it won't work
without trying it and (presumably) getting a 550 or 556 reply.

> I don't see any reason why you would want to have
> different responses for "I don't accept mail for that domain"
> and "I don't accept mail for that domain and I don't think
> anyone else does either." It's just one more thing to get
> wrong.

Agreed.  I hope I didn't say anything that confuses you about
that.  Do the above examples help?  Do we need to turn that into
a table in 5321bis with the Microsoft domains appropriately
disguised (I hope not, but, if it is the only way to make this
clear, maybe we should consider it.

> It doesn't tell the other party anything useful other than I
> suppose, a hint that her mail system is broken. But of course
> the mail system sending that code might be broken instead.

Right.  And that is also the reason I'm not sure whether the
difference between getting a 550 or 556 code back if a RCPT
command contains hotmail-com.olc.protection.outlook.com is
really important.   But that questions may take us several steps
back to the "only the first digit counts" discussion.  And the
556 _might_ allow the client or the user's MUA to give the user
slightly more clues about what is going on... unless we decide
that such a user is sufficiently confused that leading them
around in circles would be desirable.

best,
   john

---

From: "John R Levine" <[email-masked]>
Date: 7 Feb 2022 21:49:58 -0500

> 	but are identified by A or AAAA records for that domain."

That's just baffling.  The domain has an MX and and A that points to a 
mail server that only handles other domains?  I'm guessing that the idea 
is that there's a null MX for www.foo.com, and it happens that www.foo.com 
is the same host as mail.foo.com which handles mail for foo.com but not 
www.foo.com.

While that surely happens and has been happening for 40 years, in practice 
either the mail server rejects mail to www.foo.com with a 550, or it's 
misconfigured and accepts it anyway.  (See, for example, the To: address 
on this message.)

> that domain, there is no mailbox either)?  Nope, but the former

But it's not what anyone does now.  It's all 550.  More often than not the 
MTA has no idea what its name is or anything else other than the list of 
domains that it is configured to handle.

> that.  Do the above examples help?

No, they seem to say the opposite, trying to guess why the sender wants 
you to accept mail that you don't accept.

Regards,