[Top] [All Lists]

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

2019-12-24 05:31:03
On Mon 23/Dec/2019 20:49:35 +0100 Keith Moore wrote:
On 12/23/19 1:51 PM, Russ Allbery wrote:

The most effective standardized spam filtering techniques to date that
have retained effectiveness over time and not been fairly trivially
bypassed by spammers have been authentication approaches (SPF, DKIM,
etc.), which only handle certain classes of junk (but are particularly
helpful against phishing, which for most people is the most dangerous form
of junk).  Those now seem to be clearly good ideas, but by themselves seem
unlikely to achieve the necessary outcome.

Another thing I'm wondering is whether it would help for IETF to recommend 
MSAs that forward mail to arbitrary SMTP servers on the public Internet, sign
their outgoing traffic (say with DKIM) and perhaps to define a profile for
doing so.

More broadly speaking, can we effectively raise the bar for "legitimate" email
in a well-defined way so that everybody knows what hoops they need to jump
through rather than having to guess?   And can we raise the bar in such a way
that favors legitimate mail over spam?

For instance, now that we have a spec for relaying using SMTP over TLS, if we
specified that relay of mail from the MSA to the MX of the destination domain
SHOULD use TLS with client certificates, then servers would have a more
reliable and quicker way to identify and classify senders.

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.

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.


[*] The FUSSP won't be effective until it has been deployed at more than 60% of
SMTP servers and that's not a problem.

cited by SM as in

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>