On Sat, 2 Dec 2006 17:48:43 +0100 Alex van den Bogaerdt
<alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:
Some people involved in SPF think it is a good idea to publish
something like: "v=spf1 ?include:outbound.mailhop.org -all"
in this case. Others, and I am one of them, disagree.
Is dyn-dns authorized to send your mail? Then it deserves a PASS.
If forgery does happen, you expect dyn-dns to react and (virtually)
kill the forger.
I'd reserve "?" for "don't know". For instance, you think you have
migrated all users to your brand new mail hub, but some people may
still be using provider "x"'s servers to send their mail. In such
a case you could "?include:x".
Whatever you do, don't publish ?include:... and ?all in the same
policy. That would be silly, as you could easily remove "?include:..."
in such a case and end up with effectively the same policy.
Be aware that if you opt to publish "?", there are implementations
that reject mail from such places. If you're not sure you want to
authorize the server, they don't want mail from it...
I'm one of those people...
First, the behavior that Alex describes in his last message exists, but is
explicitly contrary to RFC 4408 and is, in my experience, quite rare. A
larger concern is that Neutral SPF results will get you a small positive
(more spam like) score with SpamAssassin 3.1 and later.
Currently the risk associated with cross-user forgery is small if you are
just being used as a random spammer mail from domain. There are plenty of
non-SPF domains out there they can forge more easily. The risk level may
be different if someone has a particular reason to try and forge your
domain.
Additionally, domain name based block lists and reputation services are
being deployed now (Hotmail - which unfortunately uses SPF record for their
Sender ID checks - keeps a different reputation set by domain name for
Pass/not-Pass mail). These types of services increase the consequences of
giving a Pass to someone else's mail.
In the end it's a risk/benifit trade and not everyone will come to the same
conclusion.
Scott K
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735