You said: "My point above was that at Amazon, it
was extremely easy to get it setup and running,".
But you did not do it correctly!
You don't have spf records for these domain names:
www.amazon.com
ftp-1.amazon.com
ftp-2.amazon.com
ftp-3.amazon.com
And many more I would bet.
So, someone could send mail and fake the address:
payments(_at_)www(_dot_)amazon(_dot_)com
Or any address @www.amazon.com.
Some people would think payments(_at_)www(_dot_)amazon(_dot_)com is a real
email address!
See:
http://spf.pobox.com/faq.html#allsmtp
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
"Do I have to publish spf for each of my smtp servers?
No. You should publish spf records for each and every domain you wish to
protect from being used by spammers/virusses. If, for example, your domain
is somedomain.tld and you furthermore have a subdomain www.somedomain.tld
registered, you would publish for both somedomain.tld and www.subdomain.tld
(the latter probably being set to "v=spf1 -all"). Note that you will have to
publish for each and every A record, including any wildcard (*) or @ entries
in your dns."
I think this is not clear. It should not start out with "No.". It start
with "Yes, and more!". Every hostname/sub-domain/domain that you want to
protect should have an spf record.
I missed this one myself. But I realized that it was needed and asked the
group for help. Now I know what to do. Just add a txt record for every
host/domain you have! Like these:
www.amazon.com. txt "v=spf1 -all"
ftp-1.amazon.com. txt "v=spf1 -all"
ftp-2.amazon.com. txt "v=spf1 -all"
ftp-3.amazon.com. txt "v=spf1 -all"
A wildcard record will NOT work. You CANNOT, MUST NOT and SHOULD NOT use
this!
*.amazon.com. txt "v=spf1 -all"
I hope I helped!
Guy
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of
Jonathan Gardner
Sent: Monday, September 13, 2004 4:18 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: Concerns on SPF Unified
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 13 September 2004 02:25 am, Stephane Bortzmeyer wrote:
On Fri, Sep 10, 2004 at 10:58:13AM -0700,
Jonathan Gardner <jonagard(_at_)amazon(_dot_)com> wrote
a message of 75 lines which said:
(1) SPF is simple. Most people with only a casual understanding of
SMTP will get it.
I believe you are quite over-optimistic: at the present time, most SPF
users are experts and convinced experts. When we'll see wide
deployment of SPF, we will have to face a lot more problems, showing
that SPF is not "simple" (I mention it as the author of two lectures
on SPF, one for techies and one for managers).
I don't believe for a moment that there are 100,000 experts in SMTP
world-wide. Even I myself am not an expert in SMTP, yet I was able to get
SPF published for Amazon, with "-all" even.
And my point is that we need a system that doesn't need an expert to setup
and configure, so it is important to realize that there aren't enough
experst in the world to do what has been done with SPF already. SPF Classic
is already drawing on the "expertise" of non-experts.
If you believe that SPF Classic is only deployed by experts, then you should
be arguing that SPF classic is already too complicated, not that we need an
even more complicated system.
(2) Deploying SPF records is extremely simple. You don't even have
to understand SMTP to publish.
So, why people do stupid mistakes like the one in nordnet.fr?
That is the exception, not the rule. And it isn't because they don't
understand SMTP, it is because they are sloppy.
(3) Checking SPF is pretty easy. All I have to do is configure my
MTA a bit and add some code.
...
We spent more time talking about SPF at Amazon than deploying
SPF. It literally took less than 10 minutes to get published.
We are not talking about Amazon email experts. We are talking about
Joe Sysadmin at smalldomain.com.
It sounds like you are arguing my point - that we need a system that
non-experts can setup and configure. My point above was that at Amazon, it
was extremely easy to get it setup and running, and we had the overhead of
being a big organization with lots of people involved in making hard
decisions. How much easier or harder is it going to be for one man shows? I
claimed that it is not by much, either way.
Now, onto SPF Unified. All of a sudden, the simplicity is lost. Now
people need to familiarize themselves with the SMTP protocol to a
level that isn't generally necessary. They have to learn about a new
algorithm - PRA - and it's arbitrary ordering of headers. They have
to figure out which way they want to deply - SPF/HELO, SPF/MAILFROM,
SPF/PRA, etc - and that is not an easy decision to make, let alone
even to understand.
This simply reflects the complexity of the real world. SPF tried to
simplify the world (pretending there is only one identity in email,
envelope from, while there are many, each with its strengths and
weaknesses). Unified SPF tries to acknowledge the fact that there is
no consensus on the best identity (probably for a very good reason).
The best solutions mask the complexity of the real problem. They do this by
making decisions that will work for the overwhelming majority of their
users. In the case of email identities, while it is true that there are
several email identities at present, SPF Classic is successful because it
makes a decision to only trust one of those identities. This has the
drawback that other identity schemes will conflict with the SPF Classic
identity. But the beauty is that if SPF Classic becomes an internet-wide
standard, then there will only be one identity and the complexity of email
in general will be *reduced*.
- --
Jonathan M. Gardner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBRgBsBFeYcclU5Q0RAjHUAKCP/FmLT4wZI2TybP7OSrinRYB0tQCffm92
+uJBFrM0VfV8V+B/6wJoknU=
=yJw9
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
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