bogus Received

[Geoff Gibbs]

Apart from spammers giving my hostname in the helo, I am
now seeing my username in the helo field (I think). The
evidence is :-

Received: from ggibbs (unknown [61.191.91.252])
by mercury.hgmp.mrc.ac.uk (Postfix) with SMTP id DB48C7D130
for <***@hgmp.mrc.ac.uk>; Mon, 14 Jun 2004 15:26:32 +0100 (BST)

Is there an easy regexp to match two fields on a line for
a header check or might this be easier in a perl policy daemon?

Geoff Gibbs

MRC Rosalind Franklin Centre for Genomics Research
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SB, UK
Tel: [phone] Fax: [phone]
E-mail: ***@rfcgr.mrc.ac.uk Web: http://www.rfcgr.mrc.ac.uk

[Erwan David]

Le Tue 15/06/2004, Geoff Gibbs disait

Post by Geoff Gibbs
Apart from spammers giving my hostname in the helo, I am
now seeing my username in the helo field (I think). The
evidence is :-
Received: from ggibbs (unknown [61.191.91.252])
by mercury.hgmp.mrc.ac.uk (Postfix) with SMTP id DB48C7D130
Is there an easy regexp to match two fields on a line for
a header check or might this be easier in a perl policy daemon?

If it is the helo presented to your server you can use
check_helo_access in smtpd_*_restriction.

I already filter out mail with my domain or my IP as HELO name.

[Michael Tokarev]

Post by Geoff Gibbs
Apart from spammers giving my hostname in the helo, I am
now seeing my username in the helo field (I think). The
evidence is :-
Received: from ggibbs (unknown [61.191.91.252])
by mercury.hgmp.mrc.ac.uk (Postfix) with SMTP id DB48C7D130
Is there an easy regexp to match two fields on a line for
a header check or might this be easier in a perl policy daemon?

May be it is simpler to use reject_non_fqdn_hostname,
before even accepting the message? Like this:

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_non_fqdn_hostname,
...

/mjt

[Geoff Gibbs]

Post by Erwan David
Le Tue 15/06/2004, Geoff Gibbs disait

Post by Geoff Gibbs
Apart from spammers giving my hostname in the helo, I am
now seeing my username in the helo field (I think).

If it is the helo presented to your server you can use
check_helo_access in smtpd_*_restriction.
I already filter out mail with my domain or my IP as HELO name.

Yes I am already doing that, but we only have a limited number
of domains to handle. I am not sure that I want to put
7,000 usernames in a check like this, hence the thought of
checking whether the helo name was the same as the presented
username (regardless of whether the username was genuine).

Geoff Gibbs

MRC Rosalind Franklin Centre for Genomics Research
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SB, UK
Tel: [phone] Fax: [phone]
E-mail: ***@rfcgr.mrc.ac.uk Web: http://www.rfcgr.mrc.ac.uk

[Geoff Gibbs]

Post by Michael Tokarev
May be it is simpler to use reject_non_fqdn_hostname,
before even accepting the message?

I had tried that some time ago, but the false positive rate
was too high. Maybe I should see whether I still consider
the FP rate to be a problem compared to the tidal wave of
spam. I am currently rejecting about 75% of all messages.

Geoff Gibbs

MRC Rosalind Franklin Centre for Genomics Research
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SB, UK
Tel: [phone] Fax: [phone]
E-mail: ***@rfcgr.mrc.ac.uk Web: http://www.rfcgr.mrc.ac.uk

[Michael Tokarev]

Post by Geoff Gibbs

Post by Michael Tokarev
May be it is simpler to use reject_non_fqdn_hostname,
before even accepting the message?

I had tried that some time ago, but the false positive rate
was too high. Maybe I should see whether I still consider
the FP rate to be a problem compared to the tidal wave of
spam. I am currently rejecting about 75% of all messages.

reject_non_fqdn_hostname produces too many FPs? Why? This
is a big surprize for me. Maybe you're thinking about some
other restriction, like e.g. reject_unknown_client or
reject_unknown_hostname? If reject_non_fqdn_hostname
produces too many FPs, I don't understand how your
userbase looks like... maybe it's from different
universe? Or maybe I'm from different one? ;)

