-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony Finch wrote:
On Wed, 6 Jul 2005, Julian Mehnle wrote:
David Woodhouse wrote:
What makes you suggest otherwise? Can you describe in detail the massive
changes to existing practice which you think the alternatives would need
us to make?
Do all the Qmail or Exim or Postfix or Exchange installations out there
support BATV or DKIM already? No? Thought so.
And they don't need to. They can be completely ignorant of BATV and DKIM,
and they can still successfully interoperate with servers that do
understand them. This is not the case for SPF.
Excuse me?
My servers interact with non-SPF entities all the time.
This message being a case in point.
The "forwarding problem" is _only_ an issue for entities
that support SPF at either end. It is only a problem
for the forwarder if they care about it. Frankly, it is
only a problem at all for receivers that have forwarded e-mail
_and_ reject on SPF Fail _and_ do not have the means to whitelist
their forwarders _and_ whose forwarder doesn't reinject.
There are enough places to "fix" this problem appropriate to
individual configurations that I consider it a non-issue.
1. Instead of forwarding use IMAP to fetch multiple mailboxes.
Most of the less tech-savvy people I know do something like
this already, they don't know _how_ to forward their e-mail
to a single location.
2. Have your forwarder reinject. This requires more access, but
I'm pretty sure you can get there with procmail.
3. Whitelist your forwarders. I mean really folks, it isn't that hard.
A perl script can extract mismatched (MAIL FROM)/IP pairs for
evaluation from the logs if you don't know already.
4. If you can't (or don't want to) do any of the above, don't reject
on SPF Fail.
The "forwarding problem" isn't that big a deal.
Really, it isn't.
It might be a bit painful for AOL or Earthlink to deal with to the point
that they can reject on SPF Fail and publish -all, but any effective
solution is going to be painful to implement for large entities like
them. SPF is at least less painful (and less costly in $$, CPU, and
bandwidth) than any other solution I've seen that attains similar
functionality, and that is really what it is all about.
You think that calculating message checksums is painful for a site
processing 1M messages a day? Or that SpamAssassin is a CPU hog?
Put yourself in Carl's shoes. AOL has to be processing at least 100M
messages a day. Anything that cuts down on their load from junk
messages is a good thing. Frankly, I'm a bit surprised they aren't
rejecting on SPF Fail yet. That would probably save them kilobucks a
year in upgrade costs alone. At only a 10% publishing rate.
- --
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCy8+G8/QSptFdBtURAhVfAJ9BSIFqkd1o/qI/79RmkIYzaWrjlgCfVnhD
fsesuTwfPNzKp57TF2iv2vg=
=N+bG
-----END PGP SIGNATURE-----