Filtering spam received from multiple users
Jose Hales-Garcia
Hello,
I've recently been getting spam that has the first received header filled in with multiple users. This is an example.
Received: from 79.14.233.16 (account <user1@domain>,
<user2@domain>,
<user3@domain>,
<user4@domain>,
<user5@domain>,
<user6@domain>,
<user7@domain>,
<user8@domain>,
<user9@domain>,
<user10@domain>,
<user11@domain>,
<user12@domain>,
<user13@domain>,
<user14@domain>,
<user15@domain>,
<user16@domain>,
<user17@domain>,
<user18@domain>,
<user19@domain>,
<user20@domain> HELO domain)
by domain (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 107437582 for <user1@domain>; Mon, 11 Apr 2011 10:19:10 +0100
My first idea for handling these messages is writing a filter in header_checks using regexp. Is this the best approach to take using Postfix 2.4.3?
Below are my main.cf settings that I think are relevant.
Jose
header_checks = regexp:/etc/postfix/header_checks
strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_sender_restrictions =
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access,
permit
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_client_access hash:/etc/postfix/client_access,
check_sender_access hash:/etc/postfix/sender_access,
check_recipient_access hash:/etc/postfix/recipient_access,
reject_rbl_client zen.spamhaus.org,
permit
/etc/postfix/helo_access
domain REJECT fraudulent identity
mailserver.domain REJECT fraudulent identity
mailserver.ip_addr REJECT fraudulent identity
Stan Hoeppner
>
> Hello,
>
> I've recently been getting spam that has the first received header filled in with multiple users. This is an example.
>
> Received: from 79.14.233.16 (account <user1@domain>,
> <user2@domain>,
> <user20@domain> HELO domain)
> by domain (CommuniGate Pro SMTP 5.2.3)
> with ESMTPA id 107437582 for <user1@domain>; Mon, 11 Apr 2011 10:19:10 +0100
>
> My first idea for handling these messages is writing a filter in header_checks using regexp. Is this the best approach to take using Postfix 2.4.3?
Probably not. Provide the full header and we may be able to give you
better options.
If this is bot spam or snowshoe spam, there are much better ways to deal
with it, but we need to see the source IP. If it's phish from a
compromised gorilla, webmail, or other account, it's more difficult, and
header_checks may be appropriate. With what you've posted thus far,
it's impossible to give a definitive answer.
--
Stan
Jose Hales-Garcia
On Apr 11, 2011, at 3:44 PM, Stan Hoeppner wrote:
>> My first idea for handling these messages is writing a filter in header_checks using regexp. Is this the best approach to take using Postfix 2.4.3?
>
> Probably not. Provide the full header and we may be able to give you
> better options.
I've put it below (from the latest one to arrive).
Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
Return-Path: <1004045u...@bridgestone.co.jp>
Received: from murder ([unix socket])
by mda.domain (Cyrus v2.2.12-OS X 10.4.8) with LMTPA;
Mon, 11 Apr 2011 12:18:46 -0700
X-Sieve: CMU Sieve 2.2
Received: from smtp.domain (mta.domain [mta.ip_addr])
by mda.domain (Postfix) with ESMTP id B30E42BE1FD4;
Mon, 11 Apr 2011 12:18:46 -0700 (PDT)
Received: by smtp.domain (Postfix)
id 317173CDC36A; Mon, 11 Apr 2011 12:29:30 -0700 (PDT)
Delivered-To: user9@domain
Received: from localhost (localhost [127.0.0.1])
by smtp.domain (Postfix) with ESMTP id 16C4A3CDC360;
Mon, 11 Apr 2011 12:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at domain
X-Spam-Flag: NO
X-Spam-Score: 2.526
X-Spam-Level: **
X-Spam-Status: No, score=2.526 tagged_above=-1000 required=6.31
tests=[BAYES_00=-2.599, SORTED_RECIPS=1.125, UNPARSEABLE_RELAY=4]
Received: from smtp.domain ([127.0.0.1])
by localhost (mta.domain [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vLLDg48PM5PE; Mon, 11 Apr 2011 12:29:29 -0700 (PDT)
Received: from [190.221.28.39] (unknown [190.221.28.39])
by smtp.domain (Postfix) with ESMTP id 46B763CDC359;
Mon, 11 Apr 2011 12:29:29 -0700 (PDT)
Received: from 190.221.28.39 (account <user1@domain>,
<user2@domain>,
<user3@domain>,
<user4@domain>,
<user5@domain>,
<user6@domain>,
<user7@domain>,
<user8@domain>,
<user9@domain>,
<user10@domain>,
<user11@domain>,
<user12@domain>,
<user13@domain>,
<user14@domain>,
<user15@domain>,
<user16@domain>,
<user17@domain>,
<user18@domain>,
<user19@domain>,
<user20@domain> HELO domain)
by domain (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 620648953 for <user1@domain>; Mon, 11 Apr 2011 16:29:28 -0300
From: <user1@domain>, <user2@domain>,
<user3.anderson@domain>, <user4@domain>,
<user5@domain>, <user6@domain>, <user7@domain>,
<user8@domain>, <user9@domain>,
<user10@domain>, <user11@domain>, <user12@domain>,
<user13@domain>, <user14@domain>,
<user15@domain>, <user16@domain>,
<user17@domain>, <user18@domain>,
<user19@domain>, <user20@domain>
To: <user1@domain>, <user2@domain>,
<user3.anderson@domain>, <user4@domain>,
<user5@domain>, <user6@domain>, <user7@domain>,
<user8@domain>, <user9@domain>,
<user10@domain>, <user11@domain>, <user12@domain>,
<user13@domain>, <user14@domain>,
<user15@domain>, <user16@domain>,
<user17@domain>, <user18@domain>,
<user19@domain>, <user20@domain>
Subject: Newsletter Mon, 11 Apr 2011 16:29:28 -0300
Date: Mon, 11 Apr 2011 16:29:28 -0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: hljkn_86
Message-ID: <7186695846.1...@pswasejg.gfjeafxwjq.net>
Stan Hoeppner
>
> On Apr 11, 2011, at 3:44 PM, Stan Hoeppner wrote:
>
>>> My first idea for handling these messages is writing a filter in header_checks using regexp. Is this the best approach to take using Postfix 2.4.3?
>>
>> Probably not. Provide the full header and we may be able to give you
>> better options.
>
> I've put it below (from the latest one to arrive).
> Received: from [190.221.28.39] (unknown [190.221.28.39])
In this example, reject_unknown_reverse_client_hostname would have
generated a 450 rejection. You should always use
reject_unknown_reverse_client_hostname at minimum, or the more
restrictive reject_unknown_client_hostname, though this one can cause
problems with FPs on occasion. Best to use it with warn_if_reject for a
while and monitor what it would have rejected.
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
However, it appears that 190.221.28.39 has rDNS of
Name: host39.190-221-28.telmex.net.ar
Address: 190.221.28.39
so reject_unknown_reverse_client_hostname isn't a permanent solution
here. The host is HELO'ing with an IP address, something legitimate
hosts don't normally do. A check_helo_access pcre table with an
expression that rejects dotted quads (and other undesirable HELO
strings) would work well here.
Rejecting hosts with generic rDNS, or scoring generic rDNS aggressively
in SA, is also a good way to stop spam from such hosts. fqrdns.pcre
would have rejected this mail outright:
$ postmap -q host39.190-221-28.telmex.net.ar pcre:fqrdns.pcre
REJECT Generic - Please relay via ISP (telmex.net.ar)
See: http://www.hardwarefreak.com/fqrdns.pcre
This pcre table stops a lot of spam. Many OPs here use it with good
success. Instructions are comments at the top of the file. Very low FP
rate. If most of the spam that's causing you a problem is from sources
similar to this host, you'll be pleasantly surprised how much of it
fqrdns.pcre rejects.
--
Stan
Mikael Bak
[snip]
>
>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>
> In this example, reject_unknown_reverse_client_hostname would have
> generated a 450 rejection. You should always use
> reject_unknown_reverse_client_hostname at minimum, or the more
> restrictive reject_unknown_client_hostname, though this one can cause
> problems with FPs on occasion. Best to use it with warn_if_reject for a
> while and monitor what it would have rejected.
>
> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>
> However, it appears that 190.221.28.39 has rDNS of
>
> Name: host39.190-221-28.telmex.net.ar
> Address: 190.221.28.39
>
No. The "reject_unknown_reverse_client_hostname" in the above example
would not have generated a 450 rejection, since the IP address HAS a
reverse dns hostname.
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
The "reject_unknown_client_hostname" generates lots of FP. I would not
recommend using it.
> so reject_unknown_reverse_client_hostname isn't a permanent solution
> here. The host is HELO'ing with an IP address, something legitimate
> hosts don't normally do. A check_helo_access pcre table with an
> expression that rejects dotted quads (and other undesirable HELO
> strings) would work well here.
>
> Rejecting hosts with generic rDNS, or scoring generic rDNS aggressively
> in SA, is also a good way to stop spam from such hosts. fqrdns.pcre
> would have rejected this mail outright:
>
> $ postmap -q host39.190-221-28.telmex.net.ar pcre:fqrdns.pcre
> REJECT Generic - Please relay via ISP (telmex.net.ar)
>
> See: http://www.hardwarefreak.com/fqrdns.pcre
>
> This pcre table stops a lot of spam. Many OPs here use it with good
> success. Instructions are comments at the top of the file. Very low FP
> rate. If most of the spam that's causing you a problem is from sources
> similar to this host, you'll be pleasantly surprised how much of it
> fqrdns.pcre rejects.
>
May I suggest that we don't reuse well defined abbrevations. OP is
"original poster", nothing else. To use it for sysop or mailadmin in a
mailing list is confusing.
Cheers,
Mikael
Stan Hoeppner
> Stan Hoeppner wrote:
> [snip]
>>
>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>>
>> In this example, reject_unknown_reverse_client_hostname would have
>> generated a 450 rejection. You should always use
>> reject_unknown_reverse_client_hostname at minimum, or the more
>> restrictive reject_unknown_client_hostname, though this one can cause
>> problems with FPs on occasion. Best to use it with warn_if_reject for a
>> while and monitor what it would have rejected.
>>
>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>
>> However, it appears that 190.221.28.39 has rDNS of
>>
>> Name: host39.190-221-28.telmex.net.ar
>> Address: 190.221.28.39
> No. The "reject_unknown_reverse_client_hostname" in the above example
> would not have generated a 450 rejection, since the IP address HAS a
> reverse dns hostname.
Yes, it would have. Note the "unknown" in the Received line. The rDNS
lookup failed during the transaction in question, thus this restriction
would have generated a 450 for this transaction. Note the following
that I wrote, due to the fact the host does have rDNS:
>> so reject_unknown_reverse_client_hostname isn't a permanent solution
>> here.
I think you were a bit hasty in your reply, not carefully reading the
information I provided.
--
Stan
Noel Jones
> Mikael Bak put forth on 4/12/2011 7:31 AM:
>> Stan Hoeppner wrote:
>> [snip]
>>>
>>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>>>
>>> In this example, reject_unknown_reverse_client_hostname would have
>>> generated a 450 rejection. You should always use
>>> reject_unknown_reverse_client_hostname at minimum, or the more
>>> restrictive reject_unknown_client_hostname, though this one can cause
>>> problems with FPs on occasion. Best to use it with warn_if_reject for a
>>> while and monitor what it would have rejected.
>>>
>>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>>
>>> However, it appears that 190.221.28.39 has rDNS of
>>>
>>> Name: host39.190-221-28.telmex.net.ar
>>> Address: 190.221.28.39
>
>> No. The "reject_unknown_reverse_client_hostname" in the above example
>> would not have generated a 450 rejection, since the IP address HAS a
>> reverse dns hostname.
>
> Yes, it would have. Note the "unknown" in the Received line. The rDNS
The "unknown" gives zero information about the client's rDNS.
The "unknown" signifies that the client does not have
correct FCrDNS, which does not disclose rDNS status.
A client is marked unknown when 1) the client IP address->name
mapping fails, 2) the name->address mapping fails, or 3) the
name->address mapping does not match the client IP address.
The postfix log will show the reason why the client is marked
unknown, but postfix does not indicate the reason in the
Received: header.
-- Noel Jones
Stan Hoeppner
> On 4/12/2011 4:19 PM, Stan Hoeppner wrote:
>> Mikael Bak put forth on 4/12/2011 7:31 AM:
>>> Stan Hoeppner wrote:
>>> [snip]
>>>>
>>>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>>>>
>>>> In this example, reject_unknown_reverse_client_hostname would have
>>>> generated a 450 rejection. You should always use
>>>> reject_unknown_reverse_client_hostname at minimum, or the more
>>>> restrictive reject_unknown_client_hostname, though this one can cause
>>>> problems with FPs on occasion. Best to use it with warn_if_reject
>>>> for a
>>>> while and monitor what it would have rejected.
>>>>
>>>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>>>
>>>> However, it appears that 190.221.28.39 has rDNS of
>>>>
>>>> Name: host39.190-221-28.telmex.net.ar
>>>> Address: 190.221.28.39
>>
>>> No. The "reject_unknown_reverse_client_hostname" in the above example
>>> would not have generated a 450 rejection, since the IP address HAS a
>>> reverse dns hostname.
>>
>> Yes, it would have. Note the "unknown" in the Received line. The rDNS
> The "unknown" gives zero information about the client's rDNS. The
I didn't say it did. It does tell us there was a related error, and we
know the IP has valid rDNS.
> "unknown" signifies that the client does not have correct FCrDNS, which
> does not disclose rDNS status.
Combining "unknown" with the fact that "host" returns a valid rDNS name
tells us the likely cause of "unknown" in this case was a temporary DNS
lookup failure.
> A client is marked unknown when 1) the client IP address->name mapping
> fails, 2) the name->address mapping fails, or 3) the name->address
> mapping does not match the client IP address.
Since we know valid rDNS exists via manual sleuthing, it's pretty
reasonable to conclude 1) above occurred, is it not?
> The postfix log will show the reason why the client is marked unknown,
> but postfix does not indicate the reason in the Received: header.
Always good practice to check logs. Though in this case enough
information was available in lieu of logs to correctly describe the
issue, and put it in the context of the larger question, which was "best
methods to block spam from this type of host".
Do you disagree?
>> lookup failed during the transaction in question, thus this restriction
>> would have generated a 450 for this transaction. Note the following
>> that I wrote, due to the fact the host does have rDNS:
>>
>>>> so reject_unknown_reverse_client_hostname isn't a permanent solution
>>>> here.
>>
>> I think you were a bit hasty in your reply, not carefully reading the
>> information I provided.
--
Stan
Sahil Tandon
> Mikael Bak put forth on 4/12/2011 7:31 AM:
> > Stan Hoeppner wrote:
> > [snip]
> >>
> >>> Received: from [190.221.28.39] (unknown [190.221.28.39])
> >>
> >> In this example, reject_unknown_reverse_client_hostname would have
> >> generated a 450 rejection. You should always use
> >> reject_unknown_reverse_client_hostname at minimum, or the more
> >> restrictive reject_unknown_client_hostname, though this one can cause
> >> problems with FPs on occasion. Best to use it with warn_if_reject for a
> >> while and monitor what it would have rejected.
> >>
> >> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
> >>
> >> However, it appears that 190.221.28.39 has rDNS of
> >>
> >> Name: host39.190-221-28.telmex.net.ar
> >> Address: 190.221.28.39
>
> > No. The "reject_unknown_reverse_client_hostname" in the above example
> > would not have generated a 450 rejection, since the IP address HAS a
> > reverse dns hostname.
>
> Yes, it would have.
Not in this case.
> Note the "unknown" in the Received line. The rDNS lookup failed
> during the transaction in question, thus this restriction would have
> generated a 450 for this transaction. Note the following that I
> wrote, due to the fact the host does have rDNS:
The 'unknown' in the Received: header is not due to rDNS problems, but
more likely because the name->address mapping (still) fails.
% dig +short -x 190.221.28.39
host39.190-221-28.telmex.net.ar.
... so rDNS is OK; however:
% host host39.190-221-28.telmex.net.ar
Host host39.190-221-28.telmex.net.ar not found: 3(NXDOMAIN)
> I think you were a bit hasty in your reply, not carefully reading the
> information I provided.
:-)
--
Sahil Tandon <sa...@FreeBSD.org>
Stan Hoeppner
But the test condition is 1) or 2) or 3) isn't it? Not 1) and 2) and 3)?
If the latter, you seem to be saying one can have a case with an
"unknown" stamp for the reverse-name in the log and Received: header,
but reject_*unknown*_reverse_client_hostname will not reject the connection?
Wietse Venema put forth on 3/31/2011 11:42 AM:
> The format is:
>
> Received: from helo-hostname (verified-reverse-name [ip-address])
If what you seem to be saying is correct, and I'm thus apparently wrong
here in this pedantic sub-thread, then I'm not in this boat alone. If
Postfix stamps a client's reverse-name as "unknown", but at the same
time doesn't reject based on this "unknown reverse-name" with
reject_*unknown*_reverse_client_hostname then, well, there's apparently
a problem with the concept of the "unknown" reverse-name and what that
actually means.
--
Stan
Mikael Bak
> Mikael Bak put forth on 4/12/2011 7:31 AM:
>> Stan Hoeppner wrote:
>> [snip]
>>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>>> In this example, reject_unknown_reverse_client_hostname would have
>>> generated a 450 rejection. You should always use
>>> reject_unknown_reverse_client_hostname at minimum, or the more
>>> restrictive reject_unknown_client_hostname, though this one can cause
>>> problems with FPs on occasion. Best to use it with warn_if_reject for a
>>> while and monitor what it would have rejected.
>>>
>>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>>
>>> However, it appears that 190.221.28.39 has rDNS of
>>>
>>> Name: host39.190-221-28.telmex.net.ar
>>> Address: 190.221.28.39
>
>> No. The "reject_unknown_reverse_client_hostname" in the above example
>> would not have generated a 450 rejection, since the IP address HAS a
>> reverse dns hostname.
>
> lookup failed during the transaction in question, thus this restriction
> would have generated a 450 for this transaction. Note the following
> that I wrote, due to the fact the host does have rDNS:
>
>>> here.
>
> information I provided.
>
I think not.
As others already have proven, you made a hasty judgement upon faulty
information.
My only motivation getting into this discussion was to prevent faulty
information to make it to the list archives without correction.
Mikael
Sahil Tandon
> Sahil Tandon put forth on 4/12/2011 10:58 PM:
> > On Tue, 2011-04-12 at 16:19:03 -0500, Stan Hoeppner wrote:
> >
> >> Mikael Bak put forth on 4/12/2011 7:31 AM:
> >>> Stan Hoeppner wrote:
> >>> [snip]
> >>>>
> >>>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
> >>>>
> >>>> In this example, reject_unknown_reverse_client_hostname would have
> >>>> generated a 450 rejection. You should always use
> >>>> reject_unknown_reverse_client_hostname at minimum, or the more
> >>>> restrictive reject_unknown_client_hostname, though this one can cause
> >>>> problems with FPs on occasion. Best to use it with warn_if_reject for a
> >>>> while and monitor what it would have rejected.
> >>>>
> >>>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
> >>>>
> >>>> However, it appears that 190.221.28.39 has rDNS of
> >>>>
> >>>> Name: host39.190-221-28.telmex.net.ar
> >>>> Address: 190.221.28.39
> >>
> >>> No. The "reject_unknown_reverse_client_hostname" in the above example
> >>> would not have generated a 450 rejection, since the IP address HAS a
> >>> reverse dns hostname.
> >>
> >> Yes, it would have.
> >
> > Not in this case.
> >
> >> Note the "unknown" in the Received line. The rDNS lookup failed
> >> during the transaction in question, thus this restriction would have
> >> generated a 450 for this transaction. Note the following that I
> >> wrote, due to the fact the host does have rDNS:
> >
> > The 'unknown' in the Received: header is not due to rDNS problems, but
> > more likely because the name->address mapping (still) fails.
> >
> > % dig +short -x 190.221.28.39
> > host39.190-221-28.telmex.net.ar.
> >
> > ... so rDNS is OK; however:
> >
> > % host host39.190-221-28.telmex.net.ar
> > Host host39.190-221-28.telmex.net.ar not found: 3(NXDOMAIN)
>
> But the test condition is 1) or 2) or 3) isn't it? Not 1) and 2) and 3)?
>
> If the latter, you seem to be saying one can have a case with an
> "unknown" stamp for the reverse-name in the log and Received: header,
> but reject_*unknown*_reverse_client_hostname will not reject the connection?
Remember: there is a difference between reject_unknown_client_hostname
and reject_unknown_reverse_client_hostname. The latter *only* rejects
mail when the client IP address->name mapping fails. This is *one* of
three conditions that causes Postfix to insert 'unknown' into Received:
headers and reject mail with the reject_unknown_client_hostname
directive. In the case we are discussing, the 'unknown' in the headers
was there *not* because of rDNS failure, but because the name->address
mapping failed. As a result, while reject_unknown_client_hostname would
reject the client, reject_unknown_*reverse*_client_hostname would not.
If this is not sufficiently clear at this point, a careful re-reading of
the relevant sections of postconf(5) is in order.
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
> Wietse Venema put forth on 3/31/2011 11:42 AM:
>
> > The format is:
> >
> > Received: from helo-hostname (verified-reverse-name [ip-address])
Yes, understand that just because the rDNS is known, does not mean it is
verified.
--
Sahil Tandon <sa...@FreeBSD.org>
Noel Jones
> Noel Jones put forth on 4/12/2011 6:56 PM:
>>> Mikael Bak put forth on 4/12/2011 7:31 AM:
>>>> Stan Hoeppner wrote:
>>>> [snip]
>>>>>
>>>>>> Received: from [190.221.28.39] (unknown [190.221.28.39])
>>>>>
>>>>> In this example, reject_unknown_reverse_client_hostname would have
>>>>> generated a 450 rejection. You should always use
>>>>> reject_unknown_reverse_client_hostname at minimum, or the more
>>>>> restrictive reject_unknown_client_hostname, though this one can cause
>>>>> problems with FPs on occasion. Best to use it with warn_if_reject
>>>>> for a
>>>>> while and monitor what it would have rejected.
>>>>>
>>>>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>>>>
>>>>> However, it appears that 190.221.28.39 has rDNS of
>>>>>
>>>>> Name: host39.190-221-28.telmex.net.ar
>>>>> Address: 190.221.28.39
>>>
>>>> No. The "reject_unknown_reverse_client_hostname" in the above example
>>>> would not have generated a 450 rejection, since the IP address HAS a
>>>> reverse dns hostname.
>>>
>
>
>> The "unknown" gives zero information about the client's rDNS. The
>
> I didn't say it did. It does tell us there was a related error, and we
> know the IP has valid rDNS.
>
>> "unknown" signifies that the client does not have correct FCrDNS, which
>> does not disclose rDNS status.
>
> Combining "unknown" with the fact that "host" returns a valid rDNS name
> tells us the likely cause of "unknown" in this case was a temporary DNS
> lookup failure.
No.
>
>> A client is marked unknown when 1) the client IP address->name mapping
>> fails, 2) the name->address mapping fails, or 3) the name->address
>> mapping does not match the client IP address.
>
> Since we know valid rDNS exists via manual sleuthing, it's pretty
> reasonable to conclude 1) above occurred, is it not?
Absolutely not. In this particular case it appears it was 2)
that failed.
The client is marked "unknown" if *any* of the three tests fail.
Repeat 100 times:
The client is marked "unknown" if *any* of the three tests fail.
>
>> The postfix log will show the reason why the client is marked unknown,
>> but postfix does not indicate the reason in the Received: header.
>
> Always good practice to check logs. Though in this case enough
> information was available in lieu of logs to correctly describe the
> issue, and put it in the context of the larger question, which was "best
> methods to block spam from this type of host".
>
> Do you disagree?
I disagree.
Postmortem sleuthing shows this client has working rDNS but no
A record for the rDNS name. You can't tell this from looking
at the Received: header.
Your advice that reject_unknown_reverse_client_hostname will
reject this host is incorrect. While that restriction is
useful and safe for most sites, it will probably not reject
this particular client, which has rDNS but no
hostname->address mapping.
-- Noel Jones
Stan Hoeppner
> Repeat 100 times:
> The client is marked "unknown" if *any* of the three tests fail.
Got it. Thanks for clarifying this Noel, and Sahil. The postconf
documentation covers both reject parameters, but it doesn't explain the
criteria used to decide when "unknown" is places in the Received:
header. This is why I made the error.
> Your advice that reject_unknown_reverse_client_hostname will reject this
> host is incorrect. While that restriction is useful and safe for most
> sites, it will probably not reject this particular client, which has
> rDNS but no hostname->address mapping.
And if you noticed in my original response, I listed 2 other better
methods to block spam from this example, and similar, hosts. That fact
should not be lost in this noise.
--
Stan
Noel Jones
> Noel Jones put forth on 4/13/2011 7:38 AM:
>
>> Repeat 100 times:
>> The client is marked "unknown" if *any* of the three tests fail.
>
> Got it. Thanks for clarifying this Noel, and Sahil. The postconf
> documentation covers both reject parameters, but it doesn't explain the
> criteria used to decide when "unknown" is places in the Received:
> header. This is why I made the error.
The criteria to label a client "unknown" is here:
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
although it doesn't specifically say so, the same criteria is
used for Received: headers, logging, policy services, access
tables, and anywhere else postfix uses a verified hostname.
All client hostnames used in postfix are verified unless the
docs for an individual feature specifically say otherwise.
-- Noel Jones
Wietse Venema
> Noel Jones put forth on 4/13/2011 7:38 AM:
>
> > Repeat 100 times:
> > The client is marked "unknown" if *any* of the three tests fail.
>
> Got it. Thanks for clarifying this Noel, and Sahil. The postconf
> documentation covers both reject parameters, but it doesn't explain the
> criteria used to decide when "unknown" is places in the Received:
> header. This is why I made the error.
Support for unverified reverse hostnames was added very late in
the Postfix development cycle. Until then, everything in Postfix
used only the verified name or "unknown".
The documentation for everything that uses the existing verified
hostname was not updated, after support for unverified reverse
hostnames was added. Noel is correct in that everything uses the
verified name except where explicitly indicated, but this is not
documented. It is obvious only to people who already used Postfix
before unverified reverse hostnames were introduced.
If someone has the time to hunt down all the places in the
documentation that discuss remote SMTP client names, they they can
send a patch that replaces "client name" by "verified client name".
Just like over the years I have been replacing "client" and "server"
by "remote SMTP client", "remote SMTP server", "local Postfix SMTP
client", and "local Postfix SMTP server".
Wietse
Jose Hales-Garcia
I've recently been getting spam that has the first received header filled in with multiple users. This is an example.
Received: from 79.14.233.16 (account <user1@domain>,
<user2@domain>,
<user3@domain>,
<user4@domain>,
<user5@domain>,
<user6@domain>,
<user7@domain>,
<user8@domain>,
<user9@domain>,
<user10@domain>,
<user11@domain>,
<user12@domain>,
<user13@domain>,
<user14@domain>,
<user15@domain>,
<user16@domain>,
<user17@domain>,
<user18@domain>,
<user19@domain>,
<user20@domain> HELO domain)
by domain (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 107437582 for <user1@domain>; Mon, 11 Apr 2011 10:19:10 +0100
Joe Ridge
subject of whether it's RFC compliant, at least one RFC I found said
that multiple From: addresses were allowed but only so long as the
Sender: header is defined, and the Sender: is only allowed to be one
address. However most of the multiple from mail we've received has not
the Sender defined.
I've had luck with /^From:.*>,.*</ for matching multi-from, but
ideally we'd like a header check that catches that and checks for a
Sender:, and if there is not one rejects it, so that we're only
rejecting the stuff that doesn't comply with the RFC.