Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014, Miles Fidelman wrote: Actually, the OPs notion is an interesting one. From the point of view of someone who administers a lot of systems and mailing lists, I end up getting multiple copies of lots of messages. I've been thinking for a while about how to implement anti-spam rules based on receiving multiple copies of the same message. On 14.11.14 09:32, John Hardin wrote: RAZOR/PYZOR. no, DCC.. RAZOR/PYZOR operate manually (at least they should) and do not count spam, but all non-whitelisted mail -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you.
Re: Missing Modules
Am 14.11.2014 um 20:44 schrieb Axb: I don't use SA's SPF stuff so you caught me here... My repoforge suggestion was mainly for Centos 5.x I'd go for http://dl.fedoraproject.org/pub/epel/6/x86_64/perl-Mail-SPF-2.8.0-2.el6.noarch.rpm It installs without extra dependencies and plays nice with the C6 Core modules Anybody else got a better suggestion? install the epel-release package on CentOS - i would call that repo mandatory and it *never* collides with the base-repos https://fedoraproject.org/wiki/EPEL signature.asc Description: OpenPGP digital signature
Re: Missing Modules
On 11/14/2014 08:18 PM, Niamh Holding wrote: Hello Axb, Thursday, November 13, 2014, 2:21:44 PM, you wrote: If you need need extra modules which are not provided by Centos go to http://pkgs.repoforge.org/ Just looking, so don't shoot me but http://pkgs.repoforge.org/perl-Mail-SPF/ has nothing listed later than CentOS 5 Now I'll be tarred and feathered by the rest :) I don't use SA's SPF stuff so you caught me here... My repoforge suggestion was mainly for Centos 5.x I'd go for http://dl.fedoraproject.org/pub/epel/6/x86_64/perl-Mail-SPF-2.8.0-2.el6.noarch.rpm It installs without extra dependencies and plays nice with the C6 Core modules Anybody else got a better suggestion?
Re: Missing Modules
Hello Axb, Thursday, November 13, 2014, 2:21:44 PM, you wrote: > If you need need extra modules which are not provided by Centos go to > http://pkgs.repoforge.org/ Just looking, so don't shoot me but http://pkgs.repoforge.org/perl-Mail-SPF/ has nothing listed later than CentOS 5 PS I hate hotmail! -- Best regards, Holtainmailto:holt...@hotmail.com
Re: SOUGHT 2.0 ?
On Thu, Nov 13, 2014 at 02:08:30PM +0100, Axb wrote: > >>As Alex has said there's a need for mirrors etc. - that could > >>potentially be the biggest impact on volunteers (assuming they offer > >>to help with that aspect) since they will be a more public facing > >>contribution and it would be great if it didn't spend more time > >>offline than online. > > > >What sort of disk space requirements? I'd be happy to run a mirror, > >London or Hemel Hempsted, UK, so long as you don't need too many gigabytes. > > 5 MB for rsync mirrors is more than enough. > Rule files should not exceed 50KB or they hog SA performance > Mirrors should be well connected (no volume restrictions). If rules > become popular, they'll get thousands of requests/day. I can help here, with ipv4 and v6 connected hosts at mit.edu and/or linode. > >Also could perhaps provide data if the process isn't too difficult to > >set up. I don't have much mail throughput compared to some here, and > >it's mostly UK-English-speaking, but I do have a variety of different > >mail users. > > We need trap domains which relay spam or point MX recs directly to a > couple of specific servers - user reports are not reliable and can > hadly provide enough data to make it worth the effort. Can also help here, both with trap domains and mail processing, as necessary. I wonder if creating a separate mailing list for this project might make sense at this point. Or do folks think we should keep working via the main SA lists? noah signature.asc Description: Digital signature
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 18:24:05 +0100 Matus UHLAR - fantomas wrote: > >I have an experimental botnet detector that looks for multiple > >messages with similar subjects that come from many different > >countries (as determined by geolocating the relay IP.) > isn't this what DCC is about? Similar idea, yes. Differs in implementation details. Regards, David.
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014, listsb-spamassas...@bitrate.net wrote: one characteristic that appears to be pretty consistent is the age of the domain name that a given message references [from header, envelope sender, ptr record for remote mailservers referenced in received headers, etc]. quite often, the domain names are very recently registered. in many instances, the very same day the messages are received. is there a rule/ruleset out there that adds points to a score based on domain name age? the newer the domain, the higher the score is pushed up? There is the URIBL_DOB that checks for such domains in URIs. We've just recently added the ability to check domain BLs for other message parts, and it's likely there will soon be rules for the latest SA to check (e.g.) envelope sender domain against the DOB BL. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The Constitution is a written instrument. As such its meaning does not alter. That which it meant when adopted, it means now. -- U.S. Supreme Court SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) --- 897 days since the first successful private support mission to ISS (SpaceX)
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014, Miles Fidelman wrote: Actually, the OPs notion is an interesting one. From the point of view of someone who administers a lot of systems and mailing lists, I end up getting multiple copies of lots of messages. I've been thinking for a while about how to implement anti-spam rules based on receiving multiple copies of the same message. RAZOR/PYZOR. Queuing messages for a little while, seems like a good start. As this is essentially the same use case as URIBLs (i.e. it's a checksum BL) the same approach makes sense. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The Constitution is a written instrument. As such its meaning does not alter. That which it meant when adopted, it means now. -- U.S. Supreme Court SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) --- 897 days since the first successful private support mission to ISS (SpaceX)
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014, Reindl Harald wrote: if they would have that much ressources postscreen even without RBL's would not be that effective because they don't wait until their turn to speak most of the time and so have no chance for delivery - the 13407 pregreets this month are "hurry up i have no time zombies" Blacklist: 75009 Pregreet: 13407 And pregreeting traffic is a *wonderful* criteria for tarpitting. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The Constitution is a written instrument. As such its meaning does not alter. That which it meant when adopted, it means now. -- U.S. Supreme Court SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) --- 897 days since the first successful private support mission to ISS (SpaceX)
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 07:45:49 -0500 Miles Fidelman wrote: From the point of view of someone who administers a lot of systems and mailing lists, I end up getting multiple copies of lots of messages. I've been thinking for a while about how to implement anti-spam rules based on receiving multiple copies of the same message. On 14.11.14 08:41, David F. Skoll wrote: I have an experimental botnet detector that looks for multiple messages with similar subjects that come from many different countries (as determined by geolocating the relay IP.) So far, it's been fairly effective at alerting me to new botnet spam runs, but unfortunately the signal-to-noise ratio is still a bit rough to use it to create automated rules. isn't this what DCC is about? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe.
.red
untested.. unscored
uri AXB_URI_SHADESOF_RED m{http://[a-z0-9]{5,15}\.red/}
or if you need a bazooka
if (version >= 3.004000)
blacklist_uri_host red
endif
Re: dealing with mail not yet listed in network tests
Am 14.11.2014 um 17:11 schrieb listsb-spamassas...@bitrate.net: one characteristic that appears to be pretty consistent is the age of the domain name that a given message references [from header, envelope sender, ptr record for remote mailservers referenced in received headers, etc]. quite often, the domain names are very recently registered. in many instances, the very same day the messages are received. is there a rule/ruleset out there that adds points to a score based on domain name age? the newer the domain, the higher the score is pushed up? that's URIBL_RHS_DOB http://wiki.apache.org/spamassassin/Rules/URIBL_RHS_DOB sadly it turned out to be not that relieable for a very high score signature.asc Description: OpenPGP digital signature
Re: dealing with mail not yet listed in network tests
> On Nov 14, 2014, at 00.35, John Hardin wrote: > > On Thu, 13 Nov 2014, listsb-spamassas...@bitrate.net wrote: > >> all of the emotional postulative opining aside, one possibility i have been >> considering is having postfix delay relay of messages to the content filter >> for a few minutes, as it seems that when these messages reach us, they're >> only minutes away from being matched by network tests [this is what i asked >> postfix-users about]. i'm interested to hear from folks on this list >> regarding this idea, as well as possible alternatives to dealing with this >> phenomenon. > > It's called greylisting and many people (including myself) have good results > with it. yeah, i'm very familiar with greylisting. it's something i've used in the past, and for a time, it worked reasonably well. for me, that time has passed. i've dealt with all topics that come up when greylisting is discussed; user expectations, political interests, scalability, reliability of remote systems, purist arguments, etc, etc. the the problems it causes outweigh its benefits at this point, from my experience, and so i no longer use it. in any case, delaying the relay of messages is different than delaying the acceptance of messages, the latter has numerous advantages in managing the activity, as it's done within a controlled environment. that said, i do use postscreen, and i do use after 220 tests, and this does help some. ultimately though, mail gets through. one characteristic that appears to be pretty consistent is the age of the domain name that a given message references [from header, envelope sender, ptr record for remote mailservers referenced in received headers, etc]. quite often, the domain names are very recently registered. in many instances, the very same day the messages are received. is there a rule/ruleset out there that adds points to a score based on domain name age? the newer the domain, the higher the score is pushed up? -ben
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 14:58:46 +0100 Reindl Harald wrote: [David] > > I don't agree with that contention. Botnet operators have so many > > resources at their disposal that I doubt they care about or even > > notice any sort of delaying or tarpitting. [Harald] > they don't because they have not much time for a bot until it gets > blacklisted - i see a drop down from 5 to 5000 attempts per day > after postscreen replaced a Barracuda appliance I see millions of attempts per day (we run a rather large mail relay) and it seems to be pretty much constant month after month, despite our use of greylisting. I agree that the combination of greylisting and RBLs has a synergistic effect; greylisting gives RBLs time to catch up. Regards, David. signature.asc Description: PGP signature
Re: dealing with mail not yet listed in network tests
Am 14.11.2014 um 14:43 schrieb David F. Skoll: On Fri, 14 Nov 2014 13:35:34 +0100 Reindl Harald wrote: *but* it makes a ton of troubles for large *legit* sending clusters which often after a 4xx reject handover that mail to a different node and so get again a 4xx With very little loss of effectiveness, you can modify the algorithm so that if an IPv4 address passes greylisting, you avoid greylisting anything in the /24 containing that IP address. That can help legitimate clusters quite a bit while only slightly increasing the risk from botnets. indeed a good idea RBL reject or hand it over to the smtpd daemon - after some months you will see the amount of botnet connections going down at all because it harms them waste 10 seconds for each delivery attempt I don't agree with that contention. Botnet operators have so many resources at their disposal that I doubt they care about or even notice any sort of delaying or tarpitting. they don't because they have not much time for a bot until it gets blacklisted - i see a drop down from 5 to 5000 attempts per day after postscreen replaced a Barracuda appliance if they would have that much ressources postscreen even without RBL's would not be that effective because they don't wait until their turn to speak most of the time and so have no chance for delivery - the 13407 pregreets this month are "hurry up i have no time zombies" Blacklist: 75009 Pregreet: 13407 signature.asc Description: OpenPGP digital signature
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 13:35:34 +0100 Reindl Harald wrote: > *but* it makes a ton of troubles for large *legit* sending clusters > which often after a 4xx reject handover that mail to a different node > and so get again a 4xx With very little loss of effectiveness, you can modify the algorithm so that if an IPv4 address passes greylisting, you avoid greylisting anything in the /24 containing that IP address. That can help legitimate clusters quite a bit while only slightly increasing the risk from botnets. > RBL reject or hand it over to the smtpd daemon - after some months > you will see the amount of botnet connections going down at all > because it harms them waste 10 seconds for each delivery attempt I don't agree with that contention. Botnet operators have so many resources at their disposal that I doubt they care about or even notice any sort of delaying or tarpitting. Regards, David. signature.asc Description: PGP signature
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 07:45:49 -0500 Miles Fidelman wrote: > From the point of view of someone who administers a lot of systems > and mailing lists, I end up getting multiple copies of lots of > messages. I've been thinking for a while about how to implement > anti-spam rules based on receiving multiple copies of the same > message. I have an experimental botnet detector that looks for multiple messages with similar subjects that come from many different countries (as determined by geolocating the relay IP.) So far, it's been fairly effective at alerting me to new botnet spam runs, but unfortunately the signal-to-noise ratio is still a bit rough to use it to create automated rules. You also need to be running a server that receives a significant volume of mail for this sort of thing to be effective. Regards, David.
Re: dealing with mail not yet listed in network tests
Actually, the OPs notion is an interesting one.
From the point of view of someone who administers a lot of systems and
mailing lists, I end up getting multiple copies of lots of messages.
I've been thinking for a while about how to implement anti-spam rules
based on receiving multiple copies of the same message. Queuing
messages for a little while, seems like a good start.
Miles Fidelman
Reindl Harald wrote:
Am 14.11.2014 um 13:04 schrieb David F. Skoll:
On Fri, 14 Nov 2014 08:39:13 +0100
Matthias Leisi wrote:
On Fri, Nov 14, 2014 at 6:35 AM, John Hardin
wrote:
if you're in a business environment you may have an uphill battle
with managing expectations, to wit: email is *not* intended to be
instant messaging - and may run up against the brick wall of
management not being willing to delay emails from prospective new
paying clients *at all*.
You can mitigate this risk somewhat by avoiding greylisting for a
certain set of whitelisted mailservers.
You can also tremendously mitigate the risk by remembering when a
given SMTP client passes the greylisting hurdle and avoiding
greylisting it for the next few weeks. If it passes greylisting once,
there's likely no point in greylisting it in the future. It's a sort
of automatically-built greylist-whitelist
postfix practically supports that out-of-the-box
http://www.postfix.org/POSTSCREEN_README.html#after_220
postscreen_cache_retention_time = 7d
postscreen_bare_newline_ttl = 7d
postscreen_greet_ttl = 7d
postscreen_non_smtp_command_ttl = 7d
postscreen_pipelining_ttl= 7d
postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
___
*but* it makes a ton of troubles for large *legit* sending clusters
which often after a 4xx reject handover that mail to a different node
and so get again a 4xx
hence better use postscreen without the deep-tests and let the client
IP once per week or so wait around 10 seconds after respond with a RBL
reject or hand it over to the smtpd daemon - after some months you
will see the amount of botnet connections going down at all because it
harms them waste 10 seconds for each delivery attempt
then you have "postscreen_whitelist_interfaces" where you reject based
on RBL's or respond with 4xx *unconditional*, so the client comes back
some minutes later on the primary MX (in fact the same machine!)
well, within that minutes it may got blacklisted and 50% of all IP's
connecting to the backup-mx first *never* come back!
postscreen_bare_newline_enable = no
postscreen_pipelining_enable = no
postscreen_non_smtp_command_enable = no
postscreen_cache_retention_time = 7d
postscreen_bare_newline_ttl = 7d
postscreen_greet_ttl = 7d
postscreen_non_smtp_command_ttl = 7d
postscreen_pipelining_ttl= 7d
postscreen_dnsbl_ttl = 5m
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_greet_wait= ${stress?3}${stress:10}s
postscreen_whitelist_interfaces = !, static:all
___
--
In theory, there is no difference between theory and practice.
In practice, there is. Yogi Berra
Re: dealing with mail not yet listed in network tests
Am 14.11.2014 um 13:04 schrieb David F. Skoll:
On Fri, 14 Nov 2014 08:39:13 +0100
Matthias Leisi wrote:
On Fri, Nov 14, 2014 at 6:35 AM, John Hardin
wrote:
if you're in a business environment you may have an uphill battle
with managing expectations, to wit: email is *not* intended to be
instant messaging - and may run up against the brick wall of
management not being willing to delay emails from prospective new
paying clients *at all*.
You can mitigate this risk somewhat by avoiding greylisting for a
certain set of whitelisted mailservers.
You can also tremendously mitigate the risk by remembering when a
given SMTP client passes the greylisting hurdle and avoiding
greylisting it for the next few weeks. If it passes greylisting once,
there's likely no point in greylisting it in the future. It's a sort
of automatically-built greylist-whitelist
postfix practically supports that out-of-the-box
http://www.postfix.org/POSTSCREEN_README.html#after_220
postscreen_cache_retention_time = 7d
postscreen_bare_newline_ttl = 7d
postscreen_greet_ttl = 7d
postscreen_non_smtp_command_ttl = 7d
postscreen_pipelining_ttl= 7d
postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
___
*but* it makes a ton of troubles for large *legit* sending clusters
which often after a 4xx reject handover that mail to a different node
and so get again a 4xx
hence better use postscreen without the deep-tests and let the client IP
once per week or so wait around 10 seconds after respond with a RBL
reject or hand it over to the smtpd daemon - after some months you will
see the amount of botnet connections going down at all because it harms
them waste 10 seconds for each delivery attempt
then you have "postscreen_whitelist_interfaces" where you reject based
on RBL's or respond with 4xx *unconditional*, so the client comes back
some minutes later on the primary MX (in fact the same machine!)
well, within that minutes it may got blacklisted and 50% of all IP's
connecting to the backup-mx first *never* come back!
postscreen_bare_newline_enable = no
postscreen_pipelining_enable = no
postscreen_non_smtp_command_enable = no
postscreen_cache_retention_time = 7d
postscreen_bare_newline_ttl = 7d
postscreen_greet_ttl = 7d
postscreen_non_smtp_command_ttl = 7d
postscreen_pipelining_ttl= 7d
postscreen_dnsbl_ttl = 5m
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_greet_wait= ${stress?3}${stress:10}s
postscreen_whitelist_interfaces = !, static:all
___
signature.asc
Description: OpenPGP digital signature
Re: dealing with mail not yet listed in network tests
On Fri, 14 Nov 2014 08:39:13 +0100 Matthias Leisi wrote: > On Fri, Nov 14, 2014 at 6:35 AM, John Hardin > wrote: > > if you're in a business environment you may have an uphill battle > > with managing expectations, to wit: email is *not* intended to be > > instant messaging - and may run up against the brick wall of > > management not being willing to delay emails from prospective new > > paying clients *at all*. > You can mitigate this risk somewhat by avoiding greylisting for a > certain set of whitelisted mailservers. You can also tremendously mitigate the risk by remembering when a given SMTP client passes the greylisting hurdle and avoiding greylisting it for the next few weeks. If it passes greylisting once, there's likely no point in greylisting it in the future. It's a sort of automatically-built greylist-whitelist. Regards, David.
Re: Missing Modules
On 14/11/2014 11:26, Matus UHLAR - fantomas wrote: On 13.11.14 14:34, Giles Coochey wrote: I avoid the distribution perl completely, and use perlbrew and spamassassin 3.4.0 compiled from source, with a specific perlbrew perl version I avoid breaking the version of perl that comes with the system and can satisfy all dependencies via CPAN. how do you solve cases when any package from distribution needs perl or any of its modules? perlbrew (http://perlbrew.pl/) doesn't replace the system perl, it installs a different perl to a different path. You can run many different perl versions on the same system, but in any environment only one is active. -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7584 634135 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature
Re: Missing Modules
On 13.11.14 14:34, Giles Coochey wrote: I avoid the distribution perl completely, and use perlbrew and spamassassin 3.4.0 compiled from source, with a specific perlbrew perl version I avoid breaking the version of perl that comes with the system and can satisfy all dependencies via CPAN. how do you solve cases when any package from distribution needs perl or any of its modules? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 99 percent of lawyers give the rest a bad name.
