null mx vs server domain in 4.2.4.2

[jrlevine]

It says

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.

Domains don't have ports. I think the intention here is that if a domain publishes both a null MX and an A/AAAA record, and a host at the A/AAAA address has an SMTP server, it should respond 556.

Except that is wrong, e.g.:

mail.foo.wtf. MX 0 . mail.foo.wtf. A 10.11.12.13 foo.wtf. MX 10 mail.foo.wtf.

Obviously it does not respond with 556, since it's a real server. If a client does RCPT TO:<abc@mail.foo.wtf> I think 554 is appropriate, although 550 is more common.

I guess 556 is still useful when a submission server gets a message for a null mx domain.

[aamelnikov]

Consensus from the IETF 113 discussion is no change to document (5321bis), meaning 550 should be the response.

[aamelnikov]

If no further discussions/clarifications till May 19th, this ticket will be closed with "no change".

[klensin]

Just to make the record clear, the paragraph this is discussing does not appear in RFC5321. The sentence John (Levine) quotes above (from 5321bis-09, still in 5321bis-10) specifies use of 556. That was, as John effectively pointed out, clearly an error. The text in 4.2.4.2 and the reply code descriptions (at least as of 5321bis-10 although that creates another issue, see below), clearly (I think) point to using 554 for this case. Since 550 has never been used in this context, I'm not sure what "no change... meaning 550..." means.

"556" in that sentence has been tentatively changed to "554" in the working version of rfc5321bis-11.

Now, that raises two other questions:

(1) 554 is not on the list of reply codes that can be returned for RCPT in Section 4.3.2. CREF note added there in 54321bis-11.

(2) Part of what has been causing the confusion about the use of 556 is something that is, at least, IMO, more clear in RFC 7504 than it may be in the current 4.2.4.2. In retrospect, there probably should have been a bit more discussion and maybe an example in 7504 but too late now -- the question now is how much more, if anything should be added to 4.2.4.2. If both John Levine and I have been confused, maybe the answer is "at least something". The important case is, granted, fairly obscure, but it can still be important in specialized networks and those with unusual connectivity issues. That case goes back to RFC 974 and the (inevitably vague) notion of a "delivery server". Let's assume, to take what I hope is the simplest possible case, that we have

B!.EXAMPLE. MX 0 B1X.EXAMPLE B1.EXAMPLE MX 1 B2X.EXAMPLE B1X.EXAMPLE. A 1.2.3.4 B2X.EXAMPLE. A 1.2.3.5 B3X.EXAMPLE. A 1.2.3.6 B4X.EXAMPLE. MX 0

