On Tuesday, March 4, 2003, at 11:10 PM, Troy Rollo wrote:
This breaks automated forwarding.
Couple solutions to that, most of which are documented
pretty well in
Gordon's proposal (
http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt ).
Actually it says "Another document will identify similar problems and
solutions, including mail forwarding services and the Null Sender envelope
(MAIL FROM:<>)."
It was strongly suggested to deal with that in another document to avoid
clouding the problem that draft tries to tackle. The above doc deals with
secondary MXes only because they're the most popular thing that DS is going
to break.
The problem is that this approach assumes that the only significant reason
mail with a given domain can come from a location not in a pre-authorised
set is that it's spam.
Actually, it assumes the only reason mail with a given domain is not from an
authorized location, is that it's simply not authorized. Wether it's spam
or not isn't immediately relevant, aside from the indirect fact that a good
chunk of spam has fake envelopes. This protocol could also break e-mail
worms since the majority of those fake the sender envelope.
Mail forwarding is going to break no matter what proposal is adopted to
prevent domain spoofing. I wanted to write another document to address that
very problem, but here's a preview.
Mail forwarders could modify or augment the sender envelope such as
(simplistic example):
sender(at)example(_dot_)com(_at_)forwardingservice(_dot_)foo(_dot_)bar
Or, it could replace (or encapsulate) the sender envelope entirely:
(hash-of-sender-envelope)@forwardingservice.foo.bar
I can hear you all cringing at that.
Null Sender (MAIL FROM:<>) envelopes could be checked further, to ensure
that they come from an actual MTA running on a host, and not from a person,
by checking all kinds of stuff: forward DNS, rDNS, a RMX or DS record, and
whatnot.
I think spoofing's become so much of a problem that mail forwarders will
have to redesign mail forwarding. I think that's why I've been told not to
tackle the problem in the DS document - because forwarders could come up
with their own ways to deal with it.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg