-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Discussion with Scott Kitterman and others has brought to my attention some
misunderstandings. In particular, what does an SPF PASS result really mean?
Meng and others want SPF PASS to mean that a message is authentic - that it
really comes from the domain it claims to come from. I will call this the
"AUTHENTIC PASS" result.
I believe however that SPF can't tell anything more than authority - whether
the sending MTA is authorized to send messages for the domain. Just because
an MTA is authorized, doesn't mean that the message is authentic. Further
tests may be needed to determine authenticity. I will call this the
"AUTHORIZED PASS" result.
These two positions are very similar to each other. In fact, people who feel
like I do (AUTHORIZED PASS) may also feel like Meng does (AUTHENTIC PASS)
because they feel that authorization implies authenticity, at least at this
point in time. Maybe in the future something like Domain Keys comes along
that will allow us to more effectively distinguish the two, but for now, we
have to roll them together.
The problem arises when using a third-party relay MTA that is shared among
many domains. Let's say example.com is sending mail through esp.com's MTAs.
So they list any server authorized to send mail for esp.com as their
authorized server.
There are experienced crackers who take advantage of weaknesses in esp.com's
setup to send email that claims to be from example.com through esp.com's
services. Perhaps they have subscribed to use esp.com's services, or
perhaps not. Receiving MTAs will get an SPF PASS result for these forged
messages.
example.com has no way of controlling these messages short of reactive
methods. They can contact esp.com and ask them to launch an investigation
into the spam being sent in their name through esp.com's services. esp.com
will be able to track it down to cracker.com and hold them responsible.
example.com can aldo discontinue services with esp.com.
There is no proactive way that example.com can prevent this from happening.
If the receiving MTAs believe that an SPF PASS means AUTHENTIC PASS, then
they will incorrectly attribute the email to example.com, and example.com's
reputation or accreditation will suffer.
If the receiving MTAs believe that an SPF PASS means AUTHORIZED PASS, then
they may subject the message to further scrutiny, such as Domain Keys or
other checks.
The knee-jerk response is not to use shared MTAs. But that is an expensive
option for most people. This would raise the cost of sending email
significantly for many legitimate emailers.
As far as a complete resolution to this problem, we can do the following:
(1) Ignore this problem, claiming that it won't happen on a large enough
scale. For instance, if esp.com is susceptible to these kinds of attacks,
and they do not fix their services, they will go out of business as domain
owners transfer their services to more reliable and secure ESPs. One may
also claim that your own servers are just as likely to get compromised as
esp.com's.
(2) Make clear the problems of using a shared MTAs for outgoing mail;
perhaps example.com should list esp.com's server as a NEUTRAL (?) result
and not as a PASS result. This would subject the message to further
scrutiny.
(3) Change SPF so that an SPF PASS result claims nothing more than
authority. Leave authenticity checks of individual methods to some other
protocol.
(4) Make a new result, something like "SOFTPASS", or "PERMITTED". This
result would only assert authorization, leaving authentication to some
other method.
(5) Add additional checks for authenticity in SPF, or leave that as an
option. This would make it so that an SPF result cannot be obtained in all
cases before the message is sent. In particular, Domain Keys may require
the entire message to be sent, and so checking Domain Keys will have to
cause SPF to return a "NEED MORE INFO" result before the checking can
resume and be completed. Perhaps PGP or S/MIME could be used for this
purpose as well.
Any other options? Any ideas?
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA4awIBFeYcclU5Q0RAkqfAKDNzxKAVbsUur93xWlhXNvkpIS/RgCgvL9z
/NOTtN8aS8vjyO6C0S30ERs=
=fo1G
-----END PGP SIGNATURE-----