Re: [swinog] hotmail requires sender id
Ignore it and if a hotmail customer complains to you, tell them their hotmail SPAM filter is busted and you can not do anything against it. The hotmail users should start yelling at Microsoft and not at anybody else. I wouldn't see it so bad. First, they'll start in november which leaves some time to the rest of the world to adapt to the situation. Second, I think it's a good point to promote SPF ( I know we already hat the discussion about whether SPF is good or bad ). Third, it seems as if the message will only be tagged as spam and not deleted or rejected. It's like giving spamassassin a high score for SPF. With AOL and now Microsoft (counting only the really big ones) adopting SPF I see a real chance for this technology to be successfully used. Best regards, Jean-Pierre -- HILOTEC Engineering + Consulting GmbH Energietechnik und Datensysteme Tel: +41 34 402 74 00 - http://www.hilotec.com/ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] hotmail requires sender id
On Sun, 2005-06-26 at 13:06 +0200, Jean-Pierre Schwickerath wrote: Ignore it and if a hotmail customer complains to you, tell them their hotmail SPAM filter is busted and you can not do anything against it. The hotmail users should start yelling at Microsoft and not at anybody else. shifting the message around a bit With AOL and now Microsoft (counting only the really big ones) adopting SPF I see a real chance for this technology to be successfully used. There is a 'small' problem with this. AOL uses SPFv1, while Microsoft is pushing SPFv2, which is not really SPFv2, but their own version of the thing which clashes with the real SPFv1 (openspf.org one) also called classic and that is the one people have been deploying the last 2 years, not the one with the PRA checks. The problem here is that Mickeysofts version of SPF breaks all SPFv1 installations The IESG has apparently given both drafts (SPFv1 + Sender-ID/SPFv2) the chance to go to experimental RFC. I wouldn't see it so bad. First, they'll start in november which leaves some time to the rest of the world to adapt to the situation. Second, I think it's a good point to promote SPF ( I know we already hat the discussion about whether SPF is good or bad ). Third, it seems as if the message will only be tagged as spam and not deleted or rejected. It's like giving spamassassin a high score for SPF. loadplugin Mail::SpamAssassin::Plugin::SPF Default on debian: /usr/share/spamassassin/25_spf.cf | handsnipper 8- # SPF support. pass is nice, fail is bad, softfail is bad, but # not as bad as fail. ;) These are more trustworthy results than # the SPF_HELO rules. header SPF_PASS eval:check_for_spf_pass() header SPF_FAIL eval:check_for_spf_fail() header SPF_SOFTFAIL eval:check_for_spf_softfail() describe SPF_PASS SPF: sender matches SPF record describe SPF_FAIL SPF: sender does not match SPF record (fail) describe SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) describe SPF_HELO_PASS SPF: HELO matches SPF record describe SPF_HELO_FAIL SPF: HELO does not match SPF record (fail) describe SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record (softfail) 8 /usr/share/spamassassin/50_scores.cf | handsnipper 8-- # SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's # likely that more spammers would quickly move to setting valid SPF records # otherwise. The penalties for an *incorrect* record, however, are large. ;) ifplugin Mail::SpamAssassin::Plugin::SPF score SPF_PASS -0.001 score SPF_FAIL 0 0.001 0 0.875 score SPF_SOFTFAIL 0.500 0.842 0.500 0.500 score SPF_HELO_PASS -0.001 score SPF_HELO_FAIL 0 0.405 0 0.001 score SPF_HELO_SOFTFAIL 0 1.002 0 3.140 endif # Mail::SpamAssassin::Plugin::SPF ---8 Don't forget to install the Mail:SPF perl stuff and friends. That said, I *want* to install SPFv1 records, but I am seeing it break in several of the sources where I get my mail from. For instance for the above I had to set trusted_forwarders to my upstream+secondary MX's as those boxes are not in the SPF rule of their respective domains and thus it breaks add to that quite a number of other issues, thus I hold it back for a while, in the mean time, I'll just PGP sign my stuff :) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] hotmail requires sender id
Jean-Pierre Schwickerath wrote: Ignore it and if a hotmail customer complains to you, tell them their hotmail SPAM filter is busted and you can not do anything against it. The hotmail users should start yelling at Microsoft and not at anybody else. I wouldn't see it so bad. First, they'll start in november which leaves some time to the rest of the world to adapt to the situation. Second, I I'd rather say it leaves some time to their users to move to other more useful freemail accounts like Gmail etc. There is not much point in getting forced into this SPF stupidity by Microsoft because the damage of putting SenderID records on your domain is likely greater than not doing it. And losing the ability to send mail to hotmail accounts is not really a loss. think it's a good point to promote SPF ( I know we already hat the discussion about whether SPF is good or bad ). Third, it seems as if the message will only be tagged as spam and not deleted or rejected. It's like giving spamassassin a high score for SPF. Are you sure? IIRC they are going to reject all email without SID. With AOL and now Microsoft (counting only the really big ones) adopting SPF I see a real chance for this technology to be successfully used. Be careful here. SPF =! SID. -- Andre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] hotmail requires sender id
On Sun, 2005-06-26 at 15:52 +0200, Beat Rubischon wrote: Hello! Am 26.06.05 schrieb Jeroen Massar: There is a 'small' problem with this. AOL uses SPFv1, while Microsoft is pushing SPFv2, which is not really SPFv2, but their own version of the thing which clashes with the real SPFv1 (openspf.org one) also called classic and that is the one people have been deploying the last 2 years, not the one with the PRA checks. I'm still looking for a deeper explanation. The one I found at Microsoft [1] exactly explains SPF as I know and the wizard [2] creates the same records as the wizard on spf.pobox.com. spf.pobox.com is *VERY* out of date and actually has not much to do with the classic SPFv1. The promote SenderID there and that is something that the SPF folks don't want to see, they are currently trying to decide on a site name and will the finally fix up the site, currently check: http://www.mail-spf.org/ Which has quite some up-to-date info. [1] http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx [2] http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx Do you have more information? The spf-discuss list, but that one is a bit long and I guess some others might want to have an explanation too, (even those 5 folks who are on vacation and sending vacation notices when they receive mail on a bloody technical mailinglist) Read: http://www.openspf.org/OpenSPF_community_position_v101.html Some nice URL's to read: http://www.apache.org/foundation/docs/sender-id-position.htm AOL backs away from Microsoft antispam plan http://www.computerworld.com/softwaretopics/software/groupware/story/0,10801,96022,00.html Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
