From: Stuart D. Gathman
Sent: Friday, June 11, 2004 12:37 PM
On Fri, 11 Jun 2004, Seth Goodman wrote:
Since you propose that recipient MTA's should all maintain
trusted forwarder
lists, is there really any need for originator tests? Playing
the devil's
advocate here, if all recipients maintained trusted forwarder
lists, there
really isn't any need for SRS, either. If we need SRS because
not all sites
have forwarder whitelists, we also need originator tests, since those
recipients can't distinguish a trusted forwarder from a forger.
How do we reconcile this?
Simple. All of the above.
Let forwarders chose between DBBF,SRS,RSR , (even SUBMITTER).
Let recipients do SPF checking, plus one of forwarder whitelisting,
CBV (pref via DNS) validation.
Senders should publish SPF. They can also do SES to screen
forged bounces.
They can also publish SES validation via DNS to allow efficient validation
(without SMTP).
"Legitimate" sender forgers should stop lying.
This all makes a lot of sense. "One size fits all" is not a good
prescription for success. I like the idea that recipients can select
between using a local forwarder list (recommended) or attempt to do
originating address validation (second choice). Another alternative that
this gives recipients is to have a trusted forwarder list, but still accept
mail from untrusted forwarders if the originator address can be validated.
That's probably the most robust implementation.
I also like the idea that forwarders have a choice of three forwarding
protocols (or doing nothing).
Everything mostly plays together nicely. Exception, DBBF forwarders must
be whitelisted.
Because of this, we should probably forbid SRS at the originator using DBBF,
since you can't tell if it is an originator message or a forward. SRS0 at
the originator is fine, as we can tell that it is an originator message.
Having an assurance of the domain sending you the email, and possibly
even of the originating domain, the foundation is laid for layer 2:
giving the user assurance that the 2822 headers are authentic.
Everyone's email needs are so diverse, it would be a mistake to try
and make "one size fits all". We are providing a set of tools that
are compatible with one another. Specific configurations of these tools
are more appropriate for giant providers like AOL or small businesses
like where I work.
The one tool that has not been specified very well is the SES validation
via DNS. The recipient needs to know when MAIL FROM has SES (checking
whether is starts with SRS0 or SES0 is reasonable). There is no standard
that I am aware of for the DNS query. CBV via SMTP works well enough, but
is expensive for both sender and recipient (including all the recipients
using it to ignore forgeries).
I agree that looking for SES0 or SRS0 with the originator and forward
domains the same is a reasonable way to detect an originator signed envelope
address. _If_ the recipient has a need to validate the originator address
i.e. they do not use a trusted forwarder whitelist, they would then query
the SPF record for the originating domain. Presumably, the SPF record would
contain an exists modifier with appropriate macros to query the DNS server
and get it to validate the address. I'm not very good with SPF macros, but
here's an attempt at a proposal. Please feel free to improve this!
v=spf1 a mx ses:%{L}._ses.example.com -all
where ses = new modifier that says all mail is SES signed
and provides an 'exists' string to validate it;
if there is no colon and string after this
modifier, it means that all mail is SES signed
but there is no DNS mechanism to validate it
L = new macro for local part of originating domain
If we get the following from the SMTP-client, assuming RSR address format,
MAIL FROM:<@forwarder:SES0=76ah=7G=user(_at_)orig-domain>
and we do _not_ have a trusted forwarder whitelist, or we have one but the
forwarder is not on the list, we do the following:
1) Do SPF check on the SMTP-client using "forwarder" for the domain.
2) Query "orig-domain" for the SPF record. If there is an SES modifier
string, do a DNS query with that string after macro expansion. If the SPF
record were as in the example above, since this is a forward, we can only
evaluate the ses modifier. We would do an "A" DNS query for
"SES0=76ah=7G=user._ses.origin-domain". The DNS server would return a
DNSBL-style result: 127.0.0.x, which _could_ encode all the possible SPF
results (Mark Schewmaker's idea), though only PASS or FAIL make sense in
this particular case.
This obviously could stand some fleshing out, but I think that's close to
what we've been discussing. In particular, I don't know if an "A" query to
the _ses subdomain would be sufficient to hook the code for doing the SES
address validation.
If we have this new modifier that says all outgoing mail is SES-signed, we
get to Roger's point that the domain owner is asking everyone to validate
his SES-signed address before accepting the message. To do that, we would
_always_ have to check the originating domain's SPF record to look for the
ses modifier. We could do that, but I think that if we have a trusted
forwarder list and the message came from a whitelisted forwarder, this is
redundant. OTOH, we _could_ take the position that the domain owner says to
validate the SES address so we will validate it, even if it wastes his DNS
resources. If there were _no_ trusted forwarder list, then we should
_require_ the recipient to query the originators SPF record and look for the
ses modifier. Perhaps lack of ability to validate the originator address in
this case should give an SPF result of NEUTRAL? Any thoughts?
--
Seth Goodman