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

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.

pgpLHS8ekoCjX.pgp
Description: PGP signature

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