spf.pobox.com -> spf.pobox.com/
SMTP has a security hole: any connecting client can assert any sender address. The result: your mailbox fills up with bounces to messages that you didnt send. Close the hole, and we can easily block spammers by sender domain. In this mode, an MTA uses SPF to verify the envelope sender SMTP MAIL FROM address during SMTP time. But some people pointed out that SPF can also be used to verify headers to prevent phishing. When used to verify headers, the agent could be an MTA or an MUA, and slightly different rules apply: you have to consider Sender and Resent-From as well as just the From: header.
As a reminder: SPF is designed to protect the envelope sender so you dont get bounces that say You sent us a virus. Caller-ID is designed to protect the headers so eBay and PayPal can limit the damage of phishing spams that say Your credit card has expired, please re-enter it here. If you are annoyed by viruses that cause you to get bounces, you should publish SPF. If you are a big institution or a bank and are concerned about phishing, you should publish Caller-ID records as well, but first you should check with Microsoft because you may need a technology license;
February 12th 2004: An eWeek article discusses SPFs interaction with the IETF standards process. While it would be really nice to see the SPF draft approved as an Experimental or Draft Standard within the next few weeks, the conservatism inherent in the IETF process may require that we follow procedure, hold a BOF, charter a Working Group, and meet a few times over the next year or two. Conservatism has served the IETF well in the past, and you certainly dont want to rush something as important as this. But the problems are urgent, and people are beginning to abandon email entirely. February 11th 2004: The spec has been published as an Internet-Draft with the version number 00. Oh, and we changed the name from Sender Permitted From to Sender Policy Framework.
|
http://csua.com/feed/