Hi folks,
I'm still working on the problem you have all been so kind in helping
me with, and have a problem relating to helo_checks. We require a
proper FQDN for the helo, but would like to make an exception for
several IP addresses.
I've added check_helo_access as the first line of my
smtpd_recipient_restrictions and it still doesn't work:
smtpd_recipient_restrictions =
check_helo_access hash:/etc/postfix/helo_checks,
helo_checks contains:
192.168.1.99 OK
Yet it is still rejected:
Nov 12 14:40:21 smtp01 postfix/smtpd[8282]: reject: RCPT from
unknown[192.168.1.99]: 504 <helostring>: Helo command rejected: need
fully-qualified hostname; from=<ins...@mydomain.com>
to=<outs...@gmail.com>
What could I be doing wrong?
Thanks,
Alex
On Wed, Nov 11, 2009 at 10:52 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:
> 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
>
