-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 21 July 2004 10:48 am, Michel Bouissou wrote:
"SPF pass" doesn't mean in any way "All the mail coming from that server
and claiming to be from me is actually from me".
"SPF pass" means "This server is a legitimate and usual sender of e-mail
coming from my domain". That's all. And that's already nice, as an "SPF
fail" will then mean "This e-mail comes from an unauthorized server and
should be discarded as it most probably forges its origin".
SPF is not (and I believe it wasn't meant to be, in the first place) a
means for assuring at 100% that a given message bears a true origin or a
forged one.
So you are saying that it is a legitimate sender of email, but the email it
sends may not be legitimate? That makes absolutely no sense.
If it isn't a legitimate sender (but not an illegitimate one either), then
publish it with '?'. That conveys what you want: This server sometimes
sends legitimate mail, but sometimes it doesn't. I can't tell you
definitively at this time - you'll need to do some more checking on the
individual messages.
Otherwise, there will be no way for a company like Amazon to say "These
servers ARE legitimate, and ONLY send legitimate mail. Do no further
investigation into their legitimacy."
SPF is meant to help detect most forgeries easier in the vast majority of
cases.
That is one of the purposes. If we only get this purpose fulfilled, then SPF
will be a success.
But there are other purposes. As I have said before, we are already doing
what SPF does. If you want to send bulk mail to AOL, you call them up and
tell them which servers represent you. And then they list those as being
your servers, and they hold you accountable for what those servers do.
If we don't get this mechanism through SPF, then we will have to do it some
other way, because this method is becoming unmanageable.
Suppose "my-little-domain.com" relays its outgoing mail thru its IAP's
server. Then it will be logical for "my-little-domain.com" to configure
their SPF record as to state that their IAP's server is a legitimate
sender of mail from their domain.
But that in no way means that EVERY mail sent by others thru this IAP's
server actually comes from "my-little-domain.com". Some could be
forgeries made by customers of the same IAP.
If you can't trust IAP, then don't list them as a legitimate server! Why
would you tell me to trust them if you don't even trust them?
List them as '?' or something. Use additional methods (DK etc..) to verify
the mail. Whatever you do, don't lie about whether or not I can trust the
server.
Better yet, if you can't trust IAP, don't use their services!
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA/rJRBFeYcclU5Q0RAifBAJ9nZGKHWlrmfjYzbD59oD3TtpF+fwCgwB6d
KQjYWIKGnX5K0juhYl93F3Y=
=Qy46
-----END PGP SIGNATURE-----