Well, I am waiting for SPF support (and the other tools being developped)
and I plan to use them as a tool, not as a God Ex Machina that will decide
what to accept or reject.
I will use it to help tag what I think is spam and let the end user deceide.
I can't make a decision for them about if they decide to accept it or not.
Some of my users need to see those adds for online casino and most don't.
I make the decision to accept or reject spoof e-mail because some are valid
(greeting card and so one) and some are not.
SPF and Caller-Id and SRS are tools that you deceide to use or not.
At last, something is moving in the mail area and judging from the trafic
here and the trade press, everybody is real interested to make it happend.
I don't expect a perfect word but anything that will help me control the
more then 1000 spam msg a day I personnaly received will help. And if it
help protect my organisation from spoof e-mail send in our name, the better.
And if it allow the number of virus we received to drop, it will make my
day.
--------------------------
Daniel Bourque
Loto-Québec
via BlackBerry
-----Original Message-----
From: David Woodhouse <dwmw2(_at_)infradead(_dot_)org>
To: Laszlo Toth <lazzlototh(_at_)hotmail(_dot_)com>
CC: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
<spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thu Feb 26 14:54:15 2004
Subject: Re: [spf-discuss] General Status of SPF
On Thu, 2004-02-26 at 13:10 -0500, Laszlo Toth wrote:
I see some big vendors such as CypherTrust now offering SPF
and am wondering if this is really safe to purchase and use in the
corporate
environment. Any comments or links to documents with the summary of the
where SPF stands would be appreciated.
Policy decisions are, of course, something which you have to make for
yourself.
For what it's worth, and at the risk of sounding confrontational given
the forum, I have to admit I recently considered this and decided that I
couldn't, in good faith to my users, either publish or 'obey' SPF
records.
The concept of SPF is based on the assumption that no hosts out there
legitimately forward email without changing the sender address. That
assumption is not valid in the general case, at the present time.
There are schemes (SRS) proposed to work around this flawed assumption
by making it true, but they need to be implemented by every forwarding
host on the Internet before the assumptions of SPF become generally
valid.
Even given an acceptable such scheme, it would have to be extremely
widespread before I could consider enabling SPF-checking when receiving
mail for my users.
Since there are hosts out there which aren't even updated to be capable
of ESMTP yet, and since the latest proposed SRS scheme turns a
participating host into a partially open relay -- to the extent that my
ISP has indicated they would consider such participation to be in
violation of their Acceptable Use Policy -- my personal belief is that
the chances of it becoming ubiquitous are far exceeded by the chances of
a successful porcine implementation of RFC1149.
Therefore, I cannot obey SPF records and reject mail from 'unauthorised'
IP addresses without a significant risk of false positives.
Similar logic applies to my decision whether to publish SPF records for
my domains. If I publish records, then my users may not be able to send
mail to third parties who, in accordance with well-established practice,
forward their mail from some virtual domain or forwarding account to
their 'actual' current email address.
For these reasons, I consider it impractical at this time to publish SPF
records for my own domains or implement SPF checks at my own sites.
However, I _am_ considering the use of SPF in a different fashion, to
bypass the normal SMTP sender-verification callouts in the case of
sending mailhosts which _do_ have a 'positive' SPF result. Although that
might reduce the (admittedly negligible) cost of such callouts, such an
optimisation would also mean that I may accidentally accept mail from
domains which don't accept 'MAIL FROM:<>' or 'RCPT TO:<postmaster>', so
I may yet decide not to implement it.
--
dwmw2
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-20040209.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù11{W]?Ú