Stuart D. Gathman wrote:
On Wed, 4 May 2005, Radu Hociung wrote:
This would be a transitionary use of %{l}, but no plans to use it long term?
Example long term uses:
o FAIL unauthorized user names when some users are allowed to send external
email, and others aren't. Should be enforced internally as well, but multiple
layers are always good.
The problem I have with this is that if your domain is heavily forged,
you are essentially asking innocent bystanders to perform more DNS
queries than needed to detect the forgeries.
The rules on who may send mail and who may not is really a matter of the
sender's local enforcement. In a sense, it is the dirty work that is not
nice to ask remote domains to do for you.
I think this should be enforced *only* internally.
o Even after publishing -all, track which new users have ignored the
bright yellow READ ME FIRST instructions that came with their account
information so that tech support can contact them.
As Theo pointed out before, this makes it all to easy to harvest emails.
Also I believe new users who ignore the configuration instructions will
not be a problem long term. Eventually, if SPF is generally adopted, new
users will not be able to even get their first message out.
I especially like the exp= modifier as it can be used as "I told you do"
to your users. (Ie, when a message bounces due to failed SPF, your exp=
message will be included in the bounce). I believe texts like the
following may be effective.
"Your mail software is misconfigured. Please follow instructions at..."
I won't try to come up with too many, because you can probably find
better ones than I can.
The message I use myself is:
"Dear %{s}, please send mail only through mail.ohmi.org port 587 using
your login password"
Also the nice thing about exp= is that it can be in the language of the
user. Ie, a German domain may publish a German language exp=, a greek
domain would publish a message in greek, and so on. But the bounce
message itself is probably in the local language too.
o Even after publishing -all, track which users have zombies on their home
PCs.
Do you really think the SPF record should be your first line of defense?
I would have thought blocking port 25 is the first. The next best thing
is monitoring your network traffic. By the time you get the query that
tells you they're infected, the traffic is already out there. Recipient
domains that don't check SPF will accept the viruses as your domain's
creation.
When the user of your domain is connected on a remote site, it is that
site that will do port 25 filtering.
I believe this use of %{l} is not too wise.
A saying I like goes like "When you've got a hammer, everything looks
like a nail". SPF is that kind of hammer in this zombie context.
Radu.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
smime.p7s
Description: S/MIME Cryptographic Signature