Le mercredi 21 Juillet 2004 22:00, Jonathan Gardner a écrit :
No, I am saying use SPF PASS only for *trusted* sending MTAs. Trusted means
you trust them (obviously).
If I am a small company, and I have an ISP, I obviously trust my ISP. So I
will list them as my legitimate sending MTA. If I can't trust my own ISP, I
have more serious problems than sending email!
Here the question is: What exactly do you mean by "trusting" ?
Of course, I "trust" my ISP will not try to impersonate me and send spam
forged as coming from me. Allright.
BUT most ISPs perform absolutely no control on the email they accept to relay,
provided the sending machine is inside their customers' IP pools.
So if I can send thru my ISP's MTA a message "Return-Path:
<me(_at_)mydomain(_dot_)com>",
any other customer of this ISP can do the same.
The matter is not "trusting" the ISP, but knowing its servers will happily
allow that (unless they do SASL/AUTH, which is quite rare, and the day it
happens, even I will not be able to send "Return-Path:
<me(_at_)mydomain(_dot_)com>",
I will probably have to use
"Return-Path: <obscure_personal_account(_at_)bigisp(_dot_)com>".
We aren't trying to determine if something is spam or not. We are
introducing responsibility into the email system, something that is not
there now.
I don't believe that SPF is actually "introducing responsibility into the
email system".
Read the spec. It says PASS is LEGITIMATE. Not mostly legitimate, not
partially legitimate, but LEGITIMATE. The newer specs talk about
permission.
Again, this is a matter of interpretation. PASS means that the *server* is
legitimate, not that the *message* is legitimate, and that makes quite a big
difference...
--
Michel Bouissou <michel(_at_)bouissou(_dot_)net> OpenPGP ID 0xDDE8AC6E