On 11/11/2009 8:18 PM, Alex wrote:
Hi,
I hoped someone could clarify for me the difference between
check_sender_access and check_client_access? I don't know why the docs
are unclear to me.
When is a sender_access restriction used and when is a client_access
restriction used? I thought the client_access was based on the
envelope information (MAIL FROM:), but I've read so much contradictory
information that I'm confused.
All the check_*_access restrictions operate on the SMTP
envelope information -- the same information that shows up in
the postfix logs. Although some of this information can also
be found in headers, postfix doesn't look in the headers for
these.
The check_*_access restrictions tell postfix what data to
check, and are used as follows:
client = client IP or confirmed client hostname; the host that
connected to your server. This is very difficult to forge.
helo = the HELO or EHLO hostname given by the client. This is
trivial to forge, and often wrong on legit systems. This is
so close to useless that Postfix doesn't bother to log the
helo name on accepted transactions. (but /sometimes/ can be
useful to block unwanted mail.)
The client and helo are also usually found in the top-most
Received: header added by your system. Other Received:
headers are easily forged and considered suspect.
sender = the MAIL FROM address used during SMTP. This address
*may* be found in the Return-path: header. The SMTP sender is
not necessarily listed in the From: header. This is perfectly
acceptable. Both the sender and the From: header are easily
forged.
recipient = the RCPT TO address used during SMTP. This is the
address postfix uses for deciding where the mail is to be
delivered. This may not show up anywhere in the headers.
If I wanted to block mail from a specific remote user, as we normally
think of the "From:" field, it would go in client_access, I believe.
sender_access would be based on the RCPT TO: information, then?
From ~ check_sender_access ... who sent the mail.
I'm not sure how the flow works; whether it's the client_access first
or sender_access, or vice-versa.
Within each smtpd_{client, helo, sender,
recipient}_restrictions section, the restrictions are
evaluated in the order you place them.
Most people put all their restrictions under
smtpd_recipient_restrictions for clarity.
Would it be better to put check_sender_access in the
sender_restrictions instead? I currently have no sender_restrictions.
I have the following in my logs from yesterday that I'm concerned about:
Nov 10 00:06:33 smtp01 postfix_1/qmgr[12340]: 24A2B5603A6:
from=<i...@compensation.com>, size=3082, nrcpt=50 (qu
eue active)
Nov 10 00:06:33 smtp01 postfix_1/qmgr[12340]: 24A2B5603A6:
to=<mac...@yahoo.com>, relay=none, delay=14656, sta
tus=deferred (connect to b.mx.mail.yahoo.com[66.196.82.7]: server
refused mail service)
I removed all the active, defer'd and deferred files from the second
instance so they would no longer try to be delivered.
This is not good. We are not responsible for the compensation.com
domain. It also looks like there's 50 recipients, and the data from
the queue file is obvious spam. It also looks like yahoo has now
greylisted this server because it's refusing service, and other mail
servers have blocked us outright.
Yahoo routinely greylists everybody. I would be more
concerned that others are blocking you.
I know this mail came from 81.169.130.185, h1372645.stratoserver.net,
based on the information in the queue data, but the first occurrence I
can find of this IP address in the logs is embedded in the message-id.
Then that's not the right IP. Share what you're seeing.
There is no occurrence of this IP address in the pop-before-smtp logs,
so it didn't come from an authorized user there.
Below is my smtpd_recipient_restrictions again. Hopefully someone has
some ideas while I work on upgrading to a more recent version?
I expect the two most common causes of a postfix server
sending spam are
- compromised script in your web server. These usually show
up in the logs as coming from the "postfix/pickup" service.
- hijacked user account.
Examine your logs more carefully. Search for the QUEUEID of
the mail in question and find the earliest instance of it, but
remember that a QUEUEID can be reused.
smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
check_client_access hash:/etc/postfix/pop-before-smtp
reject_unauth_destination
Your postfix is not an open relay (assuming nothing silly in
$mydestination, $relay_domains, $virtual_aliases).
Everything you need can be found at
http://www.postfix.org/documentation.html
-- Noel Jones
