[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-23 17:24:41
Peter J. Holzer writes:

The discussion did however strengthen my belief that the paragraph from
section 4.1.4:

|   An SMTP server MAY verify that the domain name argument in the EHLO
|   command actually corresponds to the IP address of the client.
|   However, if the verification fails, the server MUST NOT refuse to
|   accept a message on that basis.  Information captured in the
|   verification attempt is for logging and tracing purposes.  Note that
|   this prohibition applies to the matching of the parameter to its IP
|   address only; see Section 7.9 for a more extensive discussion of
|   rejecting incoming connections or mail messages.

ought to be deleted. Not to legalize what the IETF admin did - that's
already fine - but what you did.

No, it should be deleted because it will be ignored, in practice. It is very easy to understand why.

The reason you see various places doing this is because it works for them. As simple that. They've reached the conclusion that this check blocks a bunch of crap with negligible, if any at all, impact on their non-spam mail traffic.

However, no SMTP server I'm aware of does this by default, in its stock configuration.

If you see someone rejecting a HELO/EHLO with a non-matching IP address literal (or even any IP address literal), it's because two things must've happened earlier:

1) Their mail server turned out to be capable of doing this.

2) The organization that runs this mail server affirmatively decided to make their mail server do that.

So, in light of that, let's consider this statement:

|   However, if the verification fails, the server MUST NOT refuse to
|   accept a message on that basis.

There are only two audiences for this statement:

1) Someone who uses an SMTP server.

2) Someone who implements an SMTP server.

Those are the only two possibibilities. I can't think of anyone else who will hear this, in their daily life.

So, we can now ask a few more questions. We already know that this already happens in ractice. How common it is, I don't know, but it is already in noticeable use. Therefore, we can break down the first kind of the audience for this RFC as follows:

3) What are the chances that someone who simply uses an SMTP server will read this particular RFC, and even if they do:

4) How likely are they to comply, and turn off this configuration setting, which they believe to be useful for them, based on what they just read.

I think that the answers to 3 and 4 are pretty easy. This is very unlikely to happen. So, what's left are SMTP server implementations, the second half of the potential audience for this RFC. Ok, so let's consider the impact on SMTP server implementation.

Now, keep in mind that this is going to be just an optional feature which is very unlikely to be enabled by default. So, how likely is that an SMTP server implementation will either:

5) Remove the feature which, apparently, is popular with those who use this SMTP SMTP implementation, or at least some non-trivial portion of the users, or:

6) A new SMTP server implementation will decline to implement such a (semi)- popular feature in the first place.

I don't think that this is very likely to happen. Therefore, I expect that "MUST NOT" provision, if it exists already or will exist, to be mostly ignored.

Attachment: pgpJDxFygoWCQ.pgp
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>