In
<1082898434(_dot_)3543(_dot_)38(_dot_)camel(_at_)localhost(_dot_)localdomain>
David Woodhouse <dwmw2(_at_)infradead(_dot_)org> writes:
On Sat, 2004-04-24 at 20:21 -0400, PARIS wrote:
What happens if a person uses his business internet connection to send
email using his hotmail return address. Thus he will be sending
legitimate mail but from the business IP which of course is not
listed. So according to the DOC. THe message will be bounced.
You are correct.
That message which you (reasonably) call 'legitimate' is declared by the
SPF proponents to be illegitimate, because it should in their eyes have
been submitted via SMTP AUTH via hotmail's servers -- perhaps over the
MSA port since so many dialup providers firewall port 25.
Paris:
I think Lars already gave you a much more accurate answer to your
question. *IF* hotmail decides to have a policy that says that you
can only send email via their servers (they haven't done so yet),
*THEN* you should respect that policy.
Basically, SPF does not work with today's email system
Today's email system allows anyone to send email claiming to be from
anyone. If someone wants to send out kiddy-porn forging the
cshore.com domain name, there is little you can do about it. Anything
that changes this ability to forge anyones domain name breaks certain
parts of today's email system, some of which is used by legitimate
people.
This is something Dave is well aware of, but chooses to overlook.
[SPF] requires
everyone to start using SMTP AUTH (even when it's firewalled),
This is not true Dave and you know it. If a domain owner doesn't
explicitly create a restrictive policy, then, just like today, people who
have email addresses in that domain can go one working just like they
have. Domain owners can create very flexible policies if they want
to. This includes allowing a small number of emails from anywhere,
while limiting large scale forging of email. Domain owners can also
create per-user exceptions for people who work from home and such.
, and [SPF]
also requires some even more convoluted behaviour when forwarding email.
This is true, although the problems with forwarded email is not
turning out to be as bad of a problem as I (and many others) had
expected.
If you want to deploy SPF on a production machine then I would suggest
that you should wait until the new RFC replacing RFC2821 is released,
standardising these changes which are required by all mail hosts.
It is unlikely that any new RFC will replace RFC2821 as there appears
to be nothing that SPF conflict with RFC2821. I say "appears" only
because you can never get an absolute ruling on such things. Folks
that have *written* many of the email-related RFCs, however, have
reviewed SPF (and similar systems) and have found no conflicts.
It *IS* likely, however, that there will be some new RFCs released
sometime this year that standardizes several things related to SPF.
There is even a good chance that one of these new RFCs will be
effectively the same as the SPF spec. (The other RFCs will likely
address parts of the email system that are not addressed by SPF.)
Then wait another few years until compliance with that is ubiquitous,
and _then_ consider whether you can start to use SPF.
There are hundreds of thousands of domains that have SPF records
already. The number of people actually checking SPF records is much
harder to determine, but there appears to be somewhere between 500,000
to 5,000,000 emails that check against SPF records every day.
It is this large volume of email that is actually being check against
SPF records that have already been published that leads me to believe
that things like the problem with forwarders is not as big a problem
as it was initially thought it would be.
-wayne