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

Keith Moore writes:

> « HTML content follows »
> 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.
Then, it's their mail that they're handling, not someone else's.

> 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.
If you set up a server on port 25, in order to receive mail, and your ISP is  
blocking your port 25, then you would certainly have an issue to raise with  
them.
> > 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.
Then don't use them, yourself.

But if others choose to use them, you are in no position to judge whether  
their email is reliable or interoperable. On they can make that decision for  
themselves.
> 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,
I will certainly insist that I have full and complete right to "screw" up my  
own email in whichever way I wish.
> > 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.
Email has always been like that. It is no worse off now than it always was.

> > 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.
Yes, and it will always be the case, with email in its current form.

> > 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.
I am arguing that individual mail server operators are free to set whatever  
policies they wish, for their mail servers. It is their arbitrary right to  
do so and nobody has any standing to make them do otherwise.
> > 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.
And if the same users want a pony, they won't get that either, I'm afraid.

How is that's interoperable? "Interoperable" means that the sender and the  
recipient can communicate. In this case, they communicated perfectly, and  
the recipient simply rejected the sender's E-mail.
Interoperable would mean that the recipient intended to receive E-mail, but  
due to an error in interoperability the message failed to get delivered.  
Interoperable does not mean guaranteed E-mail delivery. Sorry, it does not.
The notion that, as a mail sender, one is entitled to have their mail  
received by their intended recipient, and a failure to do so means that E- 
mail is not interoperable, is quite flawed. One has never had that guarantee  
in the first place, and never will. Not under the current, /interoperable/ E- 
mail protocol. It's simply not designed for that, and never will.
> > > > 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.
No, you defined "meritless" as a conclusion that you reached. I pointed it  
out. And I precisely staked my position that neither myself, nor you, nor  
anyone else, can judge the merits of someone's decision for their incoming  
mail.
> > > seen lots of examples of operators engaging in completely arbitrary  
> > > behavior.
> > Arbitrary in your eyes.
> Arbitrary in users' eyes,
and in anyone other than the operators', and it's only their opinion that  
matters, sorry.

> > 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.
Yeah, some people just want a pony. They're not getting one.

> What if telephone calls were arbitrarily blocked by the telephone network for  
> no apparent reason, maybe because the caller was from a "bad neighborhood"?  
Telephone is not E-mail.

> 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.
SMTP is still the same today as it was back then, and it works the same way.

> > 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.
That's neither here, nor there. As I said, any policy diktats will fail.

> > 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.
Really? That's news to me. Who exactly is foolish enough to guarantee mail  
delivery, pray tell me?
> > > 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.
I'm not arguing anything. I'm simply pointing out that attempting to dictate  
policy decisions in technical specifications is a fools' errand. That's the  
capsule summary of my initial message that started this thread. And I'm also  
disputing any notion that E-mail has been, at any time, or will ever be, a  
guaranteed communication medium. Your users can demand their E-mail to be  
delivered as much as they want, but it's not going to be up to them, and it  
is not going to be up to you. If someone doesn't want to receive mail from  
you, there's nothing you can do about it. Call it lack of interoperability,  
call it anything you want, but you're not going to mandate anyone to receive  
email from anyone else. This is simply not going to happen. You can either  
continue to make demands, that will be fruitless, or work with making  
everyone /aware/ that E-mail is what it is, so it is not a surprise to  
anyone.

pgp5R3tjjPsg7.pgp
Description: PGP signature

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