now, Submission Server A, with a message for exampleUser@B1.example and from otherUser@X.example does a DNS lookup, as required, and gets back the records shown in the first two lines. It dutifully tries B1X.EXAMPLE, times out, and tries B2X.EXAMPLE. which responds to connection-opening. Assuming B2X thinks it is a plain, ordinary, relay, it then does the DNS lookup again, gets the same records, tries to open a connection to B1X, times out just the way the submission server did, and queues the message in the hope that the timeout goes away. So far, completely normal and no NULL MX processing involved. However, B2X is actually not required to do that. If it decides it is part of the delivery system, it can get the message to whatever it thinks is the final destination in whatever way it is configured to think appropriate including no only by non-SMTP mechanisms but by using SMTP to forward, based on either the forward-pointing or reverse-pointing addresses (or their domain components) to hosts of its choice. In particular it might look at the forward-pointing address and decide the right way to deal with the message for exampleUser@B1.example and open an SMTP connection to B3X at 1.2.3.6, to 1.2.3.7 (which doesn't even have a DNS entry), or by doing a DNS lookup on B4X (although that would probably imply a configuration error). Actually trying to open the latter connection would be an error and that is where John and I have been focusing. However, the system a B2X might reasonably, and before trying to resolve and open any of those connections, look at the backward-pointed address, say "I know perfectly well that the delivery system for B1.example is not accepting mail with a backward-pointing address of otherUser@X.example (or even containing X.example as the domain), it can (and should) return 556 for any of those cases. Doing so is completely consistent with the text in Section 4 of RFC 7504 ("normally attempt to open a mail connection ... can determine that the host does not accept mail connection...") and it is not the host at B4X.EXAMPLE that is generating that reply code.

I really hope we don't need to go into that much detail, or anything close, in 5321bis, but that is clearly up to the WG. And, if the conclusion is that we should say something more than 4.2.4.2 says (as of 5321bis-10 or, when you see it, 5321bis-11) without going that far, text suggestions would be welcome.

[jrlevine]

554 and 556 are intended for submission servers. I don't know of any MTAs that would know when to issue 554 or 556, so I would delete everything in 4.2.4.2 after "no mail exchanger for that domain" and remove the mentions of 554 and 556 at the beginning. The discussion of 521 is fine.

[klensin]

--On Wednesday, May 18, 2022 11:57 -0700 John L @.***> wrote:

554 and 556 are intended for submission servers.

I don't know where that assertion comes from, at least unless you are making a much narrower scope for "intended" than I'm reading into your note

554 appears in RFC 821 although without much description. However, its use at initial connection opening to the server is described in RFC 2821, Section 3.1 (April 2001), a description that was carried forward into RFC 5321. The 2821 text postdated the original (RFC 2476) version of Message Submission. RFC 6409 (the current Message Submission spec) mentions 554 in Section 4.1 as a code to be used on its server side for communication with the user/MUA acting as its client, but it does nothing to restrict the use of the code, either to the that submission-related purpose or for SMTP uses more generally. RFC 5321 (and 2821) also explicitly allow 554 in response to DATA if there were no valid RCPT (or MAIL) commands. FWIW, the only systems that can determine that a RCPT command is invalid because of the address (not just the domain name) given is the final delivery server or something that has access to its list of valid mailboxes: rarely, if ever, a submission system. Even if you had mentioned it in RFC 7505 (AFAICT, you didn't), it would still remain valid for receiver-SMTP systems that did not accept mail and did not advertise NULL MX. And all RFC 7504 has to say about the 554 code is (in Section 1) that 521 is preferred to it for a "system that does not receive mail or otherwise handle SMTP mail or inquiry transactions" [1].

556 is defined for the first time in Section 4 of RFC 7504. The document does not mention submission. That section talks explicitly about "an intermediate SMTP system (typically a relay)..." which would normally describe anything but a submission server or a final delivery one. That code is also mentioned in the introduction in the context of NULL MX, but explicitly using it only as an example. If a submission system, acting as a sender-SMTP, looks up the domain name part of a destination address, and discovers an NULL MX record, it should certainly return the 556 code (or an equivalent indication) to the user/MUA. But, as explained in the Github ticket comment [2], that says absolutely nothing about receiver-SMTPs that do not accept mail and that are encountered after submission (whether they advertise NULL MX or not) nor about sender-SMTPs that determine that they cannot find a host that accepts mail but might otherwise be expected to do so.

So, if there is a limitation to submission, I can't find it.

I don't know of any MTAs that would know when to issue 554 or 556, so I would delete everything in 4.2.4.2 after "no mail exchanger for that domain" and remove the mentions of 554 and 556 at the beginning. The discussion of 521 is fine.

If there were research and documentation good enough to demonstrate that those codes were not in use, anywhere, including in enterprise networks, that would be grounds for deprecating them now. However, given the number of years they have been specified for use by standards-track protocols, I think the most we could do would be to say that their use was discouraged and something else should be used instead. And, even for that case, the potential for confusion among those codes --the issue that motivated 4.2.4.2-- would remain. Eliminating the discussion would not eliminate the potential for confusion.

I trust it is clear that "I don't know of any" or even, if we could get there, "no one participating in the WG remembers seeing" does not constitute that level of documentation.

In any event, at this point 4.2.4.2 is relatively old text, appearing initially in rfc5321bis-02 or earlier, in response to Ticket #6, which was apparently closed long enough ago to have not made it into the Github-based system. My notes seem to indicate that some of the text you are now proposing to remove went in after discussions with you.

So let's see what the rest of the WG thinks.

john

[1] Note that this implies that I should have written "521" in 4.2.4.2 and not either "556" or "550".

[2] https://github.com/ietf-wg-emailcore/emailcore/issues/62#issuecomment-1130263353

[aamelnikov]

John K. is to post -11 that might clarify this. If John L. is still not satisfied with it, John L. will be asked to produce alternative text that we can compare with -11 and pick one.

[jrlevine]

John L thinks that since no MTA will ever issue a 556, we have already spent far too much time on this nit.