http://permalink.gmane.org/gmane.mail.spam.spf.discuss hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25225 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 08 Apr 2013 - 09 Apr 2013 Report Date: 05 May 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 2 Total Participants : 2 Total Vendor Postings : 0 Total Mail/No Replies : 2 (100%) 6+ Days Old : 2 4+ Days Old: 0 2+ Days Old : 0 1 Day Old : 0 Busiest Posting Hour : 5pm (1 msgs) Busiest Posting Day : Monday (1 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * * | | * * | | * * | | * </pre> spf-discuss< at >winserver.com 2013-05-05T13:58:01 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25224 <pre>This would be a good time for interested people to review the draft. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html Scott K </pre> Scott Kitterman 2013-04-10T03:36:34 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25223 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 09 Mar 2013 - 12 Mar 2013 Report Date: 08 Apr 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 12 Total Participants : 8 Total Vendor Postings : 0 Total Mail/No Replies : 3 (25%) 6+ Days Old : 3 4+ Days Old: 0 2+ Days Old : 0 1 Day Old : 0 Busiest Posting Hour : 6am (3 msgs) Busiest Posting Day : Tuesday (6 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * * | | * * | | * * | | * * </pre> spf-discuss< at >winserver.com 2013-04-08T21:31:55 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25222 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 02 Mar 2013 - 02 Mar 2013 Report Date: 09 Mar 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 1 Total Participants : 1 Total Vendor Postings : 0 Total Mail/No Replies : 1 (100%) 6+ Days Old : 1 4+ Days Old: 0 2+ Days Old : 0 1 Day Old : 0 Busiest Posting Hour : 5am (1 msgs) Busiest Posting Day : Saturday (1 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * | | * | | * | | * </pre> spf-discuss< at >winserver.com 2013-03-09T10:55:02 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25221 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 23 Feb 2013 - 23 Feb 2013 Report Date: 02 Mar 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 1 Total Participants : 1 Total Vendor Postings : 0 Total Mail/No Replies : 1 (100%) 6+ Days Old : 1 4+ Days Old: 0 2+ Days Old : 0 1 Day Old : 0 Busiest Posting Hour : 5am (1 msgs) Busiest Posting Day : Saturday (1 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * | | * | | * | | * </pre> spf-discuss< at >winserver.com 2013-03-02T10:55:00 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25220 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 16 Feb 2013 - 16 Feb 2013 Report Date: 23 Feb 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 1 Total Participants : 1 Total Vendor Postings : 0 Total Mail/No Replies : 1 (100%) 6+ Days Old : 1 4+ Days Old: 0 2+ Days Old : 0 1 Day Old : 0 Busiest Posting Hour : 5am (1 msgs) Busiest Posting Day : Saturday (1 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * | | * | | * | | * </pre> spf-discuss< at >winserver.com 2013-02-23T10:55:01 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25219 <pre> iMail News Gateway Server v3.3 (c) Copyright 1996-2012 Santronics Software, Inc. Mail Forum Statistics Date Range : 09 Feb 2013 - 14 Feb 2013 Report Date: 16 Feb 2013 ---------------------------------------------------------------------- Total Summary: ---------------------------------------------------------------------- Total Forums : 2 Total Messages : 32 Total Participants : 10 Total Vendor Postings : 0 Total Mail/No Replies : 2 (6%) 6+ Days Old : 1 4+ Days Old: 0 2+ Days Old : 1 1 Day Old : 0 Busiest Posting Hour : 10am (8 msgs) Busiest Posting Day : Tuesday (16 msgs) +-[ Hourly Posting Pattern ]----------------------+ | * | | * | | * | | * </pre> spf-discuss< at >winserver.com 2013-02-16T10:55:00 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25218 <pre> Well, seeing as there hasn't been any discussion on the list since September, it can't hurt, right? Besides, there was some discussion of pyspf, which I didn't know about. To the OP, here's what I'd do in your shoes: grab a good domain whitelist and generate IPs &amp; netblocks using some SPF tool. If a whitelist is not available to you, just generate your own based on normal traffic, using the top domains list from Alexa as a guide. http://s3.amazonaws.com/alexa-static/top-1m.csv.zip Nicolai </pre> Nicolai 2013-02-13T19:05:06 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25217 <pre>On Feb 12, Constantine A. Murenin transmitted in part: pyspf is CVS at sourceforge: http://pymilter.cvs.sourceforge.net/viewvc/pymilter/pyspf/ When I modernize, it will be to bzr. Sorry :-) I haven't checked in my ipset hack yet. </pre> Stuart D Gathman 2013-02-13T15:33:09 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25216 <pre> Seems great! Also, make sure to not use "exist", either -- don't want it to have undefined effects. % dig +shor txt rambler.ru "v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24 ip4:81.19.92.32/27 -exists:%{ir}.spf.rambler.ru -exists:%{l}.u.spf.rambler.ru ~all" % Do you have it in a git repo I could fork? C. </pre> Constantine A. Murenin 2013-02-13T05:49:17 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25215 <pre> I understand your intentions. My point is that just because an MTA sends mail from one domain that you think is a safe one, doesn't mean it doesn't also send mail for other, less savory, domains. Skipping greylisting on SPF pass for one of your 'good' domains would accomplish what your after without also giving a free pass to other domain that may not be so friendly. Tumgreyspf does something similar to this. Scott K </pre> Scott Kitterman 2013-02-13T04:45:18 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25214 <pre>On Feb 12, Stuart D Gathman transmitted in part: Hmm, using 0.0.0.0 to "never match" is a good hack, but fails with fancy includes - so I'll need to handle those. It needs to keep 4 separate ipsets for Pass, Fail, SoftFail, and Neutral. I'll make a separate method for computing ipsets. </pre> Stuart D Gathman 2013-02-13T04:10:07 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25213 <pre> I now see your misunderstanding. I never said that I wanted to coarse the SPF data into the resolution of netblocks. That just makes so very little sense on so many levels. What I meant is, when Google.com provides this: % dig +short txt gmail.com; dig +short txt _spf.google.com; dig +short txt _netblocks.google.com "v=spf1 redirect=_spf.google.com" "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ?all" "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all" % Etc. And NetBSD provides this: % dig +short txt netbsd.org ; dig +short mx netbsd.org ; dig +short mail.netbsd.org ; dig +short mail.netbsd.org aaaa 10 mail.netbsd.org. 149.20.53.66 2001:4f8:3:7::25 % And so and so trusted site provides etc. Then I want to take all of those exact netblocks, IPv4 and IPv6 specifications from SPF, and MX resolutio</pre> Constantine A. Murenin 2013-02-13T04:02:15 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25212 <pre>On Feb 12, Constantine A. Murenin transmitted in part: I did a quick and dirty for pyspf (just add ips to a set while evaluating): http://spidey2.bmsi.com/pyspf/spf.py $ python spf.py 0.0.0.0 foo&lt; at &gt;google.com google.com (('softfail', 250, 'domain owner discourages use of this host'), '~all') 216.239.32.0/19 64.233.160.0/19 66.249.80.0/20 72.14.192.0/18 209.85.128.0/17 66.102.0.0/20 74.125.0.0/16 64.18.0.0/20 207.126.144.0/20 173.194.0.0/16 216.73.93.70/31 216.73.93.72/31 This needs to ensure that all paths are followed, and combine adjacent blocks (e.g. the last two above). It also needs to handle IP6. </pre> Stuart D Gathman 2013-02-13T03:59:45 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25211 <pre>I may have misunderstood you also. I thought you were broadening narrower IPs to include the entire netblock. http://www.libspf2.org/docs/html/spf__compile_8c.html I'm not sure if that was intended to be used by itself - libspf2 uses it to cache SPF records in a very fast form. Also, I have a similar feature I added recently to pyspf - it isn't checked in to CVS yet, not thoroughly test. I added it because I've often just wanted a list of MTA IPs for debugging mail problems... </pre> Stuart D Gathman 2013-02-13T03:47:48 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25210 <pre>On Feb 12, Scott Kitterman transmitted in part: He is only whitelisting mail from the domains on his list - but by statically compiling the IPs like libspf2 does, except that he is coarsening the resolution of the set to netblocks. I was suggesting that he might not want to do the netblocks thing when starting with SPF records for the "good" domains. </pre> Stuart D Gathman 2013-02-13T02:41:15 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25209 <pre> I think you're putting distinct meanings into the terms "IP set" and "netblock", or ignoring the fact that bigger providers actually publish their IP set as netblocks within SPF. Else, why would someone specify a netblock in their SPF that's not their actual IP set? If they do, then their SPF is broken, and it'll still be broken regardless whether you do the harvesting like I contemplate, or implement SPF on your MTA. Where has it been implemented? Please provide me a link, I'm very interested in applying it to my setup. C. </pre> Constantine A. Murenin 2013-02-13T02:36:33 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25208 <pre> "Constantine A. Murenin" &lt;mureninc&lt; at &gt;gmail.com&gt; wrote: This seems way harder than just whitelisting mail from the domains on your list that pass SPF. You are assuming that all mail from those hosts is as trustworthy as the mail from your list of good domains. I don't think that is a safe assumption. Scott K </pre> Scott Kitterman 2013-02-13T02:11:30 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25207 <pre>You misunderstood. My only suggestion was to calculate the *actual* IP set, not the "netblock" set. SPF is much more fine grained than netblocks. The same colocation facility might have both "good" and "evil" domains. The idea of statically compiling the IP set for your type of application is a good one, and has already been implemented. </pre> Stuart D Gathman 2013-02-13T01:50:01 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25206 <pre> On Feb 12, 2013, at 7:19 PM, Constantine A. Murenin &lt;mureninc&lt; at &gt;gmail.com&gt; wrote: Constantine, I think your approach is novel and interesting. I'd like to see what the actual results are, as nothing beats real life data. FWIW, my understanding is that there is a gap between the stuff that is easy to determine as "legit" and the stuff that is easy to flag as "unwanted" (when one throws the kitchen sink of tools available to make such a determination). The trouble lies in the gap -- for any single piece of email in "the gap", is this piece of email: - legit but routed in a weird way? - a handcrafted phish? - spam/malware from a compromised (but otherwise trusted) source? Given the above, I'm curious to know how much email "in the gap" would be pulled out if you generate a bunch of netblocks from "good" SPF records and use that to manage your grey-listing. I would guess that you'd only be reinforcing stuff that has no problem being passed through as "legit". But if you have data that shows otherwise, </pre> Tim Draegen 2013-02-13T01:20:26 http://permalink.gmane.org/gmane.mail.spam.spf.discuss/25205 <pre>first i would say yes if doing the sort of greylisting you are talking about pre-whitelisting ips from spf records is not a bad way to cut down on initial delays secondly i would say if the ip(s) is not available via an spf record do not assume 'a mx' as 'a' largely NEVER is a legit mta its usually a website, b MX has usually at most 1 ip that sends most others are receive only, and often all are receive only thirdly yes this will save your greylisting work/initial DB build, but also greylisting equally will not reduce the spam much as most modern spambots will also retry later so will also pass greylisting (why they do this and TLS nowdays) fourthly you should still use spf/dkim/spamassasin-at-data/etc on your mta for connections that have come past greylisting because still a lot of spam comes via greylist-passing bots and legit mailservers with compromised users either way this use of SPF is not relevant to this list really? as greylisting done properly is not a concern for legit senders as it just d</pre> alan 2013-02-13T00:57:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.spam.spf.discuss