[Top] [All Lists]

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

2019-12-25 19:58:57
John C Klensin writes:

clearly enough.  While I would (and did) argue for a change in
direction and/or strategy rather than simply continuing with the
anti-spam arms race, I think any proposal for such a change and
direction or strategy must be rooted in a deep understanding of
what the environment is like, what has been done, and what the
strengths and weaknesses of those approaches have been.

I don't think there's anything here that requires deep understanding. The facts are pretty basic, and fundamental. The "P" in "SMTP" is as "S" as they come. It does its job with a minimum of fuss. Its job, of serving as means of delivering mail, gets done in the most straightforward manner imaginable.

I don't think any changes here are in the cards. I doubt that any change to SMTP will accomplish anything. And I already mentioned that I do not believe that any societal or legal changes will accomplish anything more than the CAN SPAM act of 2003 has actually accomplished. What difference has it made? What tangible result can anyone point out, that it accomplished towards the goal of controlling spam? I wasn't the only one who laughably predicted its utter uselessness in that regard, when it went up the flagpole. I don't see any non-technical measure being able to produce any better results than the CAN SPAM act.

I think that any solution to spam can only be a technical solution. But I do not think it involves SMTP per se, but be something at the same level of the protocol stack as DMARC is. DMARC itself proves that the mail originated from its purported sender. I recall that the original advocacy for DMARC included some claims of its purported anti-spam benefits. I never saw how proving that mail really came from a domain proved whether it's spam or not. A healthy portion of my spam folder is DMARC-signed, so that does a lot of good, in that regard… But once something along the same lines defines whether the mail was solicited by its recipient, only at that point you can have SMTP enter the picture and have SMTP servers check it and have an option of rejecting unsolicited email.

But for defining the anti-spam technical solution itself, that SMTP really doesn't need to be involved in this particular discussion. SMTP does the job it's assigned to do. And, that's it, nothing else needs to be said. First, it's necessary to have a technical approach to defining whether mail was solicited by its recipient. Implement this first, with SMTP out of the picture. Now, once you have done, an SMTP server can stick its nose, take a sniff, and accept or reject mail on that basis, if such option is available.

Attachment: pgpLHS8ekoCjX.pgp
Description: PGP signature

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