Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

Contribution: regex rules for "bad" hostname patterns

Contribution: regex rules for "bad" hostname patterns

2013-08-11 by Jim Klimov

Hello all,

   I've ported into milter-greylist regex capabilities some rules from
our milter-regex setup (much time has passed, so I am not sure if
these rules were authored by myself or by someone from that project).
I hope the rules and comments near them are quite self-explanatory.
Use/adopt with due care, and have fun :)

   By the way, is there any option and format string to set and report
in "msg" clauses the "contact" address for this server's postmaster,
so that collateral casualties might ask for them to be whitelisted?
Probably it should be (automatically?) whitelisted as an RCPT rule.
So far this example hardcodes "abuse@...", but a macro would
be a lot neater here ;)


# cat milter-greylist.conf-80-regex-DUL
### This blocks dial-up and other consumer addresses based on remote
### host's domain name which "seems like" a typical dial-up address.
### $Id: $

### Use extended regular expressions instead of basic regular
### expressions.
extendedregex

### Try to ensure bracketed numeric IP addresses are resolved into names
unbracket

### Reject (delay) unresolvable mailservers (hostname is IP in brackets)
### The short delay along with flushaddr allows to quickly recover from
### temporary DNS errors, but keeps really unresolvable sources from
### delivering mail to us. True servers are registered at least somehow!
racl greylist \
     domain /^\[[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\]$/ \
     delay 1m flushaddr \
     msg "(CONNECT) DNS PTR could not be resolved. Please try again 
later or re-post through an SMTP server properly registered in DNS, or 
contact abuse@.... IP:'%i' DOMAIN:'%d' HELO:'%h' FROM:'%f' RCPT:'%r'"


### Reject (delay) relays with malformed HELO or DNS PTR names
### (not FQDN)
racl greylist helo /^[^\.]*$/ delay 60m msg "Malformed HELO ('%h' not a 
fully-qualified domain name: no dot)"

racl greylist domain /^[^\.]*$/ delay 60m msg "Malformed DNS PTR ('%d' 
not a fully-qualified domain name: no dot)"



### Reject (delay) things that look like they might come from a dynamic
### "consumer" or "dial-up" address, if this was not filtered by DULRBL.
### So, we reject anything that has three digit sets deperated by a
### dash, (ie adsl-134-11-333-11.someisp.net). We reject anything that
### has 3+ numeric subdomains, (ie dialup.123.45.67.8.someisp.net).
### And finally reject any address that has a group of 12 digits,
### (ie pool123045067003.someisp.net).

list "dynamicDomainNames" domain { \
     /^.*[0-9][0-9]*\-[0-9][0-9]*\-[0-9][0-9]*.*$/              \
     /^[^\[].*[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*.*[^\]]$/    \
     /^.*[0-9]{12}.*$/e                  \
     /^.*ppp[0-9\.\-].*$/i               \
     /^.*pool[0-9\.\-].*$/i              \
     /^.*dsl[0-9\.\-].*$/i               \
     /^.*dial[0-9\.\-].*$/i              \
     /^.*dial-?up[0-9\.\-].*$/i          \
     /^.*dynamic[0-9\.\-].*$/i           \
     /^.*cable[0-9\.\-].*$/i             \
     /^.*client[0-9\.\-].*$/i            \
     /^.*host[0-9\.\-].*$/i              \
     /^.*dhcp[0-9\.\-].*$/i              \
     /^.*cdma[0-9\.\-].*$/i              \
     /broadband/i                        \
     /static/i                           \
     /^.*in-addr\.arpa.*$/i              \
     /^.*dip0\.t-ipconnect\.de$/i        \
     /^.*virtua\.com\.br$/i              \
     /speedy.com.ar$/i                   \
}
racl greylist list "dynamicDomainNames" delay 120m \
     msg "(CONNECT) Your hostname DNS PTR entry looks like a 
dynamic/consumer address, please re-send through your ISP's registered 
SMTP server, or contact abuse@.... IP:'%i' DOMAIN:'%d' HELO:'%h' 
FROM:'%f' RCPT:'%r'"

### Above we rejected (delayed long enough to get hit by DNS RBL)
### potential spammers by IP-looking names and by dynamic-looking
### names...



Hope this helps,
//Jim Klimov

Re: [milter-greylist] Contribution: regex rules for "bad" hostname patterns

2013-08-11 by Jim Klimov

On 2013-08-11 05:06, Jim Klimov wrote:
> By the way, is there any option and format string to set and report
> in "msg" clauses the "contact" address for this server's postmaster,
> so that collateral casualties might ask for them to be whitelisted?
> Probably it should be (automatically?) whitelisted as an RCPT rule.
> So far this example hardcodes "abuse@...
> <mailto:abuse%40domain.com>", but a macro would
> be a lot neater here ;)


