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

On Thu 26/Dec/2019 02:58:46 +0100 Sam Varshavchik wrote:
> John C Klensin writes:
>
> > 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 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.

The strategy of email authentication —referenced at least since 2004[*] (15yrs 
ago)— is to do coarse-grain domain-based identification.  Of course, 
authentication has to be complemented by authorization and reputation.  
Authentication hit the mark.  IME, the vast majority of messages have at least 
one "=pass" (which in my case is any of spf, dkim, dmarc, or dnswl).


> A healthy portion of my spam folder is DMARC-signed, so that does a
> lot of good, in that regard…
Those domains are bad.  Knowing their reputation, their messages could have 
gone to the spam folder based on authentication rather than content.  
Reputation, as standardized by rfc7073, is normally not used.  Even if 
reputation is a key ingredient, it's not up to SMTP to mention that mail sites 
should maintain (and share) a database of email identities.


> But for defining the anti-spam technical solution itself, that SMTP really
> doesn't need to be involved in this particular discussion.

I agree SMTP shouldn't specify authentication protocols.  (BATV was one of the 
early ones, it is not mentioned in any rfc*21, and that's good.)  However, 
authentication in general ought to be mentioned.  In addition, there are traits 
of rfc5321, such as Section 3.9 "Mailing Lists and Aliases", which deserve 
being restructured not just to comply with DMARC, but to establish more clearly 
who is responsible of what.  Mailing lists and email address portability are 
currently considered SMTP core features.  They are such minor parts of the spec 
that rfc5321bis could leave them out, delegating them to some ancillary spec, 
without altering the protocol so much as to have to get back to proposed 
standard.  Such a reshaped, simplified SMTP really wouldn't need to be involved 
in these discussions, but we aren't there yet.


Best
Ale
-- 

[*] 
https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/

signature.asc
Description: OpenPGP digital signature

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