On Fri, 2004-11-26 at 05:11, Nigel J. Carr wrote:
What I have NOT seen is a document that clearly lays out ALL scenarios
of mail traffic including legit, spoofed, bounces, NDR, receipts,
forwarding, ........, and other configurations I do not pretend to
understand. For each scenario, risks and solution(s) should be
documented. This will allow non SPF technical people to communicate
the scenario they have and the council to publish the proposed/agreed
solution/standard etc.
Other than the fact that it is extremely difficult to know what ALL the
scenarios are so that they can be laid out in a document, the only
reason this doesn't exist is because no one has been collecting any
other than what has already been posted on spf.pobox.com. I do agree
that a clearing house listing success stories and "how I did it" might
help get the word out. A wiki might make the most sense, since it would
easy for those with the scenarios to post their strategy and update
their progress.
Another problem is that this kind of exchange crops up every so often:
"Help! My users are roaming, and their email will be rejected
when sent via servers other than my own. What should I do?"
"You should set up some kind of authentication, such as SMTP
AUTH on the mail submission port, to allow your users to send
mail for your domain via your servers."
"I don't want to set up SMTP AUTH or that increases my customer
support costs, etc etc etc."
So I'm not sure how useful an exhaustive list of all deployed scenarios
would actually be -- people who actually WANT to do it will figure it
out (with or without the help of people here) and those who don't won't.
SPF is not about helping people set up their networks, like getting SMTP
AUTH working or making changes to DNS -- although there are lots of
people here who would be willing to help or get people pointed in the
right direction. There are just too many variables in those kinds of
things to speak with any kind of blanket authority (notice the SPF
wizard tries to do this for putting TXT records into zone files for BIND
and djbdns, but those two are not the only DNS servers that people use,
although most likely the most popular). People should be visiting their
software's documentation or contacting their software vendor for help in
getting any one aspect of their network configured and running.
For example
It is recommended NOT to send NDR as it increases traffic and that is
the intent of some viruses. However when a legit email is sent but the
address is typed incorrectly then the sender is not notified that a
possibly critical email has failed to be delivered. A
solution/recommendation could be that mail that passes SPF will send
NDR as it is a genuine email that has a typo in the email address.
No where has anyone ever suggested that publishing SPF or enforcing SPF
publishers' policies should result in not sending a nondelivery report.
It is the sending host, who receives any rejections from the
SPF-checking host, who is in charge of that. As far as the sending host
is concerned, an SPF rejection is just like any other rejection, and
should generate a bounce. If the sending host is generating bounces to
unverified addresses, that's an issue that sending host is responsible
for, and has nothing to do with SPF.
Many non-MTA intrated systems that do send NDRs do so based on the plain
From: header, which SPF is not concerned with and is largely
unverifiable and untrustworthy anyway (insert standard PRA rebuttal
here).
Perhaps this should be a separate list - maybe it already is.
spf-deployment exists, yes. It doesn't get nearly as much traffic as
spf-discuss -- either people don't know about it :(, people are not
having deployment issues :), or no one is deploying :(
Andy.