I did not find anything like it, so rolled my own: '%c' format string
to substitute by the email address defined with the new 'contact_email'
keyword. This email is also added to the whitelist.

During my testing I found that Messaging Server post-processed messages
for abuse@, accepting them during SMTP dialog with the sender, and then
milter-greylist refused it during internal dialog between the MTA's
queue handlers which tried to deliver it further to admin@ mailbox.
I haven't seen such behavior with any other target addresses; so YMMV.
Things worked okay when I added this admin@... to rcpt whitelist
as well, so be sure to test your contact address with mails from all
sorts of sources that your deployment should not trust in production.

This worked for me with both a defined email address (any quoted string
actually - something that is not an email address is also happily added
to the rcpt whitelist), and with a missing keyword - at which point %c
substitution in msg texts is empty.

Again, I monkeyed around cloning existing lex code without any deeper
understanding of it, so there may be mistakes... still, this compiled
and worked for me as I expected :)

HTH,
//Jim Klimov

Re: [milter-greylist] Contribution: regex rules for "bad" hostname patterns

2013-08-11 by manu@...

Jim Klimov <jimklimov@...> wrote:

>    By the way, is there any option and format string to set and report
> in "msg" clauses the "contact" address for this server's postmaster,
> so that collateral casualties might ask for them to be whitelisted?

No, but here is an idea: milter-greylist already have the concept of
variables, fetched from LDAP or a random web service (ldapcheck and
urlcheck). They can be used in format strings. The thing is implemented
in prop.c

Perhaps a set clause for acl would be interesting? You could do
something like this (second ACL already work, you need to implmeent the
set clause in the first one):

racl continue set webmaster="webmaster@..."
racl blacklist domain evil.com msg "ask %P{webmaster} why"

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] Contribution: regex rules for "bad" hostname patterns [1 Attachment]

2013-08-14 by manu@...

Jim Klimov <jimklimov@...> wrote:

> I did not find anything like it, so rolled my own: '%c' format string
> to substitute by the email address defined with the new 'contact_email'
> keyword. This email is also added to the whitelist.

I said in another message, I think we can do better, with a mecanism to
set variables.  We can already do this:
racl blacklist domain evil.com msg "ask %P{webmaster} why"

%P{webmaster} comes from ldapcheck or urlcheck clauses. IMO we now need
a set clause in ACL to set variables from ACL themselves, like this:
racl continue set webmaster="webmaster@..."


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] Contribution: regex rules for "bad" hostname patterns [1 Attachment]

2013-08-16 by manu@...

Emmanuel Dreyfus <manu@...> wrote:

> I said in another message, I think we can do better, with a mecanism to
> set variables.  We can already do this:
> racl blacklist domain evil.com msg "ask %P{webmaster} why"
> 
> %P{webmaster} comes from ldapcheck or urlcheck clauses. IMO we now need
> a set clause in ACL to set variables from ACL themselves, like this:
> racl continue set webmaster="webmaster@..."

I started writing code to support that. Stay tuned.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.