/mjt

[Trevor Paquette]

We've had days where we reject over 90% of all incoming email.

Things I check for in the HELO greeting to reject:
localhost
127.0.0.1
my IP
my hostname
my 'domain'
+ all the domains that we host.

This drops ALOT of connections.

-----Original Message-----
From: owner-postfix-***@postfix.org
[mailto:owner-postfix-***@postfix.org]On Behalf Of Geoff Gibbs
Sent: Tuesday, June 15, 2004 3:41 AM
To: postfix-***@postfix.org
Subject: Re: bogus Received

Post by Michael Tokarev
May be it is simpler to use reject_non_fqdn_hostname,
before even accepting the message?=20

I had tried that some time ago, but the false positive rate
was too high. Maybe I should see whether I still consider
the FP rate to be a problem compared to the tidal wave of
spam. I am currently rejecting about 75% of all messages.

Geoff Gibbs

MRC Rosalind Franklin Centre for Genomics Research
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SB, UK
Tel: [phone] Fax: [phone]
E-mail: ***@rfcgr.mrc.ac.uk Web: http://www.rfcgr.mrc.ac.uk

[Roger B.A. Klorese]

Post by Michael Tokarev
reject_non_fqdn_hostname produces too many FPs? Why? This
is a big surprize for me.

You probably don't have many Windows clients with no domain
configured... or Exchange servers as clients. Both of those require
specific effort to HELO with an FQDN, and many don't take that effort
till it's needed.

[Michael Tokarev]

Post by Roger B.A. Klorese

Post by Michael Tokarev
reject_non_fqdn_hostname produces too many FPs? Why? This
is a big surprize for me.

You probably don't have many Windows clients with no domain
configured... or Exchange servers as clients. Both of those require
specific effort to HELO with an FQDN, and many don't take that effort
till it's needed.

I do have these, and I know full well how badly they behave.
But I recall my original message in this thread:

smtpd_recipient_restrictions =
...
permit_mynetworks, <==== note this one
...
reject_non_fqdn_hostname,
....

permit_mynetworks may be accomplished with
permit_sasl_authenticated or whatever.
That to say, for "clients", for which this postfix
serves as a smarthost, there's no need to enforce
this very restriction.

/mjt

[John Peach]

On Tue, 15 Jun 2004 08:06:51 -0700

Post by Roger B.A. Klorese

Post by Michael Tokarev
reject_non_fqdn_hostname produces too many FPs? Why? This
is a big surprize for me.

You probably don't have many Windows clients with no domain
configured... or Exchange servers as clients. Both of those require
specific effort to HELO with an FQDN, and many don't take that effort
till it's needed.

In that case put the check after mynetworks.....

[Roger B.A. Klorese]

Post by Michael Tokarev
I do have these, and I know full well how badly they behave.
smtpd_recipient_restrictions =
...
permit_mynetworks, <==== note this one
...
reject_non_fqdn_hostname,
....
permit_mynetworks may be accomplished with
permit_sasl_authenticated or whatever.
That to say, for "clients", for which this postfix
serves as a smarthost, there's no need to enforce
this very restriction.

Yes, but from a *prococol* perspective, not a business-relationship
perspective, a "client" is anything that connects to you.

In our case, it is considered unacceptable for us to force anyone to
connect from their ISP's or business's smarthost, ince we have a pretty
strong no-blocked-real-mail-is-acceptable policy. And we also encounter
many cases where the "smarthost" delivering to us is itself a
misconfigured Windows mail server.

[John Groseclose]

Post by John Peach
On Tue, 15 Jun 2004 08:06:51 -0700

Post by Roger B.A. Klorese
You probably don't have many Windows clients with no domain
configured... or Exchange servers as clients. Both of those require
specific effort to HELO with an FQDN, and many don't take that effort
till it's needed.

In that case put the check after mynetworks.....

Or put the check after any other check that verifies the sender (SASL,
pop-before-smtp, etc).

If they're one of my users, they can AUTH and send anyway, no matter what=
their
HELO says. If they're not one of my users, they shouldn't be sending
direct-to-mx to my domain anyway - they should be sending through their I=
SPs
mailserver, which should HELO with a good string.

--
spam delenda est