Yahoo Groups archive

Milter-greylist

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

Message

Re: [milter-greylist] P0f support

2008-08-31 by Oliver Fromme

Patrick Domack wrote:
 > Oliver Fromme wrote:
 > > manu@... wrote:
 > > > Patrick Domack <patrickdk@...> wrote:
 > > > 
 > > > > well, since we now have support for everything else (dnsbl, spf,
 > > > > dkim), why not add p0f support (os fingerprinting) to selectively
 > > > > greylist against.
 > > > 
 > > > Heavily greylisting windows XP boxen could be a major benefit.
 > > 
 > > The important question is:  How reliable is it?  How likely
 > > is it to get false positives?  It should be pointed out
 > > that tools like nmap (and similar) just take a good guess,
 > > but are often wrong.  For example, it doesn't detect one of
 > > my backup MX machines correctly.
 > > 
 > > Also note that some server admins intentionally change the
 > > parameters of their TCP/IP stack so fingerprinting does not
 > > guess their OS correctly (just like many admins change the
 > > welcome message of their MTA so it confuses potential
 > > attackers).
 > > 
 > > I don't want to put a huge greylist delay on machines based
 > > on their OS if the OS detection isn't 100% reliable.
 > > 
 > > And I *certainly* don't want my own MTAs greylisted for a
 > > long time just because some other braindead server is unable
 > > to detect my OS correctly.  :-(
 > > 
 > > That's why I feel a little uneasy adding such a "feature"
 > > to milter-greylist.
 > 
 > Well isn't that like anything. Nothing is ever going be reliable, [...]

Right.  Sadly.

There was a time (before spam existed, and before anybody
would even consider running MTAs on Windows) when e-mail
delivery in the internet was reliable.  Sadly this isn't
the case anymore today.

Talking about filter features:  Some features are more
reliable than others, and some features are easier to
abuse or misuse than others (or to use in an inappropriate
or wrong way).

If an OS fingerprinting feature will be implemented in
milter-greylist, it should at least be accompanied by
a fat warning, and it should not be included in the
sample configuration file by default.

Of course, nothing helps against clueless mail server
admins.  I'm already pretty much fed up with such people,
having dealt with a lot of them [*].  Of course this is
not to blame on milter-greylist.  But the more features
milter-greylist grows that are too easily misconfigured,
the more often it *will* be misconfigured, and the result
is that internet email becomes more and more unreliable.

Best regards
   Oliver

PS: [*] The most recent example was someone who greylisted
for 1 minute and expired tuples after one hour.  Since
one of my mailservers resends every two hours (which is
perfectly RFC-compliant), it was unable to send anything
to him.  When I temporarily ran the queue in order to
reach his postmaster@ address to inform him about the
problem, it bounced with a "user unknown" error.
No need to say more.

Sorry for grumbling.  I would just like to make email
more reliable, not more unreliable ...

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

$ dd if=/dev/urandom of=test.pl count=1
$ file test.pl
test.pl: perl script text executable

Attachments

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.