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

On 10/4/20 8:34 PM, Sam Varshavchik wrote:

> > > 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.
That's what MSPs do - they handle mail on others' behalf.

Let me use an analogy.  If I buy Internet service from some ISP, I 
expect them to deliver the IP packets that I originate to their 
destinations, and I expect them to deliver IP packets from other sources 
to my network.   What I don't expect is that the ISP will randomly drop 
or mangle IP packets based on arbitrary criteria. The IP stack 
(including everything above IP) expects that networks will make a best 
effort to deliver packets and largely depends on that behavior.
> > > 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.
That's not a way to get reliability or interoperability.

> 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 is precisely why email is now unreliable.

It used to be that IETF was about people trying to make the network and 
networked applications work well for everyone.   But somehow this list 
is now populated by at least a few people who are loudly defending their 
"right" to screw it up by whatever means they choose, for whatever 
reasons they choose, without having to answer to anyone for doing so.    
Assuming you have some good intention behind your arguments (and I, 
perhaps naively, expect that you really do), it's hard to see what it is.
> 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. 
Well, I happen to think that email, as an interpersonal messaging 
service, is worth preserving.   Maybe they don't.
> > 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.
Email isn't just a protocol, it is a service.   You can conform to the 
SMTP specification to the letter and the email service still be unreliable.
> Whether or not someone accepts mail from someone else is a matter of 
> policy, not interoperability.
You're not even arguing for policy.   You're arguing for completely 
arbitrary behavior.
> 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.
Emphatically disagree.   If users can't trust that reasonable mail that 
they send to correct addresses of willing recipients will be delivered, 
email doesn't interoperate by any reasonable definition.
> > > 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.
Well, you're so busy trying to define "merit"  in a circular and 
meaningless fashion, that I don't think I could ever convince you anyway.
> > seen lots of examples of operators engaging in completely arbitrary 
> > behavior.
> Arbitrary in your eyes.
Arbitrary in users' eyes, and users are generally powerless to do 
anything about it other than maintain multiple email accounts and try 
them randomly until something works or they give up.

> 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.
Some of those people were *right*, even if they didn't make their 
arguments with perfect precision.     They were arguing for a *reliable 
email network* as viewed by users.
What if telephone calls were arbitrarily blocked by the telephone 
network for no apparent reason, maybe because the caller was from a "bad 
neighborhood"?   Would people keep relying on the telephone network, or 
would they just give up?   (Sure, recipients often ignore calls for 
which the calling number isn't known to them, but that's not the network 
blocking the calls)
I do remember some of the anti-spam discussions in the 1990s and how 
chaotic and hopeless they were.   There was a tremendous amount of 
naivete among most of the participants, and a lot of belligerence among 
some, especially those trying to make a "land grab" for part of the 
space whether by patent filings or other means.    I basically bailed, 
not having the time to keep up with them, hoping that the discussions 
would get saner later.
But today is not the 1990s, and conditions are somewhat different now 
than they were then, in ways that might be useful if people actually 
want to create a reliable email service.    Of course, maybe some people 
today still stand to benefit from perpetuating the chaos that currently 
exists.
> 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.
Well maybe there are some subset of MSPs that actually want to 
contribute to making email more reliable, and maybe those MSPs are 
willing to try to build consensus around policies to that end. As for 
the ones trying to sabotage mail for whatever reasons, I don't think 
IETF can do anything about them, but we can always hope that the ones 
that care about reliable service replace them.
So maybe there should be an RFC "How To Make Your Email Work Reliably If 
That's Actually What You Want To Do".   Because I think Internet email, 
at least post-821/822, is still far better at its core than every other 
messaging system out there.   Better metadata, better searching, better 
archiving, more flexibility. What has happened to Internet email is 
nothing short of tragic, and I would like to see it fixed rather than 
left to rot.
> > 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.
Best-effort worked fairly well back when the biggest reasons for failure 
were bad MTA configuration (sendmail.cf files were especially 
notorious), bad DNS configuration, and persistent failure of the IP network.
Today's email is nowhere nearly a best-effort service.

> > > 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?

No, IETF is about trying to make recommendations that will facilitate 
and improve service for users.   Which seems like the opposite of what 
you're arguing for.
Keith



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