This thread from the qmail list
http://www.ornl.gov/cts/archives/mailing-lists/qmail/2003/10/msg00257.html
is worth reading; it revisits the greatest objections to SPF. They are
valid concerns and I wish we had better answers to them.
| Hello,
|
| Slashdot just pointed me to <[10]http://spf.pobox.com/>, which has me
| disturbed.
|
| The basic idea of SPF is to prevent spoofed return addresses, by adding a
| DNS entry of the form IP.in-addr._smtp_client.DOMAIN with TXT field of
| "spf=allow" to authorize that IP to send email with user(_at_)DOMAIN as the
| envelope sender.
|
| Naturally this bothers me greatly, since I use DynDNS to run my own email
| server over a DSL line.
DynDNS has told me privately that they plan to publish SPF records for
user domains, so this problem is solved.
| In addition, I notice that the author seems quick to suggest
| ill-thought-out schemes. For example, SPF as described above breaks all
| relaying, such as that done by pobox.com, and he has an elaborate scheme
| of return-address rewriting so that each relay modifies the envelope to
| end in a domain it was authorized for. He then remarks, as if this is an
| insignificant detail, that "In practice, an additional cookie is required
| to limit the validity of the rewritten address; otherwise, SRS leads to
| open relaying."
On Jul 22 2003, hp.com rejected mail coming from a pobox.com IP because
the envelope sender was yahoo.com.
<istvan(_dot_)szucs(_at_)hp(_dot_)com>: host smtp.hp.com[192.151.81.13]
said:
554 <jasperii(_at_)yahoo(_dot_)com>: Sender address rejected:
This yahoo.com mail didn't really arrive via a yahoo.com mail server
I am told uol.com.br is doing the same thing now.
So even if nothing comes of SPF, it looks like pobox.com would have to
implement sender rewriting anyway.
| What's particularly scary here is that there may be a good idea hidden
| under the author's muddy thinking--but it isn't what this author is
| proposing. The only way to beat this guy might be to join him, and help
| him work the kinks out of his idea.
This is what the spf-discuss mailing list is for. Already we have made
many improvements to the basic SPF concept thanks to the community.
Thanks to Slashdot there are now twice as many people on the list, so I
expect SPF will get twice as good soon! I agree that I am a muddier
thinker than most, so any clarification is certainly welcome.
|
| The relay issue, on the other hand, I see no good solution for.
|
Sender rewriting sucks. If there's a better solution, I'm all for it.
Meanwhile, we've already written the module, and after we've tested it,
we'll upload it to CPAN.
The disadvantages of the new paradigm must be weighed against the old.
Yes, pobox.com will be forced to do sender rewriting. True, eBay will
no longer be able to legitimately forge addresses. There are other
downsides.
But this is the cost of change; for a reduction in spam, is the price
worth paying?
Debate arises. Some say yes, some say no.
This is why SPF is a voluntary mechanism.
If a domain would be hurt by publishing SPF records, don't publish them.
If a user would be hurt by performing SPF checks, don't perform them.
If an ISP would hurt some of its users by publishing SPF records, the
market will decide.
The exception is forwarding services: for them, the world is moving on,
and they need to move with it. Hence sender rewriting.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