| |||||||||||||
|
| |||||||||||||
Blocking forgeries and spam with SPFBlocking forgeries and spam with SPFPosted Oct 23, 2003 3:05 UTC (Thu) by roelofs (subscriber, #2599)Parent article: Blocking forgeries and spam with SPF Does any of this have anything to do with the "From: " line, or is it all limited to the "From " line (which reflects the "actual sender" as seen by the MTA, I think, regardless of what I do in the user agent)? In other words, will pobox.com, ieee.org, acm.org, etc., all have to include an SPF wildcard record--rendering the whole system fairly pointless--or can I continue to happily "forge" my "From: " address without any changes on their side, safe in the knowledge that all this SPF stuff will only affect the "From " address, which always points to my current ISP no matter what I do? Sorry for the imprecise From:/From description, but I'm not exactly a mail-system guru... I just want my "public" address to be the one over which I have long-term control, not one that disappears as soon as I move to another state. Greg Roelofs
(Log in to post comments)
Blocking forgeries and spam with SPF Posted Oct 23, 2003 8:33 UTC (Thu) by sjdg (guest, #5384) [Link] According to the RFC, it works on the envelope header ("From "), not the embedded "From:" header. Your benign faking should be ok.Simon.
Blocking forgeries and spam with SPF Posted Oct 23, 2003 15:43 UTC (Thu) by zone (guest, #3633) [Link] Umm, no. Practically half the site is devoted to answering the "From:" vs. "From " question, and addressing the problems SPF will create with regards to that. In summary, if your users send mail with your domain, but don't always use your mail server, you need to specify "softdeny", at least until you can transition them to using your outgoing mail server exclusively. After all of your users are using your mail server exclusively, then you can set the default SPF to "deny".This is really a very large roadblock to SPF adoption for certain domains. Convincing thousands of your users to change their habits and not to use their mail server at their ISP, at work, at the cybercafe, at a friend's house, etc., but instead to always remember to specify the domain's real mail server, is not an easy task. It will be made substantially easier if MUA developers get on the SPF bandwagon and steer the user into sending through the proper mail server, but it will also take a concerted effort by ISPs and employers to educate their users. In an ideal SPF world where the Global Sunrise Date of April 12, 2004 were to actually occur (i.e. all legitimate domains have SPF records and all are set to default=deny), there would be no more "vanity domains" in the traditional sense. You'll either have to send through the domain's mail server or use the new Sender Rewriting Scheme or possibly some other contrived way. The SPF authors are apparently relying on sites that forward mail for their users to take the initiative to implement SPF-compliant solutions and notify their users. From what I can tell, SPF adoption can and probably will happen, but it's going to take a lot more than simple DNS records and spam filter adjustments. It's going to take cooperation from ISPs, corporate network administrators, mail agent developers, and unfortunately, end users. Until a significant portion of emails are sent from domains with default=deny, spam filters will be forced to take a non-aggressive SPF stance, and rely on traditional techniques when analyzing emails from domains with default=softdeny or with no SPF information at all.
|
|
||||||||||||