On Wed, 6 Jul 2005, David Woodhouse wrote:
On Wed, 2005-07-06 at 12:39 -0400, Stuart D. Gathman wrote:
Because I get 30000 forged messages per day that are indistinguishable
at the SMTP envelope level from forwarded (in your "change the RCPT only"
sense) messages. Versus < 100 real messages. And that is just a small 5
person domain.
You're again pointing out that SPF has problems with forwarding, and
using _that_ as justification for a claim that forwarding is 'abuse'.
No, I'm pointing out that without SPF I would have to chuck email altogether.
I have 0 problems with forwarding - and I do tons of forwarding from
my personal family vanity domain to mail systems of various family
members, both personal Linux servers in the basement and commercial
ISPs.
The reason we don't have any problems whatsoever with SPF and forwarding
is because we know what forwards we have setup. We don't have to
do SRS, because we know what forwards we have setup. (But we do
use SES to block forged bounces.) We don't mess with lists of IPs to
whitelist our forwarders, because that is what SPF is for - to list
IPs in a compact algorithmic form.
To come up with a scheme which cannot distinguish certain classes of
genuine mail from faked mail, and then declare that those classes of
genuine mail are therefore 'bad' in some way, doesn't make sense.
SPF perfectly distinguishes faked mail from genuine mail. That is
why it is a lifesaver. If you forward some mail to me, that is
faked mail - and I will reject it. It is faked because I did not ask you to
forward mail to me. If I *did* ask you, then I would list your domain as a
forwarder and nothing from you would bounce. (Of course, I would never
ask you to forward mail for me unless you reject on SPF fail.)
See? The perfect solution to faked MAIL FROMs.
Now, I understand that certain domains have no idea what forwards
they or their users have setup. I consider that very sloppy, but
it is none of my business. All it means is that those certain domains
can't reject on SPF fail - because they don't know which are actually
forwards, because they have lost track of their forwarders.
Nothing breaks. They just can't reject on FAIL (without breaking
stuff) until they meet the requirements - just like you can't publish
-all without breaking stuff until you meet the requirements (like
no sending from random locations without SMTP AUTH, webmail, VPN, etc).
SPF Benefits:
o participation is optional
o nothing breaks, not even "forwarding", when you meet the requirements:
- sending: you must identify all sending IPs
- receiving: you must identify all aliases and "forwarders" (relays
that rewrite RCPT TO).
o relaxed modes are available for both sending (?all) and receiving
(no rejects) to get partial benefits when you don't meet the requirements.
o nothing breaks in the relaxed modes regardless of any requirements.
SPF Drawbacks:
o if a domain incorrectly rejects received mail without meeting the requirement
(listing non-SRS forwarders), then this can cause problems:
- for the sender (whose mail incorrectly bounces), and
- for the forwarder (who must start using SRS or similar to work around the
broken recipient).
The sender can also work around this problem by getting the target
of the forward from the bounce (since the forwarder rewrote the
RCPT TO), and sending to that address instead.
The fact that one party, the recipient, can cause problems for two
or more other parties with their configuration error is a drawback.
This drawback is easily avoided by always starting in the relaxed
mode (no rejects) for receiver policy, and only switching to strict
mode after several months of log entries indicate that all authorized
forwarders are accounted for.
Really, what more can you ask for? If you don't like SPF, just ignore it.
Nothing will break when people implement it properly. We are trying
to educate people. We need tutorials on the website. If bad implementations
are causing you pain, then get up to speed and help educate people.
I sure wish the openspf.org with docs was open for business.
BATV and SES are great too. I use SES to block forged bounces. I don't
currently use them for authentication because of the replay problem, but I am
open to solutions (like message body hashes), and have spent time on the SES
project.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.