Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

Keith Moore writes:

> On 10/4/20 7:09 PM, Sam Varshavchik wrote:
>
> > Life's not fair.
> >
> > Whether it's fair, or not, if someone wishes to evaluate an individual IP  
> > address based on its "neighborhood", a.k.a., the hosting provider, it is  
> > their prerogative to do so. Their mail server, their rules.
> As long as they're only handling their own mail, I'd agree.
It's unclear to me how they could end up handling something that's not their  
own mail. Doing so would, at least, involve hijacking DNS records to repoint  
someone else's mail to their own mail server. But that would fall waaaaaay  
out of scope, here.
> > Or, if someone decides to willingly outsource their evaluation to a third  
> > party provider, it is their prerogative to do so as well.
> Sure, though one hopes that the third party operates by published criteria  
> that helps the client evaluate that provider's effectiveness and sanity.
That's neither here, nor there. One can publish anything. Whether they abide  
by what they publish, in practice, it's a different story. But everyone  
should make their own decisions, for themselves.
To my knowledge, none of the widestly used, and most popular third party E- 
mail reputation services have any kind of authoritative, published manifesto  
about how they go about doing what they do. Anything beyond very, very  
general and non-specific description of what they're all about, and what  
their lofty goals are. Some are more specific than others, but nobody will  
actually state, for the record, exactly how they get from point A to point B.
And that has always been the way as far as I can remember.

And they are still used.

And this has been a frequent criticism from their detractors, and I suspect  
that you're using this rigorous standard as an indirect way of attempting to  
discredit all third party E-mail reputation services. Well, be it as it may.  
But this does not discredit them in my eyes. But that's only because I think  
most of them are already discredited, for other unrelated reasons. I stopped  
using all of them, some time ago, after I concluded that things have changed  
sufficiently, over the years, for them to be worth anything, any more.
But I certainly have no objection to anyone else still using them. It's a  
free world. Who am I to tell someone who they should or should not accept  
mail from, and why?
> > > what point does this depart from common sense and into the realm of pure  
> > > prejudice?  ("That IP address is from across the tracks, which is a bad part  
> > > of the net.")
> > Yes, it is prejudice. So?
> At least you're willing to admit it.
>
> See, I'm fine with penalizing operators that have clearly established bad  
> reputations through bad behavior.   I'm not so fine with penalizing  
> operators that merely have the misfortune to have "bad IP addresses", or  
> send traffic from "bad neighborhoods".
You are entitled to your opinion. But you need to understand that, insofar  
as the operators of those mail servers go, they don't really value your  
opinion that much. Most of them don't even know who you are. Or who I am.  
They only see what's incoming on their port 25, and they will make their  
decision accordingly, and they won't really care whether someone else across  
the world thinks of it.
> > There happens to be some entities who do not like the side of railroad  
> > tracks that I live in, by the way. Or, they outsource their mail filtering  
> > to third parties that carry that opinion. I never whined about how unfair it  
> > is. And it never entered my mind to complain to them as well. I recognized  
> > that it's their mail server, their rules. They are free to take care of  
> > their business, and I'm free to take care of mine, in whichever way I see  
> > fit.
> The purpose of IETF (and therefore this list) is to promote  
> interoperability, not to degrade it or shield those who do so.
And specifying how EHLO/HELO, MAIL FROM, RCPT TO, and DATA works, on a  
purely technical level – this can't be any more interoperable than it  
already is.
Whether or not someone accepts mail from someone else is a matter of policy,  
not interoperability.
Interoperability is promoted by having a rigid, unambiguous, technical  
specification for something. That spells everything out in detail. SMTP is  
much more interoperable than other mail protocols that better be left  
unsaid, which had poor specs from the beginning that created many  
interoperability headaches, for decades. As far as that goes, I think that  
SMTP is remarkably interoperable.
But I don't think there's anything technical in requiring any particular  
validation or non-validation criteria, or a policy, for the sender's IP  
address, or a domain, that falls outside of SMTP's strict boundaries. That's  
a matter of policy, and not a technical specification, and bears no  
relevance on interoperability.
> > Yes, they may seem to be arbitrary to an outside observer. But, they must  
> > have merit to whoever is using that spam filter. If it didn't have any  
> > merit, then they would not be put into place, by definition.
> I disagree.  I've seen lots of spam filtered for meritless reasons, I've
You concluded that it was meritless to yourself. You did not make that  
conclusion for anyone else.
> seen lots of examples of operators engaging in completely arbitrary behavior.
Arbitrary in your eyes. In their eyes, it's unclear how arbitrary or not  
arbitrary it was. You cannot know that without asking them and getting their  
answer. They may have perfectly legitimate reason for engaging in the  
behavior you deemed to be arbitrary. You don't know that.
> > And the only ones whose opinion counts, with respect to their mail server,  
> > is them.
> Emphatically disagree.
This has been alluded to before, briefly. Back in the 1990s, there was a  
rather …vocal group who proferred the notion that mail server administrators  
have no standing to control E-mail sent or received by their users. That  
their users had some kind of a right to receive all E-mail unfettered and  
that mail administrators have no right, of some sorts, to block it for any  
reason.
Let's just say that the group of individuals I'm referring to – and some on  
this list know exactly who they are – were not saying much different from  
what you are saying here. … and at about this point I started describing how  
well their ideas were received, what everyone thought of them and how  
everyone else assessed their … faculties, but when I reread it I realized  
that this came off too negative, so I decided to delete all of that, and  
just get to the bottom line:
No matter how much someone asserts to the contrary, the administrators of  
mail servers will always have complete, and have the only say, as to their  
mail servers' administrative policies. And there's nothing that anyone will  
be able to do about it. No matter how much anyone else, you or anyone else,  
thinks of the merits of their work. Sorry. Write any requirement into the  
next SMTP specification, that attempts to dictate policy. It won't work.
> And that path leads to a thoroughly dysfunctional  
> mail system, in which senders cannot assure the reliable delivery of mail
This has never been the case, sorry.

E-mail, as it stands, has never been a reliable, guaranteed message delivery  
medium. At most, E-mail has always been on a best-effort basis.
> > If it makes sense, to them, to enable EHLO domain verification (dragging  
> > this subject matter back into the thread kicking and screaming), then  
> > they're going to do that no matter what verbiage remains in the successor to  
> > RFC 5321. You can take that to the bank.
>
> Yes, people will defend their own stupidity and irresponsibility until their  
> deathbeds.     That doesn't mean that IETF should support it.
Well, I'm somewhat skeptical that they're looking for IETF's support on  
anything. And I don't really know what "IETF should support it" means in  
this context. Is IETF about setting everyone's mail acceptance mail  
policies, by decree?

pgpEassTfsZiz.pgp
Description: PGP signature

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