Re: opinions on greylisting and others
On May 26, 2009, at 4:00 AM, Arvid Picciani wrote: does this list have an online archive? Yes. Google it.
Re: opinions on greylisting and others
thanks for your responses. unfortunatly i lost all my local mail when my laptop exploded friday :( does this list have an online archive?
Re: opinions on greylisting and others
On 24-May-2009, at 09:45, John Hardin wrote: On Sun, 24 May 2009, LuKreme wrote: /\.(dsl|\d+dls|dsl\d+)\./ REJECT Dynamic DSL looking address dLs? typo? Yep, thanks for that. -- Anybody who could duck the Vietnam war can certainly duck a couple of shoes. -- Chris Gehlker
Re: opinions on greylisting and others
On Sun, 24 May 2009, LuKreme wrote: /\.(dsl|\d+dls|dsl\d+)\./ REJECT Dynamic DSL looking address dLs? typo? -- 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 --- Efficiency can magnify good, but it magnifies evil just as well. So, we should not be surprised to find that modern electronic communication magnifies stupidity as *efficiently* as it magnifies intelligence. -- Robert A. Matern --- Tomorrow: Memorial Day - honor those who sacrificed for our liberty
Re: opinions on greylisting and others
On 22-May-2009, at 15:30, mouss wrote:
on the other hand, you can block some known values/suffixes/
expressions.
here are a few recent "real" life samples
dynamic.ranchi.bb.59.92.92.92/24.bsnl.in
static.chandigarh.bb.59.94.224.236/24.bsnl.in
161.185.225.124.null.hi.!dynamic.163data.com.cn
18.50.225.124.lg.hi.!dynamic.163data.com.cn
customer-static-.iplannetworks.net
dsl88.230-.2304.ttnet.net.tr
40.subnet125-166-24.astinet.telkom.net.id.24.166.125.in-addr.arpa
BThomehub.home
api.home
I think my rules for helo's catch all of these:
!/[[:alpha:]]/REJECT helo non-alpha helo not
allowed to talk to me
!/\.[[:alpha:]]{2,}$/ REJECT helo no TLD, invalid hostname
# Block localhost (unusual in HELO)
/^localhost(\.localdomain)?$/ REJECT helo Unacceptable hostname in helo
/^unknown$/ REJECT helo No unknown hostnames
/^(mail.)?kreme\.com$/ REJECT helo Don't spoof my hostname
/\.(local|home|example)$/ REJECT Unacceptable LAN name in helo
/(d{1,3}[.-]){3}[.-]\d{1,3}/ WARN Too many numbers in your hostname
/\.(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic .
servers not allowed
/^(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic ^
servers not allowed
--
Lobotomy means never having to say you're sorry -- or anything
else.
Re: opinions on greylisting and others
On 22-May-2009, at 07:29, John Hardin wrote: They will especially get a clue if many sites reject their traffic with a message like "your HELO should be your actual public FQDN, you moron." (worded more politely, of course) That about as polite as is necessary for a misconfigured server. -- These are the thoughts that kept me out of the really good schools. -- George Carlin
Re: opinions on greylisting and others
On 22-May-2009, at 06:14, Arvid Ephraim Picciani wrote:
- greylisting
I do this to great effect, but not for all servers (see below)
- rejecting broken HELO at smtp time (such as "MUMS_XP_BOX")
Yep, I reject a lot of messages based on helos
- rejecting dynamic IPS at smtp time (PBL)
I use zen, but I also have a FQDN check that rejects a lot (and also
greylists):
/\.?(dhcp|dialup|dynamic|ppp|pool)\.?/ REJECT Dynamic addresses
must use a real mailserver
/\.(dsl|\d+dls|dsl\d+)\./ REJECT Dynamic DSL
looking address
/^[^\.]*[0-9][^0-9\.]+[0-9]/ check_greylist
/^[^\.]*[0-9]{5}/check_greylist
/^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z]/ check_greylist
/^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9]/check_greylist
/^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\./check_greylist
(DSL is separate for historical reasons on my server)
- firewalling hosts with 100% spam, forever.
I'm using fail2ban so blacklisting failed connections is transparent.
Only banning for 15m right now as I continue to test.
--
The fact that Bob and John are married does nothing to diminish
anyone else's marriage any more than a black woman marrying a
white man, a Jew marrying a Catholic, or an ugly Lyle marrying
a Pretty Woman
Re: opinions on greylisting and others
John Hardin a écrit : > On Fri, 22 May 2009, mouss wrote: > >> John Hardin a écrit : >>> On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: >>> I was mentioning cases where someone compares HELO to FQDN and rejects connections if they do not match. That was indicated by the message (even with different wording). >>> >>> Ok, agreed. If they don't match don't reject, just give that a point. >> >> Not as stated. let's say >> >> 192.0.2.1 has a PTR of life.example >> life.example has an A of 192.0.2.1 >> easy.example has an A of 192.0.2.1 >> >> if an MTA running on 192.0.2.1 helos as easy.example, then it's as good >> as any other name he could use. The fact that "life" is not "easy" is >> totally irrelevant. (of course, hostnames were chosen to allow for a >> word game, but this too is totally irrelevant :) >> >> you can only add a point if you do more checks, such as helo is in AU >> and sending IP is in UA, ... etc. > > ...sigh. Yeah, that's what I was trying to say, without going to the > effort of saying all of it. I agree. > >>> However, a FQDN in the HELO being unresolvable is a valid reason to >>> reject. >> >> but as I understand the RFCs, it could resolve to anything. an example >> would be an MTA behind a NAT box. (note that I am talking about the RFC >> requirement, not about what anyone can do with the noise he gets...) > > Right. Checking that what it resolves to is reasonable is a more complex > question. Whether or not it resolves at all is a simple question that > can be enforced at SMTP time by the MTA or a milter. > I still get mail with "company.grp" (oh these exchange admins!). I've also seen unresolvable helo in mail from .edu sites (where they seem to like to use an infinity of subdomains, some of which get removed from dns but some MTAs containue to use them...). so I don't try to resolve the helo... on the other hand, you can block some known values/suffixes/expressions. here are a few recent "real" life samples dynamic.ranchi.bb.59.92.92.92/24.bsnl.in static.chandigarh.bb.59.94.224.236/24.bsnl.in 161.185.225.124.null.hi.!dynamic.163data.com.cn 18.50.225.124.lg.hi.!dynamic.163data.com.cn customer-static-.iplannetworks.net dsl88.230-.2304.ttnet.net.tr 40.subnet125-166-24.astinet.telkom.net.id.24.166.125.in-addr.arpa BThomehub.home api.home dsldevice.lan speedtouch.lan (and the award winner:) my.firewall >>> Per RFC2821 3.6 it MUST resolve. >> >> BTW. 2821 and 2822 were updated some time ago. use 5321 and 5322 as >> references now. > > Thanks. > > RFC5321 2.3.5 still requires the domain name in the HELO/EHLO, if used, > to resolve, so that reject is still valid for internet mail. > RFC aside, it is relatively easy to setup a helo that resolves (and even that resolves to the "public" IP unless you are behind NAT and you have multiple routes). but I'll wait until the gorillas enforce this.
Re: opinions on greylisting and others
On Fri, 22 May 2009, mouss wrote: John Hardin a écrit : On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: I was mentioning cases where someone compares HELO to FQDN and rejects connections if they do not match. That was indicated by the message (even with different wording). Ok, agreed. If they don't match don't reject, just give that a point. Not as stated. let's say 192.0.2.1 has a PTR of life.example life.example has an A of 192.0.2.1 easy.example has an A of 192.0.2.1 if an MTA running on 192.0.2.1 helos as easy.example, then it's as good as any other name he could use. The fact that "life" is not "easy" is totally irrelevant. (of course, hostnames were chosen to allow for a word game, but this too is totally irrelevant :) you can only add a point if you do more checks, such as helo is in AU and sending IP is in UA, ... etc. ...sigh. Yeah, that's what I was trying to say, without going to the effort of saying all of it. I agree. However, a FQDN in the HELO being unresolvable is a valid reason to reject. but as I understand the RFCs, it could resolve to anything. an example would be an MTA behind a NAT box. (note that I am talking about the RFC requirement, not about what anyone can do with the noise he gets...) Right. Checking that what it resolves to is reasonable is a more complex question. Whether or not it resolves at all is a simple question that can be enforced at SMTP time by the MTA or a milter. Per RFC2821 3.6 it MUST resolve. BTW. 2821 and 2822 were updated some time ago. use 5321 and 5322 as references now. Thanks. RFC5321 2.3.5 still requires the domain name in the HELO/EHLO, if used, to resolve, so that reject is still valid for internet mail. -- 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 --- Public Education: the bureaucratic process of replacing an empty mind with a closed one. -- Thorax --- 32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
Re: opinions on greylisting and others
John Hardin wrote: On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: I was mentioning cases where someone compares HELO to FQDN and rejects connections if they do not match. That was indicated by the message (even with different wording). Ok, agreed. If they don't match don't reject, just give that a point. However, a FQDN in the HELO being unresolvable is a valid reason to reject. Per RFC2821 3.6 it MUST resolve. and here I'd recommend a temporary 4xx rejection as dns issues *do* occasionally occur :-)
Re: opinions on greylisting and others
John Hardin a écrit : > On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: > >> I was mentioning cases where someone compares HELO to FQDN and rejects >> connections if they do not match. That was indicated by the message (even >> with different wording). > > Ok, agreed. If they don't match don't reject, just give that a point. > Not as stated. let's say 192.0.2.1 has a PTR of life.example life.example has an A of 192.0.2.1 easy.example has an A of 192.0.2.1 if an MTA running on 192.0.2.1 helos as easy.example, then it's as good as any other name he could use. The fact that "life" is not "easy" is totally irrelevant. (of course, hostnames were chosen to allow for a word game, but this too is totally irrelevant :) you can only add a point if you do more checks, such as helo is in AU and sending IP is in UA, ... etc. > However, a FQDN in the HELO being unresolvable is a valid reason to > reject. but as I understand the RFCs, it could resolve to anything. an example would be an MTA behind a NAT box. (note that I am talking about the RFC requirement, not about what anyone can do with the noise he gets...) > Per RFC2821 3.6 it MUST resolve. > BTW. 2821 and 2822 were updated some time ago. use 5321 and 5322 as references now.
Re: opinions on greylisting and others
On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: I was mentioning cases where someone compares HELO to FQDN and rejects connections if they do not match. That was indicated by the message (even with different wording). Ok, agreed. If they don't match don't reject, just give that a point. However, a FQDN in the HELO being unresolvable is a valid reason to reject. Per RFC2821 3.6 it MUST resolve. -- 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 --- Public Education: the bureaucratic process of replacing an empty mind with a closed one. -- Thorax --- 32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
Re: opinions on greylisting and others
> On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: > >> On 22.05.09 06:29, John Hardin wrote: >>> They will especially get a clue if many sites reject their traffic with a >>> message like "your HELO should be your actual public FQDN, you moron." >>> (worded more politely, of course) >> >> yes, it should be, but you also MUST NOT reject if it is not. >> There are always cases when sender does not use it... On 22.05.09 09:01, John Hardin wrote: > I have milter-regex reject connections from the Internet at large if > there's no period at all in the HELO. This covers FQDNs and [x.x.x.x] IP > address literals per RFC2821 3.6, 4.1.1.1 and 4.1.3. Granted my pithy > comment above does not cover all valid cases. > > Can you give me a reasonable example of when this rejection rule would be > inappropriate? I was mentioning cases where someone compares HELO to FQDN and rejects connections if they do not match. That was indicated by the message (even with different wording). My mailserver rejects bogus HELO - without dots, and my own hostnames/IPs and I don't object against thopse reasons... -- 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. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Re: opinions on greylisting and others
On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: On 22.05.09 06:29, John Hardin wrote: They will especially get a clue if many sites reject their traffic with a message like "your HELO should be your actual public FQDN, you moron." (worded more politely, of course) yes, it should be, but you also MUST NOT reject if it is not. There are always cases when sender does not use it... I have milter-regex reject connections from the Internet at large if there's no period at all in the HELO. This covers FQDNs and [x.x.x.x] IP address literals per RFC2821 3.6, 4.1.1.1 and 4.1.3. Granted my pithy comment above does not cover all valid cases. Can you give me a reasonable example of when this rejection rule would be inappropriate? -- 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 --- End users want eye candy and the "ooo's and hhh's" experience when reading mail. To them email isn't a tool, but an entertainment form. -- Steve Lake --- 32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
Re: opinions on greylisting and others
Matus UHLAR - fantomas wrote: On 22.05.09 06:29, John Hardin wrote: They will especially get a clue if many sites reject their traffic with a message like "your HELO should be your actual public FQDN, you moron." (worded more politely, of course) yes, it should be, but you also MUST NOT reject if it is not. There are always cases when sender does not use it... Do you mean not FQDN, or not *their* FQDN (ie, matching the IP)? I believe we are talking about the former, not the latter.
Re: opinions on greylisting and others
> On Fri, 2009-05-22 at 14:14 +0200, Arvid Ephraim Picciani wrote: > > Greetings. > > I'm thinking of implementing: > > - greylisting On 22.05.09 08:06, McDonald, Dan wrote: > very effective. I cut my incoming mail by about 80% when we put up > greylisting. I'm using sqlgrey. You apparently don't have better reasons to reject at SMTP time... some blacklist are _very_ effective. I would use greylisting as last-resort, only on mail backups. > > - rejecting dynamic IPS at smtp time (PBL) this one probably? -- 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. M$ Win's are shit, do not use it !
Re: opinions on greylisting and others
On 22.05.09 06:29, John Hardin wrote: > They will especially get a clue if many sites reject their traffic with a > message like "your HELO should be your actual public FQDN, you moron." > (worded more politely, of course) yes, it should be, but you also MUST NOT reject if it is not. There are always cases when sender does not use it... -- 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. We are but packets in the Internet of life (userfriendly.org)
Re: opinions on greylisting and others
On Fri, 22 May 2009, Aaron Wolfe wrote: On Fri, May 22, 2009 at 9:06 AM, McDonald, Dan wrote: On Fri, 2009-05-22 at 14:14 +0200, Arvid Ephraim Picciani wrote: - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") We had too many false-positives when I did that. In particular, Exchange administrators sem to be completely incapable of setting the HELO name to something sane. Although I would agree with that a couple years ago, in the past several months I have been scoring very high on retarded HELO names with good results. I think the tide is turning, more and more admins finally getting a clue and more sites blocking or scoring highly on misconfiguration. They will especially get a clue if many sites reject their traffic with a message like "your HELO should be your actual public FQDN, you moron." (worded more politely, of course) -- 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 --- Insofar as the police deter by their presence, they are very, very good. Criminals take great pains not to commit a crime in front of them. -- Jeffrey Snyder --- 32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
Re: opinions on greylisting and others
On Fri, 22 May 2009, Arvid Ephraim Picciani wrote: Greetings. I'm thinking of implementing: - greylisting - honeypots - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") - rejecting dynamic IPS at smtp time (PBL) - firewalling hosts with 100% spam, forever. Are there any oposing opinions on those? My suggestions for SMTP-time message tests are embodied in my sample milter-regex file at http://www.impsec.org/~jhardin/antispam/ I recall some people dont like greylisting for some reasons. Some admins have to deal with users who have (to me, unrealistic) expectations that email is a 100% reliable _real-time_ communications mechanism, and are thus reluctant to add any unnecessary delay. If delay is not a problem, or if you are willing to configure your greylist to bypass known correspondents, then there's no issue. Spammers to some degree are also rewriting their bots to work in the face of greylisting, but it still seems (in the absence of actual statistical analysis - the plural of "anecdote" is not "data") to help. I am very happy with it, but I am running only a small domain. Also i'm unsure if should firewall, since the postmaster of that host might all sudden get things under control. But we currently have around 99% spam, so i think i need more drastic actions before our mailbox overloads :( My policy is to automatically TCP tarpit (not just firewall) repeat offenders, but that behavior is based on the MTA log, so the tarpit will open back up after a while on its own - if they aren't making it to the MTA, they don't generate any new log entries. If the abuse continues, they go back into the tarpit for a while. If the admin cleans things up and the abusive behavior stops, they won't get tarpitted again. At present that policy is based on a client in zen continuing to connect even though they always get a 5xx reject, or someone with a reject in /etc/mail/access continuing to connect, so it's not as dynamic as it could be. For example, it would be possible to add some analysis of SA logs to include IP addresses that were generating pure spam for recent traffic. I'm getting lots of it from zombies, so i wonder if its legitime to scan the sender before accepting. For example if it blocks icmp, its very likely a home router. But i have no data on that, and no clue. There are ways to tie p0f (OS fingerprinting) into the mail system, see http://www.google.com/search?q=p0f+smtp I will leave it to others to comment on the effectiveness of that, I have no experience with it. Spamhaus has only about half of the zombies. PBL even lacks half of the german dialup ISPs. i'm thinking i need my own techniques to build such lists. Blocking at the MTA ising a DNSBL is risky, you want to be careful in choosing which DNSBL you use for poison-pill-level access control. The consensus is that zen.spamhaus.org is reliable enough for this (though of course some will disagree). There are other things to look at. For example, is your MTA configured to accept invalid email addresses and quietly discard the message? If so, that may make your domain more attractive to spammers than it would be if you rejected invalid addresses during SMTP. Your saying "honeypot" above makes me wonder if you have catchall turned on and are accepting mail to invalid addresses and feeding that to your spam corpus. That's valid, but it does have a cost, and I wouldn't do that on my main domain. -- 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 --- Insofar as the police deter by their presence, they are very, very good. Criminals take great pains not to commit a crime in front of them. -- Jeffrey Snyder --- 32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
Re: opinions on greylisting and others
On Fri, May 22, 2009 at 9:06 AM, McDonald, Dan wrote: > On Fri, 2009-05-22 at 14:14 +0200, Arvid Ephraim Picciani wrote: >> Greetings. >> I'm thinking of implementing: >> - greylisting > > very effective. I cut my incoming mail by about 80% when we put up > greylisting. I'm using sqlgrey. > >> - honeypots >> - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") > > We had too many false-positives when I did that. In particular, > Exchange administrators sem to be completely incapable of setting the > HELO name to something sane. > Although I would agree with that a couple years ago, in the past several months I have been scoring very high on retarded HELO names with good results. I think the tide is turning, more and more admins finally getting a clue and more sites blocking or scoring highly on misconfiguration. I may start blocking at the MTA, the score I'm giving is essentially a block already. >> - rejecting dynamic IPS at smtp time (PBL) >> - firewalling hosts with 100% spam, forever. > > >> I'm getting lots of it from zombies, so i wonder if its legitime to scan >> the sender before accepting. For example if it blocks icmp, its very >> likely a home router. > > Any sane enterprise server administrator will block external icmp. > I would recommend that you use p0f and a tool like BOTNET.pm to detect > zombies - if they have messed up DNS and are running Windows, then it's > a bot... > >> But i have no data on that, and no clue. >> Spamhaus has only about half of the zombies. PBL even lacks half of the >> german dialup ISPs. i'm thinking i need my own techniques to build such >> lists. >> >> thanks. > -- > Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX > www.austinenergy.com >
Re: opinions on greylisting and others
On Fri, 2009-05-22 at 14:14 +0200, Arvid Ephraim Picciani wrote: > Greetings. > I'm thinking of implementing: > - greylisting very effective. I cut my incoming mail by about 80% when we put up greylisting. I'm using sqlgrey. > - honeypots > - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") We had too many false-positives when I did that. In particular, Exchange administrators sem to be completely incapable of setting the HELO name to something sane. > - rejecting dynamic IPS at smtp time (PBL) > - firewalling hosts with 100% spam, forever. > I'm getting lots of it from zombies, so i wonder if its legitime to scan > the sender before accepting. For example if it blocks icmp, its very > likely a home router. Any sane enterprise server administrator will block external icmp. I would recommend that you use p0f and a tool like BOTNET.pm to detect zombies - if they have messed up DNS and are running Windows, then it's a bot... > But i have no data on that, and no clue. > Spamhaus has only about half of the zombies. PBL even lacks half of the > german dialup ISPs. i'm thinking i need my own techniques to build such > lists. > > thanks. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: opinions on greylisting and others
Arvid Ephraim Picciani wrote: Greetings. I'm thinking of implementing: - greylisting - honeypots - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") - rejecting dynamic IPS at smtp time (PBL) - firewalling hosts with 100% spam, forever. Are there any oposing opinions on those? I recall some people dont like greylisting for some reasons. Also i'm unsure if should firewall, since the postmaster of that host might all sudden get things under control. But we currently have around 99% spam, so i think i need more drastic actions before our mailbox overloads :( I'm getting lots of it from zombies, so i wonder if its legitime to scan the sender before accepting. For example if it blocks icmp, its very likely a home router. But i have no data on that, and no clue. Spamhaus has only about half of the zombies. PBL even lacks half of the german dialup ISPs. i'm thinking i need my own techniques to build such lists. thanks. I have good success rejecting malformed HELOs at smtp (postfix) using: smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit If find this blocks around a third of all smtp connections. Then I use zen.spamhaus.org and greylisting. Combined, HELO tests, spamhaus and greylisting blocks ~96% of spam for me, and certainly gets the easy/obvious spambots. I use postgrey (for postfix) which will autowhitelist compliant servers that do retry so a week or two after installation I noticed no real impact against legitimate mail. Moreover, even a very minimal delay of 60 seconds is good enough to do the job as spambots simply won't retry after the initial temporary rejection. However, be prepared to come across the occasional legitimate sender that may need whitelisting against greylisting as not all do retry. After that, rejecting commonly spammed non-existent recipients (recipient_access) and my own blacklists of IPs/sender domains that continually spam me takes out a considerable chunk more. SA is left with around 1% of the total spam volume to deal with. I monitor my blacklists, and if they've not spammed in 1 month I remove them from the list, checked weekly.
opinions on greylisting and others
Greetings. I'm thinking of implementing: - greylisting - honeypots - rejecting broken HELO at smtp time (such as "MUMS_XP_BOX") - rejecting dynamic IPS at smtp time (PBL) - firewalling hosts with 100% spam, forever. Are there any oposing opinions on those? I recall some people dont like greylisting for some reasons. Also i'm unsure if should firewall, since the postmaster of that host might all sudden get things under control. But we currently have around 99% spam, so i think i need more drastic actions before our mailbox overloads :( I'm getting lots of it from zombies, so i wonder if its legitime to scan the sender before accepting. For example if it blocks icmp, its very likely a home router. But i have no data on that, and no clue. Spamhaus has only about half of the zombies. PBL even lacks half of the german dialup ISPs. i'm thinking i need my own techniques to build such lists. thanks.
