From: Meng Weng Wong
Sent: Wednesday, April 07, 2004 5:54 PM
<...>
Instead, perhaps we can borrow another concept from the postal service:
different classes of mail. ...
This is rational, given there is no easy way validate the RFC2822 originator
addresses. However, I believe there are several ways to do this, and I
posted one such method on the list the other day. If you are uncomfortable
with "yet another validation scheme", those "SES0" addresses can _all_ be
changed into SRS0 format addresses so it is completely in accordance with
your existing plans. Given the fact that we _can_ unambiguously validate
each address, including the local part, without any additional DSN info,
maybe you would comment on why there is a need for multiple mail classes?
The method I gave, and others similar to it, can detect forgeries of each of
the critical addresses. If anything is forged, the mail is rejected and a
DSN goes back to the sender. Isn't that simpler than multiple mail classes?
<...>
IF: 2822 "From" == 2822 "Sender" == 2821 return-path
&& (SPF || Caller-ID) pass
&& (To: || CC:) == recipient address
&& reputation system recognizes the sender (eg. whitelisting)
THEN: it's first class.
IF: (SMIME || PGP) signed
&& 2822 "From" matches the signature
&& reputation system recognizes the sender (eg. whitelisting)
THEN: it's first class.
IF: 2822 "Sender" == 2821 return-path
&& (SPF || Caller-ID) pass
&& List-ID shows up
&& recipient acknowledges they're subscribed to the mailing list
THEN: it's a first-class mailing list.
IF: 2822 "Sender" == 2821 return-path
&& (SPF || Caller-ID) status unknown
&& List-ID shows up
&& recipient acknowledges they're subscribed to the mailing list
THEN: it's a second-class mailing list.
IF: 2822 "From" != 2821 return-path
&& "To:" and "CC:" do not match a known recipient address
&& message appears to be a mailing list
&& recipient does not recognize the mailing list
THEN: it's third class, possibly spam
IF: the reputation system does not like the sender
THEN: it's fourth class, probably spam
etc etc.
This seems consistent but for one omission: the RFC2822 Reply-To: header.
To guard against forgery, I believe it essential that we verify the
Return-Path: (RFC2821) plus the all three "originator addresses" from
RFC2822, From:, Sender: and Reply-To:.
Meng: I would still appreciate a public reply to the SES class of
proposals, of which I presented one possible example. If you request, I
will post a more concise description to make this easier. This class of
verification scheme has pros and cons, and I think the list would be
well-served by actually discussing them rather than ignoring them.
--
Seth Goodman