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

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.

pgpJDxFygoWCQ.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp