Re: Relaying problems
On 11/12/2009 10:09 PM, Alex wrote:
Hi,
If you don't want to whitelist the IP address completely but instead just
want to allow it to bypass your HELO checks, then check_helo_access will
work. However, you should first understand that the type of lookup performed
depends on the name of the restriction, NOT where the restriction is placed.
For example, as was mentioned before, check_client_access looks up the
client (hostname, IP address,...). Likewise, check_sender_access looks up
the envelope sender, domain, etc. In this case, check_helo_access is going
to look up the HELO hostname of the client.
But helo is a component of the envelope, no? Wouldn't it then make
sense to have it in sender_checks?
On 11/13/2009 1:30 AM, LuKreme wrote:
On 12-Nov-2009, at 21:09, Alex wrote:
But helo is a component of the envelope, no?
No.
Technically, the envelop is only the sender and receiver.
However, for purposes of this list we commonly also include
the client IP/hostname and HELO in discussions of envelope data.
So you do finely get that yes and no answer you've been
looking for. ;)
At any rate, you miss the point.
The smtpd_{client, helo, sender, recipient}_restrictions are
about *when* a check takes place, corresponding to the {client
connection, HELO, MAIL FROM, RCPT TO} stage of the SMTP
transaction.
(The *when* is altered by the smtpd_delay_reject (default yes)
which delays all those restrictions from running until the
client sends RCPT TO. This was added as a feature and as a
default after it was discovered that some clients react badly
to being rejected prior to RCPT TO. It also has the
beneficial side effect that you get more complete logging of
rejected transactions. But this is distracting from your issue.)
The check_{client, helo, sender, recipient}_access tests look
for something in a list, and if the something is found, do
that function. You have to tell postfix /what/ to look for by
specifying client, helo, sender, or recipient.
So, for example, if you tell postfix to look for the client IP
in a table by using check_client_access, you don't want to put
a HELO name or a sender address in the table -- it will never
match.
Okay, just tried that from a test network, and it doesn't work for me.
In helo_checks.pcre I have:
/^inside.testdomain.com$/ DUNNO
/./ reject_invalid_helo_hostname
There is no reject_invalid_helo_hostname in postfix 1.1. If
that table was used, you would have received a server
configuration error and the mail would have been deferred with
a 421 code.
I've reloaded postfix and performed the same steps as I have
previously, and it produces this in the logs:
Nov 12 22:48:51 smtp01 postfix/smtpd[6860]: reject: RCPT from albert.testdomain
.com[192.168.1.99]: 504alex: Helo command rejected: need fully-qualified hos
tname; from=a...@testdomain.com to=a...@testdomain.com
To follow up with Noel's post,
You use check_client_access because your table contains a client IP. If your
table
contained the actual bad HELO name you could use check_helo_access, but
generally
it's better to whitelist by client address.
Does that conflict with what Michael was saying about not allowing IP
addresses in access files, or am I misunderstanding what Michael was
saying?
Eh? I didn't see anything about not allowing IPs.
Assuming we do know that the helo would consistently be alex123 for
test purposes, I could somehow configure the helo_access to permit
based on that string?
Yes, you can whitelist the specific bad helo. However, it's
generally better to whitelist a client (verified property
unique to that client) rather than a helo or sender address
(something easily forged).
Below is the postconf -n. Thanks very much for analyzing it for me.
Actually, I didn't want to be presumptuous, but it probably would have
been quicker in the end :-)
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
alternate_config_directories = /etc/postfix_f
always_bcc =
biff = no
body_checks = regexp:/etc/postfix/body_checks
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_process_limit = 120
delay_warning_time = 0
disable_mime_input_processing = yes
disable_vrfy_command = yes
enabled = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 25600
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains =
zen.spamhaus.org
cbl.abuseat.org
sbl.spamhaus.org
pbl.spamhaus.org
zen.spamhaus.org already includes both sbl.spamhaus.org and
pbl.spamhaus.org.
maximal_queue_lifetime = 5d
message_size_limit = 13312000
mime_header_checks =
minimal_backoff_time = 800s
mydestination = $myhostname, localhost.$mydomain
myhostname = smtp01.testdomain.com
mynetworks = 127.0.0.0/8, 192.168.161.45/32,
Re: Relaying problems
On 11/13/2009 10:57 AM, Noel Jones wrote: maps_rbl_domains = zen.spamhaus.org cbl.abuseat.org sbl.spamhaus.org pbl.spamhaus.org zen.spamhaus.org already includes both sbl.spamhaus.org and pbl.spamhaus.org. Oops, zen also includes cbl.abuseat.org. So you're doing 1 lookup for the price of 4. -- Noel Jones
Re: Relaying problems
Hi,
At any rate, you miss the point.
The smtpd_{client, helo, sender, recipient}_restrictions are about *when* a
check takes place, corresponding to the {client connection, HELO, MAIL FROM,
RCPT TO} stage of the SMTP transaction.
It works now, thanks so much.
I understand much more clearly how this all goes together. I was
rejecting non-fqdn hostnames before I was giving it the opportunity to
override the restriction according to the data flow.
I'm really excited and inspired by what I've been able to do with
everyone's help.
I hope to upgrade the server before the end of the year. It's been
running fine the way it is. We haven't really had the resources to
spend on something that's working just fine. The server is on the
other side of the country, and it just routes mail all day and doesn't
complain. It had nearly 700 days of uptime before I rebooted it
recently, without incident.
Thanks again,
Alex
Re: Relaying problems
On 11/11/2009 11:36 PM, Alex wrote: Hi, But commas do make it prettier to look at. My reality has been shaken, and everything I previously thought I knew drawn into question. Yeah, crazy. I always had the smtpd_recipient_restrictions separated by a comma, all on one line, until recently when I saw so many others using it otherwise. Thanks to all for the information so far. I've got a bit more reading to do, and have to monitor more closely. Not only do queue IDs get reused, they change mid-stream because of the two-queue configuration. Thanks again, Alex But postfix logs when the QUEUEID changes, so that's not such a big deal. You can use syslog_name to differentiate logging in the different instances. That makes trouble shooting easier. -- Noel Jones
Re: Relaying problems
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
Re: Relaying problems
Hi, To follow up with my own post, I should mention that I did postmap the file, which I should have mentioned. I also thought it might be better to add it to smtpd_client_restrictions? smtpd_client_restrictions = check_helo_access hash:/etc/postfix/helo_checks Perhaps that's the way to do it instead? Thanks again, Alex On Thu, Nov 12, 2009 at 2:48 PM, Alex mysqlstud...@gmail.com wrote: 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
Re: Relaying problems
On 11/12/2009 1:48 PM, Alex wrote: 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]: 504helostring: Helo command rejected: need fully-qualified hostname; from=ins...@mydomain.com to=outs...@gmail.com What could I be doing wrong? Thanks, Alex Stop top posting. Google for the term if you don't understand. It looks as if you're trying to whitelist the client by IP, so you need check_client_access to check an IP. As a general rule, access tables should be *below* reject_unauth_destination to prevent accidental open relay. You have a lot of reading to do. Start here: http://www.postfix.org/documentation.html -- Noel Jones
Re: Relaying problems
Noel Jones wrote: On 11/12/2009 1:48 PM, Alex wrote: 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]: 504helostring: Helo command rejected: need fully-qualified hostname; from=ins...@mydomain.com to=outs...@gmail.com What could I be doing wrong? Thanks, Alex Stop top posting. Google for the term if you don't understand. It looks as if you're trying to whitelist the client by IP, so you need check_client_access to check an IP. As a general rule, access tables should be *below* reject_unauth_destination to prevent accidental open relay. You have a lot of reading to do. Start here: http://www.postfix.org/documentation.html -- Noel Jones If you don't want to whitelist the IP address completely but instead just want to allow it to bypass your HELO checks, then check_helo_access will work. However, you should first understand that the type of lookup performed depends on the name of the restriction, NOT where the restriction is placed. For example, as was mentioned before, check_client_access looks up the client (hostname, IP address,...). Likewise, check_sender_access looks up the envelope sender, domain, etc. In this case, check_helo_access is going to look up the HELO hostname of the client. So, your HELO access map should match hostnames (or domain names, see the docs for check_helo_access), not IP addresses. This is always true, regardless of whether the check_foo_access statements appear in smtpd_client_restrictions, smtpd_sender_restrictions, etc. Now -- and there may be a cleaner way to do this -- when I want to bypass a restriction for some set of clients or senders, I usually use a pcre table that falls through to some default restrictions given that nothing else matched first. For example, you could have, check_helo_access pcre:/etc/postfix/helo_checks and then within that file, /^hostname-you-want-to-allow$/ DUNNO # Matches everything else. /./ reject_invalid_helo_hostname
Re: Relaying problems
Hi, Stop top posting. Google for the term if you don't understand. Sorry, that was only to follow up with my own post, so people had a reference. It looks as if you're trying to whitelist the client by IP, so you need check_client_access to check an IP. Yes, and I've tried that too. I have done quite a bit of reading, and afraid I'm getting conflicting info now. I've read posts from Ralf in the past, as well as the man pages and other docs at postfix.org, but it's still not working. Can you point me to the right documentation that outlines why it would be check_client_access to check an IP? For the time being, I've added the IP to mynetworks, but that's obviously less than the most desirable approach. Even with the following it doesn't work: smtpd_recipient_restrictions = permit_mynetworks [...] check_helo_access hash:/etc/postfix/helo_checks, check_client_access hash:/etc/postfix/client_checks In client_checks and helo_checks I have the IP listed: 192.168.1.99 OK and have postmap'd the file. I've tried a separate smtpd_helo_restrictions with similar results: smtpd_helo_restrictions = permit_mynetworks check_helo_access hash:/etc/postfix/helo_checks permit As a general rule, access tables should be *below* reject_unauth_destination to prevent accidental open relay. You have a lot of reading to do. Start here: http://www.postfix.org/documentation.html Yes, I know. This is part of a larger project. I'd appreciate your direction here. Here are some of the directions I have followed that have lead me to where I am: # Postfix-users from 2004 smtpd_client_restrictions? http://marc.info/?t=11013771602r=1w=2 smtpd_client_restrictions = permit_mynetworks check_helo_access hash:/etc/postfix/helo_checks I've since removed it, basically starting from scratch, because I'm afraid it has created more problems than it solves. My full smtpd_recipient_restrictions is below: smtpd_recipient_restrictions = reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining permit_mynetworks reject_invalid_hostname reject_non_fqdn_hostname reject_unauth_destination check_helo_access hash:/etc/postfix/helo_checks check_recipient_access pcre:/etc/postfix/recipient_checks check_sender_access hash:/etc/postfix/sender_checks check_client_access hash:/etc/postfix/client_checks Thanks so much. Best regards, Alex
Re: Relaying problems
On 11/12/2009 9:21 PM, Alex wrote: It looks as if you're trying to whitelist the client by IP, so you need check_client_access to check an IP. Yes, and I've tried that too. I have done quite a bit of reading, and afraid I'm getting conflicting info now. I've read posts from Ralf in the past, as well as the man pages and other docs at postfix.org, but it's still not working. Can you point me to the right documentation that outlines why it would be check_client_access to check an IP? You use check_client_access because your table contains a client IP. If your table contained the actual bad HELO name you could use check_helo_access, but generally it's better to whitelist by client address. If you feel you've gotten conflicting answers, it's only because you keep changing the question. (Way past) Time to post postconf -n and the actual log entry of what you are trying to allow. -- Noel Jones
Re: Relaying problems
Hi, If you don't want to whitelist the IP address completely but instead just want to allow it to bypass your HELO checks, then check_helo_access will work. However, you should first understand that the type of lookup performed depends on the name of the restriction, NOT where the restriction is placed. For example, as was mentioned before, check_client_access looks up the client (hostname, IP address,...). Likewise, check_sender_access looks up the envelope sender, domain, etc. In this case, check_helo_access is going to look up the HELO hostname of the client. But helo is a component of the envelope, no? Wouldn't it then make sense to have it in sender_checks? So, your HELO access map should match hostnames (or domain names, see the docs for check_helo_access), not IP addresses. I've tried that too, and the way I have it configured, it rejects both ways. This is always true, regardless of whether the check_foo_access statements appear in smtpd_client_restrictions, smtpd_sender_restrictions, etc. No IP addresses in either of those files? There's a HOWTO by Jim Seymour, linked from postfix.org, detailing UCE controls that I followed, and it interchanges both: http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt I even followed it to help with the helo_checks issue, which hasn't worked. Now -- and there may be a cleaner way to do this -- when I want to bypass a restriction for some set of clients or senders, I usually use a pcre table that falls through to some default restrictions given that nothing else matched first. For example, you could have, Okay, just tried that from a test network, and it doesn't work for me. In helo_checks.pcre I have: /^inside.testdomain.com$/ DUNNO /./ reject_invalid_helo_hostname In main.cf I have: check_helo_access pcre:/etc/postfix/helo_checks.pcre Perhaps the reject_invalid_helo_hostname doesn't work with postfix-v1? I've reloaded postfix and performed the same steps as I have previously, and it produces this in the logs: Nov 12 22:48:51 smtp01 postfix/smtpd[6860]: reject: RCPT from albert.testdomain .com[192.168.1.99]: 504 alex: Helo command rejected: need fully-qualified hos tname; from=a...@testdomain.com to=a...@testdomain.com To follow up with Noel's post, You use check_client_access because your table contains a client IP. If your table contained the actual bad HELO name you could use check_helo_access, but generally it's better to whitelist by client address. Does that conflict with what Michael was saying about not allowing IP addresses in access files, or am I misunderstanding what Michael was saying? Assuming we do know that the helo would consistently be alex123 for test purposes, I could somehow configure the helo_access to permit based on that string? Below is the postconf -n. Thanks very much for analyzing it for me. Actually, I didn't want to be presumptuous, but it probably would have been quicker in the end :-) alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases alternate_config_directories = /etc/postfix_f always_bcc = biff = no body_checks = regexp:/etc/postfix/body_checks command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_process_limit = 120 delay_warning_time = 0 disable_mime_input_processing = yes disable_vrfy_command = yes enabled = yes fallback_relay = header_checks = pcre:/etc/postfix/header_checks mail_owner = postfix mailbox_command = /usr/bin/procmail mailbox_size_limit = 25600 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maps_rbl_domains = zen.spamhaus.org cbl.abuseat.org sbl.spamhaus.org pbl.spamhaus.org maximal_queue_lifetime = 5d message_size_limit = 13312000 mime_header_checks = minimal_backoff_time = 800s mydestination = $myhostname, localhost.$mydomain myhostname = smtp01.testdomain.com mynetworks = 127.0.0.0/8, 192.168.161.45/32, 192.168.174.45/32, 192.168.227.0/24 newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix queue_run_delay = 800s readme_directory = /etc/postfix/README_FILES relay_domains = $mydestination, testdomain.com relayhost = sample_directory = /etc/postfix/samples sender_canonical_maps = sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_recipient_restrictions = reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining permit_mynetworks reject_invalid_hostname reject_non_fqdn_hostname reject_unauth_destination check_helo_access hash:/etc/postfix/helo_checks check_recipient_access pcre:/etc/postfix/recipient_checks check_sender_access hash:/etc/postfix/sender_checks check_client_access hash:/etc/postfix/client_checks reject_maps_rbl
Re: Relaying problems
On 12-Nov-2009, at 21:09, Alex wrote: But helo is a component of the envelope, no? No. -- [TN]FBMachine i got kicked out of Barnes and Noble once for moving all the bibles into the fiction section
Re: Relaying problems
On 11/10/2009, Alex (mysqlstud...@gmail.com) wrote: I'm still using postfix-1.x, Most people here would stop reading there and press/click delete (or some might simply click 'Reply' and add the words 'upgrade'). So... UPGRADE. It is time. is there going to be significant configuration changes to upgrade to the current from 1.x? Easily answered for yourself with a little reading... the source IP is not one from the pop-before-smtp database And you'd lose a lot of people here too. Pop-b4-smtp is insecure, and its use is strongly discouraged.
Re: Relaying problems
Hi, I'm still using postfix-1.x, Most people here would stop reading there and press/click delete (or some might simply click 'Reply' and add the words 'upgrade'). So... UPGRADE. It is time. Thanks for hitting me with the well-deserved clue-bat. Advice well taken. Now, what if I said I was still using bind-4? Heh, just joking :-) Thanks again, Alex
Re: Relaying problems
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. 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? I'm not sure how the flow works; whether it's the client_access first or sender_access, or vice-versa. 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. 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. 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? 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 reject_invalid_hostname reject_non_fqdn_hostname reject_unknown_sender_domain # reject_unknown_recipient_domain # reject_unauth_pipelining check_client_access hash:/etc/postfix/client_checks check_client_access pcre:/etc/postfix/client_checks.pcre check_recipient_access pcre:/etc/postfix/recipient_checks check_helo_access hash:/etc/postfix/helo_checks check_sender_access hash:/etc/postfix/sender_checks check_sender_access hash:/etc/postfix/disallow_my_domain check_recipient_access pcre:/etc/postfix/recipient_checks.pcre Below is the other relevant information from main.cf. Please excuse the obscuring of my real domain with 'exxample.com' in its place. mydestination = $myhostname, localhost.$mydomain, smtp0.exxample.com mydomain = exxample.com myhostname = smtp0.exxample.com Thanks so much. Best regards, Alex On Wed, Nov 11, 2009 at 12:05 PM, Alex mysqlstud...@gmail.com wrote: Hi, I'm still using postfix-1.x, Most people here would stop reading there and press/click delete (or some might simply click 'Reply' and add the words 'upgrade'). So... UPGRADE. It is time. Thanks for hitting me with the well-deserved clue-bat. Advice well taken. Now, what if I said I was still using bind-4? Heh, just joking :-) Thanks again, Alex
Re: Relaying problems
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. Both restrictions look up something in an access table, and return a result. With check_client_access, the thing that is looked up is the client. By client, the following is meant: client hostname, parent domains, client IP address, or networks obtained by stripping least significant octets With check_sender_access, the sender of the message is used as the lookup key. Again, multiple lookups are made: MAIL FROM address, domain, parent domains, or localpart@ 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. If you want to block the MAIL FROM address, use check_sender_access. 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? Use check_sender_access to block email addresses, but beware that the envelope (MAIL FROM) sender often disagrees with the From: header. I'm not sure how the flow works; whether it's the client_access first or sender_access, or vice-versa. Normally, client information is available first, but if you're deferring rejection, you can place the restrictions in any order you wish. Below is my smtpd_recipient_restrictions again. Hopefully someone has some ideas while I work on upgrading to a more recent version? 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 reject_invalid_hostname reject_non_fqdn_hostname reject_unknown_sender_domain # reject_unknown_recipient_domain # reject_unauth_pipelining check_client_access hash:/etc/postfix/client_checks check_client_access pcre:/etc/postfix/client_checks.pcre check_recipient_access pcre:/etc/postfix/recipient_checks check_helo_access hash:/etc/postfix/helo_checks check_sender_access hash:/etc/postfix/sender_checks check_sender_access hash:/etc/postfix/disallow_my_domain check_recipient_access pcre:/etc/postfix/recipient_checks.pcre I'm guessing even v1.x required commas between restrictions?
Re: Relaying problems
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
Re: Relaying problems
Hi, But commas do make it prettier to look at. My reality has been shaken, and everything I previously thought I knew drawn into question. Yeah, crazy. I always had the smtpd_recipient_restrictions separated by a comma, all on one line, until recently when I saw so many others using it otherwise. Thanks to all for the information so far. I've got a bit more reading to do, and have to monitor more closely. Not only do queue IDs get reused, they change mid-stream because of the two-queue configuration. Thanks again, Alex
Re: Relaying problems
On Tue, Nov 10, 2009 at 09:01:45PM -0500, Alex wrote: Reading from a message in the second queue waiting to be delivered, the source IP is not one from the pop-before-smtp database Is not now is not the same as was not then. and is not from the internal network. You have shown no configuration information that documents your definition of mynetworks. The destination is is a user at yahoo.com. You have shown no configuration information that documents your definitions of mydestination, relay_domains, ... How could this happen? Below is the recipient restrictions from the first instance: 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 - Client listed in $mynetworks, or authorized via pop-before-smtp - Recipient domain matches $mydestination, or $relay_domains or is (1.x) listed in $virtual_maps, or $virtual_mailbox_maps. - The original recipient was not actually at Yahoo, the mail in question a result of local rewriting, or other local transformation. It could also be a bounce. The last 1.x release is from early 2002, it is not easy to remember its features at this point. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
