On 12/24/19 6:30 AM, Alessandro Vesely wrote:
There seems to be a common path, shared among SPF, ADSP, and DMARC. At some
times, it was common belief that universal adoption of the token protocol would
stop spam.[*] The protocol provides for soft or hard settings, so spam
fighters push for hard settings, while experts warn that the intended use of
the protocol differs. Eventually, MTAs settle for soft settings. Next.
Well, maybe it's time to raise the bar a bit, and maybe IETF can help.
It might also help if people can be held accountable for the mail that
they send. If the authentication works well enough, it basically
forces spam and malware to go anonymous, to keep the senders from being
held legally accountable. Of course, advertisers will continue to
believe that what they are doing is legitimate, but if they're forced to
authenticate themselves using real names, it will be easier to
distinguish their mail from that of reasonable people.
The latter stage hasn't yet come for DMARC. For example, SM found an a web
tool which diagnoses the IETF "Not [having] all authenticity marks against
email phishing (DMARC, DKIM and SPF)".[†] That's not the only web tool doing
Spam comes in different shades. The best we can hope for email authentication
is to eliminate just the anonymous spam, that which provides false identities.
With a little additional effort, trash-domain authentications can be
recognized as well. However, hard settings for everybody entails some change
in SMTP semantics, for SPF it was forwarding, for ADSP and DMARC mailing lists.
I don't think rfc5321bis should address email authentication directly, but
reshaping Section 3.9 might help.
I agree that 5321bis is not the place to address most of these things,
though there might be slight changes to the language. But I've been
assuming throughout this discussion that efforts to improve spam
filtering would be separate from the revision of 5321. Sorry if I
haven't made that clear.
ietf-smtp mailing list