Re: question about searching log files
On 01/25/2017 04:44 PM, Fazzina, Angelo wrote: Hi, I am trying to grep out all the log lines for a particular connection. I added logging to see the cipher being used when connecting, now i want to see if anyone is actually getting connected and sending emails. Obviously with many threads, logs are not written chronologically, so need to find unique data like a message id to see all logs of one email transaction. Victor's collate.pl might be a good place to start. https://github.com/vdukhovni/postfix/blob/master/postfix/auxiliary/collate/collate.pl It would be helpful if the from= and to= lines into a single line. I believe there was a sed/awk script that did some of that, but I've been unable to find it. Ideas for taking this output one step further would be appreciated. Thanks, Alex
Re: SPF and forwarding
Hi, On 07/26/2015 01:34 AM, Robert Schetterer wrote: Am 26.07.2015 um 03:04 schrieb Alex: Hi, I have a postfix-2.10.5 server on fedora, and have several users that forward their mail through to gmail. This is apparently enough to break SPF and make gmail think I'm the originator of the email, instead of the actual sender. Consequently, gmail considers it spam and moves it to a spam folder. Is there anything I can do, including somehow rewriting the email, to get gmail (and others, for that matter) to accept these forwarded emails without considering them spam? Can they be rewritten using our SPF information, somehow? ... https://de.wikipedia.org/wiki/Sender_Rewriting_Scheme perhaps with fedora read https://www.mind-it.info/forward-postfix-spf-srs/ https://github.com/roehling/postsrsd That sounds like a great solution, but it appears to rewrite every address, not just those which are to be forwarded: - Due to the way PostSRSd is integrated with Postfix, sender addresses will always be rewritten even if the mail is not forwarded at all. This is because the canonical maps are read by the cleanup daemon, which processes mails at the very beginning before any routing decision is made. Have you used this? Is that the proper way to interpret what it does, that it affects every From address? Thanks, Alex
Re: Outbound rate limiting
On 07/03/2015 04:07 PM, Marius Gologan wrote: You forward messages repeatedly, flooding this mailing list too. I received a Wietse automated message saying they were rejected for various reasons pertaining to words in the body and was told to retry. Google it doesn't think differently, but is very accurate. Same is hotmail, even more accurate. Things are not ok on your side. We are not the originators of these messages. The users on this system have a .forward file that's forwarding these messages through to gmail. I mention this because I suspect it may have something to do with why it's being classified as unsolicited. As I mentioned, it has a clear unsubscribe policy and passed our normal spam filters. I didn't realize it was okay to top-post on this list. Thanks, Alex
Re: Outbound rate limiting
Hi, How do people generally deal with these? They, and the some of the network around them, are promoted to my packet filter for a few months. If I see nothing in 3 months or so, they get unblocked. To easy the load on my packet filter, not on the spammers. These are messages being forwarded through our system through the user's local .forward file. That brute-force method wouldn't work here. I would like to better identify the unsolicited email, however, particularly those google think are unsolicited. Are they alerted when these are received so they can be managed/deleted or the accounts disabled, etc? Nope. Any packets they send me are just ignored (after the first one). If you're not alerted, how do you know it's happening? That was my first question - so I don't have to read every single email, and the ones in question stand out. Thanks, Alex
Re: Outbound rate limiting
On 07/03/2015 03:23 PM, Marius Gologan wrote:
As per your errors, you send Unsolicited Messages. If that is the
case then is not related to sending rates, but to spam complaints
rate. Our system has detected an unusual rate of unsolicited mail
originating from your IP address
1. Recipients must optin. Never send to a list acquired from
somewhere or think that is my list, I can send anything to them,
even twice a day 2. Recipients may not be interested in what you
send. You need an working Un subscribe service, bounce processor, an
FBL service implemented and never bother second time an optout. 3.
Reputation - is built in time based on quality (engagement), not
quantity. Is not a technical tweak.
I thought that might be the case. These are emails being forwarded
through this system from what appears to be a trusted source with
clearly-defined un subscribe info, but I guess google thinks differently.
How do people generally deal with these? Are they alerted when these are
received so they can be managed/deleted or the accounts disabled, etc?
Thanks,
Alex
-Original Message- From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Alex Sent:
Friday, July 3, 2015 8:05 PM To: postfix users list Subject: Outbound
rate limiting
Hi,
Some time ago I had asked a question about rate limiting email to
sites like gmail and yahoo using transport maps and
destination_concurrency_limit, but I still can't get it right. I'm
trying to throttle traffic to avoid the following restrictions from
sites like google:
Jul 3 12:57:37 propemail postfix-turtle/smtp[10283]: 002454148E:
to=halland...@gmail.com, orig_to=10...@example.com,
relay=alt1.gmail-smtp-in.l.google.com[64.233.186.27]:25,
delay=101691, delays=101684/2.3/3/1.5, dsn=4.7.0, status=deferred
(host alt1.gmail-smtp-in.l.google.com[64.233.186.27] said: 421-4.7.0
[66.XXX.XXX.100 15] Our system has detected an unusual rate of
421-4.7.0 unsolicited mail originating from your IP address. To
protect our 421-4.7.0 users from spam, mail sent from your IP address
has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0
https://support.google.com/mail/answer/81126 to review our Bulk
Email 421 4.7.0 Senders Guidelines. 200si10956555qhh.75 - gsmtp (in
reply to end of DATA command))
I've tried to configure a transport map for gmail and a few others
using:
/\@gmail\.com$/ turtle: /yahoo(\.[a-z]{2,3}){1,2}$/ turtle:
/\@hotmail\.com$/ polite:
transport_maps = regexp:/etc/postfix/transport_limit
default_destination_concurrency_limit = 10
polite_initial_destination_concurrency = 1 # number of parallel
deliveries polite_destination_concurrency_limit = 3 # seconds between
each set of messages polite_destination_rate_delay = 0 # number of
recipients polite_destination_recipient_limit = 5
turtle_initial_destination_concurrency = 1
turtle_destination_concurrency_limit = 2
turtle_destination_rate_delay = 1s turtle_destination_recipient_limit
= 2
I'm really not sure what I'm still doing wrong. Any ideas would be
greatly appreciated. Thanks, Alex
Re: Understanding sender_access
Hi, I'm trying to understand how to reject mail not within my domain claiming it's from my domain. I understand body_checks can be used to block mail From: my domain, and check_sender_access can be used to block MAIL FROM my domain, but don't understand the implications of doing that. I have postfix set up on a mail relay which accepts mail from the Internet and forwards to an internal Exchange server. This Exchange server is the only server responsible for outbound mail. There are no mobile users, but on occasion mail is sent from bulk mailers as being From: our domain. I'm concerned that by implementing body_checks or a sender map could reject these emails. Do these bulk mailers generally have a common setup where they can be configured to use smtp-auth for this? I'm hoping someone can provide some general guidance on how to configure my system to permit trusted senders to use our domain while spammers trying to use From: our domain are rejected. Is this type of spoofing generally a concern? Is typically SPF the best approach? Thanks, Alex Use SPF to limit forgery by outside parties. This restricts use of the envelope sender, not the From: header. Note this may affect your recipients' ability to forward your mail elsewhere. Generally, you should ignore the contents of the From: header as a spam indicator. For example, this email says it's from me, but it's really from the postfix-users list. If you want to be strict about it, you can use a content filter such as SpamAssassin and add a little bit to the score based on the From: header, but it would be unwise to reject mail only because the From: header contains your domain. For example, you would never receive your own posts to this list. Note that sometimes mail arrives with a bare username in the From: header. Some configurations of postfix may add @$myorigin to the bare name. To prevent this, on your gateway set main.cf remote_header_rewrite_domain = domain.invalid http://www.postfix.org/ADDRESS_REWRITING_README.html#william Thanks so much for your help. That brings together the individual pieces. Now I can ask more specific questions. Thanks, Alex
Understanding sender_access
Hi, I'm trying to understand how to reject mail not within my domain claiming it's from my domain. I understand body_checks can be used to block mail From: my domain, and check_sender_access can be used to block MAIL FROM my domain, but don't understand the implications of doing that. I have postfix set up on a mail relay which accepts mail from the Internet and forwards to an internal Exchange server. This Exchange server is the only server responsible for outbound mail. There are no mobile users, but on occasion mail is sent from bulk mailers as being From: our domain. I'm concerned that by implementing body_checks or a sender map could reject these emails. Do these bulk mailers generally have a common setup where they can be configured to use smtp-auth for this? I'm hoping someone can provide some general guidance on how to configure my system to permit trusted senders to use our domain while spammers trying to use From: our domain are rejected. Is this type of spoofing generally a concern? Is typically SPF the best approach? Thanks, Alex
Rejecting spoofed emails
Hi,
I'm struggling with trying to determine for sure if my domain is
protected from spoofing (and backscatter) attacks. I'm also working on
building an SPF record, but would like to do what I can with postfix first.
It is my understanding that SPF will block based on invalid
envelope-sender, not the From: address, which is what I'm trying to
achieve here.
It's also my understanding that this is done through the use of
check_helo_access, correct?
This mail server is an Internet relay (postfix-2.10.5 on fedora) which
forwards mail to an internal Exchange system. The Exchange system is
responsible for all outbound mail. The only mail being sent from this
relay system is to the Exchange system, and bounces or other
undeliverable messages.
At one point I had a helo_checks file defined that contained something like:
example.com REJECT You are not my domain
but I was hesitant because I wasn't sure it was correct and wasn't sure
of all the hosts in the domain that could be sending mail through this
relay.
In my helo_checks file I have only my IP and a few others that were
improperly being rejected:
64.11.22.55OK
123.222.8.40 OK
I also have a helo_checks.pcre file that contains:
/./ reject_invalid_helo_hostname
I'm confused, and hope someone could help me understand what I might be
missing. I've included my postconf output below.
Is my configuration currently blocking all attempts at sending mail
From my domain without having originated from servers within my domain?
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = bcc-user
biff = no
body_checks = regexp:/etc/postfix/body_checks.pcre
bounce_queue_lifetime = 1d
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_process_limit = 200
delay_warning_time = 4h
disable_vrfy_command = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks.pcre
pcre:/etc/postfix/header_checks-jimsun.pcre
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $myhostname, localhost.$mydomain
mydomain = example.com
myhostname = mail01.example.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 64.11.22.0/27
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
dnsbl.sorbs.net=127.0.0.10*8 b.barracudacentral.org*7
dnsbl.sorbs.net=127.0.0.5*6 mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4 bl.spamcop.net*4
bl.spameatingmonkey.net*4 mykey.zen.dq.spamhaus.net=127.0.0.3*4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:11}s
postscreen_whitelist_interfaces = static:all 64.11.22.0/24
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $transport_maps, example.com, cs.example.com, example.com
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = check_client_access
hash:/etc/postfix/client_checks,
check_reverse_client_hostname_access
pcre:/etc/postfix/fqrdns-042715a.pcre
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient, permit_mynetworks,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/sender_checks,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_invalid_helo_hostname,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
check_recipient_access pcre:/etc/postfix/recipient_checks, permit
Re: backwards-compatible settings
Hi, Jun 8 21:20:03 mail02 postfix[22018]: Postfix is running with backwards-compatible default settings Meaning the compatibility level is not set the requisuite minimum value. This applies whether or not the relevant parameters have been explicitly set. Okay, I think I understand now. I interpreted this message as an indication there were still variables set to defaults from older versions. I'll update the compatibility_level variable. Thanks again, Alex
Re: backwards-compatible settings
Hi, I've upgraded from postfix-2.10.5 on fedora20 to postfix-3.0.1 on fedora22 and receiving the backwards-compatibility warning. I've checked all of the settings on the COMPATIBILITY_README page, and adjusted the relay_domains setting, which was the only one that applied to my config. I'm still receiving the compatibility warning and hoped someone could review my config to help me determine which one is still trigging the compat warning? In COMPATIBILITY_README, See the section Turning off the backwards-compatibility safety net. I was hoping there was a more precise way to locate which option is apparently triggering the compatibility warning? I understand that I can suppress the warning, but wouldn't the preferred method be to configure it with the current options? Thanks, Alex
Re: backwards-compatible settings
Hi,
I've upgraded from postfix-2.10.5 on fedora20 to postfix-3.0.1 on
fedora22 and receiving the backwards-compatibility warning. I've checked
all of the settings on the COMPATIBILITY_README page, and adjusted the
relay_domains setting, which was the only one that applied to my config.
I'm still receiving the compatibility warning and hoped someone could
review my config to help me determine which one is still trigging the
compat warning?
In COMPATIBILITY_README, See the section Turning off the
backwards-compatibility safety net.
I was hoping there was a more precise way to locate which option is
apparently triggering the compatibility warning?
To give one example, you see the following warning:
postfix/trivial-rewrite[14777]: using backwards-compatible
default setting append_dot_mydomain=yes to rewrite
localhost to localhost.example.com; please add
localhost to mydestination or other address class
I'm actually not seeing any of these messages in the logs. The only
entry I see when reloading is:
Jun 8 21:20:03 mail02 postfix[22018]: Postfix is running with
backwards-compatible default settings
Is there some log level or something else I'm missing to have postfix
reveal more specifically which setting is forcing the compatibility mode?
I've now explicitly set mynetworks_style=host, relay_domains doesn't
include $mydestination and is set to my domains, I'm not chrooting any
services, I've explicitly set append_dot_mydomain=no, and I've
explicitly set smtputf8_enable=yes.
postconf doesn't print any variables that include ${{compatibility_level}.
I realize I could just set the compatibility_level variable, but I'd
like to understand where the deprecated variables are...
Thanks again,
Alex
backwards-compatible settings
Hi,
I've upgraded from postfix-2.10.5 on fedora20 to postfix-3.0.1 on
fedora22 and receiving the backwards-compatibility warning. I've checked
all of the settings on the COMPATIBILITY_README page, and adjusted the
relay_domains setting, which was the only one that applied to my config.
I'm still receiving the compatibility warning and hoped someone could
review my config to help me determine which one is still trigging the
compat warning?
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = bcc-user
biff = no
body_checks = regexp:/etc/postfix/body_checks.pcre
bounce_queue_lifetime = 1d
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_process_limit = 200
delay_warning_time = 4h
disable_vrfy_command = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks.pcre
pcre:/etc/postfix/header_checks-jimsun.pcre
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $myhostname, localhost.$mydomain
mydomain = example.com
myhostname = bwimail02.example.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 64.XX.16.0/27
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
dnsbl.sorbs.net=127.0.0.10*8 b.barracudacentral.org*7
dnsbl.sorbs.net=127.0.0.5*6 mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4 bl.spamcop.net*4 bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:8}s
postscreen_whitelist_interfaces = static:all
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $transport_maps, example.com, cs.example.com
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = check_client_access
hash:/etc/postfix/client_checks,
check_reverse_client_hostname_access
pcre:/etc/postfix/fqrdns-042715a.pcre,
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_non_fqdn_sender, reject_unlisted_recipient,
permit_mynetworks, reject_unauth_destination,
check_sender_access hash:/etc/postfix/sender_checks,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_invalid_helo_hostname,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
check_recipient_access pcre:/etc/postfix/relay_recips_ecartis, permit
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/sender_checks,
reject_unknown_sender_domain
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
Thanks,
Alex
Re: Rate limiting guidance needed
On 06/05/2015 02:00 AM, Glenn English wrote: If it's possible to throttle based on MX record for a domain, I'd really appreciate your help. I do it with the iptables packet filter (I'm on Linux, but I suspect there are similar packages on other systems). I'm doing packet shaping with tc/htb on fedora. Can you share how you're doing it with iptables? Is this using fwmark? I shuttle incoming packets of the different protocols to individual chains, then use the 'recent' module to do rate limiting on the that protocol. I'm using it for outbound shaping, to avoid flooding a remote network like yahoo, but would also like to throttle incoming for imap and smtp abusers. Thanks, Alex
Re: Rate limiting guidance needed
Hi, If it's possible to throttle based on MX record for a domain, I'd really appreciate your help. Hi, Alex. I don't do it that way, but that sounds simpler than the way I do it! Interested to see what others come up with. I didn't receive any other responses. Is that because it's not possible to do it in that way, or am I missing something? I've read practically everything I could possibly find, and haven't found a better way. If you have a list of domains that you throttle and would like to share them, I'd sure appreciate it. So SPEAKING of the way I do it, I wrote a blog post back in 2012 about how I got mine working with all the Yahoo domains (that I could find at the time). http://www.stevejenkins.com/blog/2012/08/how-to-postfix-configuration-to-reduce-yahoo-deferrals-using-transport-maps/ I believe I actually had already found that, and did indeed use a few bits from it. Thanks, Alex
Re: postfix stats
Hi, I've been using pflogsumm but it's old and doesn't know about postscreen. I'd like to see how many connections are being refused by postscreen. What do you like? logwatch? awstats? other? http://logreporters.sourceforge.net/ I believe logwatch now includes recent copies of these two, but I like to run them standalone anyway. This one is also very good, and a new version was just made available: http://sendmailanalyzer.darold.net/ I'm sure Gilles would love to hear that you're using it and is receptive to making specific improvements. Regards, Alex
Re: Stan Hoeppner's fqrdns.pcre file?
Hi, I should have mentioned that I actually did that, once I couldn't find Stan's site: https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre For those who are using it, I've replaced it with a version from March 2013 instead of March 2012. https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre I don't know when Stan did his final update, but if anyone has one newer than Mar 27 2013, please send it to me off-list and I'll update it. I've forwarded to Steve my version from Oct 2014, but also just happened across this, from Stan, in 2012: http://postfix.1071664.n5.nabble.com/postscreen-supersedes-fqrdns-pcre-table-td46419.html As we all look to utilize every mechanism possible in the fight against spam, perhaps this list is now too rudimentary and antiquated to be used any longer? Thanks, Alex
Re: Stan Hoeppner's fqrdns.pcre file?
Hi, check_client_access uses the verified name, which is more conservative. I wasn't convinced this was a good idea, so I played it safe. So check_client_access is performing an additional DNS query on the hostname to check if it matches the IP? Right. Awesome, thanks. I'm learning all the time :-) It does, but RDNS_DYNAMIC matches fewer patterns. Are you concerned about duplicate points for effectively the same rule? A little bit, but not nearly enough to figure out how the two overlap and do something about it. I've never had a false positive report involving my GENERIC_RDNS, so it can't be *that* bad. If it ever causes an issue I'll probably drop the rule entirely. Okay, good point. I did see quite a few FPs when I was rejecting with the fqrdns.pcre file outright, however. Thanks, Alex
Re: Stan Hoeppner's fqrdns.pcre file?
Hi, I assume that means you use it in header_checks? It's still a client check; I have smtpd_recipient_restrictions = ... check_client_access pcre:$maps/generic_rdns.pcre, If you're using a version of postfix later than 2.6, you should be using check_reverse_client_hostname_access instead of check_client_access, according to the fqrdns file itself Unless there's some other reason/benefit I'm not seeing? And then in spamassassin, header GENERIC_RDNS exists:X-Generic-RDNS score GENERIC_RDNS 1.0 describe GENERIC_RDNS Reverse DNS looks generic (e.g. residential) Doesn't this all serve the same purpose as RDNS_DYNAMIC already included with spamassassin? Thanks, Alex
Re: Stan Hoeppner's fqrdns.pcre file?
Hi, On 04/27/2015 10:44 PM, Michael Orlitzky wrote: On 04/27/2015 06:55 PM, Alex Regan wrote: Hi, I assume that means you use it in header_checks? It's still a client check; I have smtpd_recipient_restrictions = ... check_client_access pcre:$maps/generic_rdns.pcre, If you're using a version of postfix later than 2.6, you should be using check_reverse_client_hostname_access instead of check_client_access, according to the fqrdns file itself Unless there's some other reason/benefit I'm not seeing? check_client_access uses the verified name, which is more conservative. I wasn't convinced this was a good idea, so I played it safe. So check_client_access is performing an additional DNS query on the hostname to check if it matches the IP? Doesn't this all serve the same purpose as RDNS_DYNAMIC already included with spamassassin? It does, but RDNS_DYNAMIC matches fewer patterns. Are you concerned about duplicate points for effectively the same rule? Thanks, Alex
Re: Stan Hoeppner's fqrdns.pcre file?
Hi, On 04/27/2015 10:44 PM, Michael Orlitzky wrote: On 04/27/2015 06:55 PM, Alex Regan wrote: Hi, I assume that means you use it in header_checks? It's still a client check; I have smtpd_recipient_restrictions = ... check_client_access pcre:$maps/generic_rdns.pcre, If you're using a version of postfix later than 2.6, you should be using check_reverse_client_hostname_access instead of check_client_access, according to the fqrdns file itself Unless there's some other reason/benefit I'm not seeing? check_client_access uses the verified name, which is more conservative. I wasn't convinced this was a good idea, so I played it safe. So check_client_access is performing an additional DNS query on the hostname to check if it matches the IP? Doesn't this all serve the same purpose as RDNS_DYNAMIC already included with spamassassin? It does, but RDNS_DYNAMIC matches fewer patterns. Are you concerned about duplicate points for effectively the same rule? Thanks, Alex
Rejecting domains with access lists
Hi, I have a fedora20 system with postfix-2.10.5 and trying to figure out sender_restrictions and client_restrictions and how access tables work. I've read the first five google results, including the access(5) man page, and don't understand the pattern matching. How can I match all users in a domain? Exact matches work, but how do I do *@domain1.com ? I tried just listing the domain itself and that doesn't work. If I have us...@domain1.com REJECT in my sender_access file, my test works. However, if I have just domain1.com, it does not: $ echo 'us...@domain1.com REJECT' sender_checks $ postmap sender_checks $ sender=us...@domain1.com $ postmap -q $sender hash:/etc/postfix/sender_checks REJECT $ echo 'domain1.com REJECT' sender_checks $ postmap sender_checks $ postmap -q $sender hash:/etc/postfix/sender_checks $ Should I consider using pcre or regex for this instead? Ideas greatly appreciated. Thanks, Alex
Re: Rate limiting to gmail, yahoo
Hi,
I posted the message below a few days ago, and haven't seen any
responses. Were my questions too confusing or did I otherwise not
provide the info necessary to help with my problem?
Thanks,
Alex
On 04/18/2015 10:25 PM, Alex Regan wrote:
Hi,
I have a fedora20 system with postfix-2.10.5 that is primarily used as a
mail store. I'd like to get some kind of rate limiting working to build
a better reputation with gmail and other systems.
This server has a couple of hundred IMAP users for a branch of a larger
company. The mail is sent from the corporate server, through a mail
router, then delivered on this system. Many of these users forward their
mail off this system to a remote account, many of which are gmail and
yahoo.
On occasion, the corporate office sends a few thousand messages to the
recipients on this system, which causes the system to queue these
messages then forward hundreds at a time to the user's remote yahoo and
gmail accounts. This frequently results in temporary bounces such as:
Apr 18 09:04:38 email postfix/smtp[30964]: 0B83D40570: host
gmail-smtp-in.l.google.com[64.233.171.26] said: 421-4.7.0 [66.XX.XX.100
15] Our system has detected an unusual rate of 421-4.7.0
unsolicited mail originating from your IP address. To protect our
421-4.7.0 users from spam, mail sent from your IP address has been
temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0
http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421
4.7.0 Email Senders Guidelines. n88si4525330qge.91 - gsmtp (in reply to
end of DATA command)
I'm trying to understand how best to rate limit mail to a group of
senders without too significantly delaying mail to these recipients.
Maybe one approach would be to implement the delay in the same way gmail
does on the mail router, such that mail is delayed at the corporate system?
The problem I'm having with my current configuration is mail is being
delivered entirely too slowly. I hoped someone had a configuration they
know to work with gmail or could generally explain what I'm doing wrong.
Setting a destination_rate_delay to 2s seems entirely too slow. I
currently have destination_recipient_limit set to 15 or so.
I feel like it would be nice to have an initial destination delay, then
no further throttling, but I'd love to hear people's experiences on if
that was a good idea.
I've created these services in master.cf:
polite unix - - n - - smtp
-o syslog_name=postfix-polite
turtle unix - - n - - smtp
-o syslog_name=postfix-turtle
My transport_rate file looks like this:
/\@gmail\.com$/ polite:
/yahoo(\.[a-z]{2,3}){1,2}$/ turtle:
/\@hotmail\.com$/ polite:
/secureserver\.net$/ polite:
Suggestions for other common systems that would be good candidates for
throttling?
I've included my main.cf below. Thanks for any ideas.
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = mail-archive
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id sleep 5
disable_mime_input_processing = no
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mydestination = $myhostname, localhost.$mydomain
mynetworks = 127.0.0.0/8, 64.X.XX.0/27
newaliases_path = /usr/bin/newaliases.postfix
transport_maps = regexp:/etc/postfix/transport_limit
polite_destination_concurrency_limit = 10
polite_destination_rate_delay = 2s
polite_destination_recipient_limit = 15
polite_initial_destination_concurrency = 1
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_CAfile = /var/www/mail.example.com-443/ssl/gd_bundle-2014.crt
smtp_tls_exclude_ciphers = 3DES
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_non_fqdn_sender,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_helo_hostname,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_client_access hash:/etc/postfix/client_checks,
check_sender_access hash
Rate limiting to gmail, yahoo
Hi,
I have a fedora20 system with postfix-2.10.5 that is primarily used as a
mail store. I'd like to get some kind of rate limiting working to build
a better reputation with gmail and other systems.
This server has a couple of hundred IMAP users for a branch of a larger
company. The mail is sent from the corporate server, through a mail
router, then delivered on this system. Many of these users forward their
mail off this system to a remote account, many of which are gmail and yahoo.
On occasion, the corporate office sends a few thousand messages to the
recipients on this system, which causes the system to queue these
messages then forward hundreds at a time to the user's remote yahoo and
gmail accounts. This frequently results in temporary bounces such as:
Apr 18 09:04:38 email postfix/smtp[30964]: 0B83D40570: host
gmail-smtp-in.l.google.com[64.233.171.26] said: 421-4.7.0 [66.XX.XX.100
15] Our system has detected an unusual rate of 421-4.7.0
unsolicited mail originating from your IP address. To protect our
421-4.7.0 users from spam, mail sent from your IP address has been
temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0
http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421
4.7.0 Email Senders Guidelines. n88si4525330qge.91 - gsmtp (in reply to
end of DATA command)
I'm trying to understand how best to rate limit mail to a group of
senders without too significantly delaying mail to these recipients.
Maybe one approach would be to implement the delay in the same way gmail
does on the mail router, such that mail is delayed at the corporate system?
The problem I'm having with my current configuration is mail is being
delivered entirely too slowly. I hoped someone had a configuration they
know to work with gmail or could generally explain what I'm doing wrong.
Setting a destination_rate_delay to 2s seems entirely too slow. I
currently have destination_recipient_limit set to 15 or so.
I feel like it would be nice to have an initial destination delay, then
no further throttling, but I'd love to hear people's experiences on if
that was a good idea.
I've created these services in master.cf:
polite unix - - n - - smtp
-o syslog_name=postfix-polite
turtle unix - - n - - smtp
-o syslog_name=postfix-turtle
My transport_rate file looks like this:
/\@gmail\.com$/ polite:
/yahoo(\.[a-z]{2,3}){1,2}$/ turtle:
/\@hotmail\.com$/ polite:
/secureserver\.net$/ polite:
Suggestions for other common systems that would be good candidates for
throttling?
I've included my main.cf below. Thanks for any ideas.
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = mail-archive
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id sleep 5
disable_mime_input_processing = no
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mydestination = $myhostname, localhost.$mydomain
mynetworks = 127.0.0.0/8, 64.X.XX.0/27
newaliases_path = /usr/bin/newaliases.postfix
transport_maps = regexp:/etc/postfix/transport_limit
polite_destination_concurrency_limit = 10
polite_destination_rate_delay = 2s
polite_destination_recipient_limit = 15
polite_initial_destination_concurrency = 1
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_CAfile = /var/www/mail.example.com-443/ssl/gd_bundle-2014.crt
smtp_tls_exclude_ciphers = 3DES
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_non_fqdn_sender,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_helo_hostname,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_client_access hash:/etc/postfix/client_checks,
check_sender_access hash:/etc/postfix/sender_checks,
check_recipient_access pcre:/etc/postfix/local_recip_map, reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
Re: Sender access issues
Hi,
A few days ago I was having an issue with not being able to use
sender_access to permit mail with non-existent hostnames to be delivered
that would normally be rejected:
Feb 24 16:48:55 mail01 postfix/smtpd[1945]: NOQUEUE: reject: RCPT from
smtp.lanyonmail.com[50.56.12.142]: 450 4.1.8 myuser@lanyonrs.local:
Sender address rejected: Domain not found; from=myuser@lanyonrs.local
to=phyl...@example.com proto=ESMTP helo=Mail.LanyonMail.com
Viktor had helped me get it working, or so I thought, but it was still
rejecting mail, and I don't entirely know why. I've since added an
additional check_sender_access to the recipient restrictions, and I
believe it's working again, but I didn't want to do it that way, and I'm
not even sure that was the actual fix, as I was working under pressure.
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/sender_checks,
--- ---
reject_unknown_sender_domain,
...
permit
smtpd_sender_restrictions = reject_unknown_sender_domain
-
I've separated out the smtpd_{client,recipient,sender}_restrictions, and
added the email address with the invalid domain I wish to allow to
sender_access, but it's still being rejected.
I've included my postconf output below, and hoped someone could review
it. I'd like to remove the check_sender_access in the recipient
restrictions to separate it out into the three different classes.
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = bcc-user
biff = no
body_checks = regexp:/etc/postfix/body_checks.pcre
bounce_queue_lifetime = 1d
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_process_limit = 200
delay_warning_time = 4h
disable_vrfy_command = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks.pcre
pcre:/etc/postfix/header_checks-jimsun.pcre
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $myhostname, localhost.$mydomain
mydomain = example.com
myhostname = bwimail01.example.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 68.123.123.40/29
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
dnsbl.sorbs.net=127.0.0.10*8 b.barracudacentral.org*7
dnsbl.sorbs.net=127.0.0.5*6 mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4 bl.spamcop.net*4 bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:8}s
postscreen_whitelist_interfaces = static:all 68.123.123.40/29
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination, $transport_maps, example.com
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/client_checks,
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_helo_required = yes
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient,
permit_mynetworks,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/sender_checks,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_invalid_helo_hostname,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
permit
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/sender_checks,
Re: Sender access issues
Hi, What does the below report (with the exact address from the unmunged log message): $ sender=myuser@lanyonrs.local $ postmap -q $sender hash:/etc/postfix/sender_checks I had *@lanyonrs.local OK in sender_checks and it printed nothing. I added the explicit email address and it returns OK. Nothing in the Postfix documentation promises any special meaning for *@domain keys in indexed tables. If you're going by intuition and guess-work rather than documentation, you won't get far. The lookup keys for access tables are documented under: http://www.postfix.org/access.5.html To match every address in a domain, just use the domain as the lookup key: lanyonrs.local OK An even better solution is to fix the problem on the sender end, and use a real sending address. I even looked at access(5) just before sending this, and have no idea how I missed that. I think I need a break. Yes, certainly using a real address is the proper solution here. Thanks for your continued help with this. Alex
Re: Sender access issues
Hi, Feb 24 16:48:55 mail01 postfix/smtpd[1945]: NOQUEUE: reject: RCPT from smtp.lanyonmail.com[50.56.12.142]: 450 4.1.8 myuser@lanyonrs.local: Sender address rejected: Domain not found; from=myuser@lanyonrs.local to=phyl...@example.com proto=ESMTP helo=Mail.LanyonMail.com That was two days ago, who knows how it relates to your current configuration. Test by sending from the same address via a direct connection to your MTA and report results that match the exact configuration you're reporting. My apologies. I was having a little difficulty explaining what's happening while still keeping the history in tact. I thought it was working after the changes we made the other day, but it started rejecting the messages again in the same way as shown above: Feb 26 19:46:03 mail01 postfix/smtpd[23353]: NOQUEUE: reject: RCPT from smtp.lanyonmail.com[50.56.12.142]: 450 4.1.8 myuser@lanyonrs.local: Sender address rejected: Domain not found; from=myuser@lanyonrs.local to=doro...@example.com proto=ESMTP helo=Mail.LanyonMail.com What does the below report (with the exact address from the unmunged log message): $ sender=myuser@lanyonrs.local $ postmap -q $sender hash:/etc/postfix/sender_checks I had *@lanyonrs.local OK in sender_checks and it printed nothing. I added the explicit email address and it returns OK. Maybe that is what I inadvertently changed that caused it to stop working after some point that it was working. smtpd_recipient_restrictions = ... check_sender_access hash:/etc/postfix/sender_checks, reject_unknown_sender_domain, ... Why is the sender logic repeated in the recipient restrictions? I must not have explained very clearly that I had added that when it stopped working because it's what I last had working properly, and it did get it to work again. I'd now like to identify why the method we worked out two days ago stopped working and started to reject mail again. Thanks, Alex
Sender access issues
Hi,
I have a postfix-2.10.5 system on fedora20 and having some trouble with
mail being rejected due to unknown senders:
Feb 24 16:48:55 mail01 postfix/smtpd[1945]: NOQUEUE: reject: RCPT from
smtp.lanyonmail.com[50.56.12.142]: 450 4.1.8 myuser@lanyonrs.local:
Sender address rejected: Domain not found; from=myuser@lanyonrs.local
to=phyl...@example.com proto=ESMTP helo=Mail.LanyonMail.com
Ideally, the sender would put their envelope-sender address in DNS, but
it's not something that can be done now. I've added a
check_sender_access in my smtpd_recipient_restrictions, but it's still
not working, and hoped someone could help me understand why.
My /etc/postfix/sender_checks file contains:
myuser@lanyonrs.localOK
I've included my config below and would be grateful if someone had some
ideas.
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = bcc-user
biff = no
body_checks = regexp:/etc/postfix/body_checks.pcre
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_process_limit = 200
delay_warning_time = 4h
disable_vrfy_command = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks.pcre
pcre:/etc/postfix/header_checks-jimsun.pcre
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 2400
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $myhostname, localhost.$mydomain
mydomain = example.com
myhostname = mail01.example.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 68.123.123.40/29
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
dnsbl.sorbs.net=127.0.0.10*8 b.barracudacentral.org*7
dnsbl.sorbs.net=127.0.0.5*6 mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4 bl.spamcop.net*4 bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:8}s
postscreen_whitelist_interfaces = static:all 68.123.123.40/29
queue_directory = /var/spool/postfix
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination, $transport_maps, example.com
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = check_client_access
cidr:/etc/postfix/client_access_blocklist
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient, permit_mynetworks,
reject_unauth_destination,
check_client_access hash:/etc/postfix/client_checks,
check_sender_access hash:/etc/postfix/sender_checks,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_invalid_helo_hostname,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
check_recipient_access pcre:/etc/postfix/property_recip_map,
check_recipient_access pcre:/etc/postfix/recipient_checks,
check_recipient_access pcre:/etc/postfix/relay_recips_ecartis,
permit
smtpd_sender_restrictions = reject_unknown_sender_domain
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
Thanks,
Alex
Re: Sender access issues
Hi,
On 02/24/2015 08:34 PM, Viktor Dukhovni wrote:
On Tue, Feb 24, 2015 at 08:07:59PM -0500, Alex Regan wrote:
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/sender_checks,
--- ---
reject_unknown_sender_domain,
...
permit
smtpd_sender_restrictions = reject_unknown_sender_domain
-
The problem was that you were checking in two places, but added an
exception in only one of them.
So you're saying that if I didn't have the smtpd_sender_restrictions at
all, it would have worked in recipient restrictions, correct?
These check_{client,sender}_access restrictions have been in the recipient
restrictions section for a long time, without realizing I was doing it
incorrectly.
It is not incorrect, rather a matter of style. However:
Instead, I've configured sender, client, and helo restrictions, as such, and
removed them all from recipient restrictions:
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/sender_checks
reject_unknown_sender_domain
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/client_checks,
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_helo_restrictions =
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks
Does that now seem correct?
Maybe. Depends whether any of these need exceptions for hosts
in mynetworks (previously in effect when they were part of the
recipient restrictions).
See http://www.postfix.org/postconf.5.html#smtpd_delay_reject
Some people find the all in one approach simpler. With Postfix
2.10 or later (only), you're encouraged to move relay control into
smtpd_relay_restrictions. Otherwise depends on your needs and
which you find easier to work with.
Now that I've separated it out, I believe I'll have an easier time of
understanding it and maintaining it.
Hmm... Would you describe what my configuration would look like using
the new relay restrictions?
Thanks,
Alex
Re: Sender access issues
Hi,
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient,
permit_mynetworks,
reject_unauth_destination,
check_client_access hash:/etc/postfix/client_checks,
check_sender_access hash:/etc/postfix/sender_checks,
--- ---
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_invalid_helo_hostname,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
check_recipient_access pcre:/etc/postfix/property_recip_map,
check_recipient_access pcre:/etc/postfix/recipient_checks,
check_recipient_access pcre:/etc/postfix/relay_recips_ecartis,
permit
smtpd_sender_restrictions = reject_unknown_sender_domain
-
Yes, thanks so much. I just came back to check my mail and follow up
that I just figured it out! It occurred to me when I realized I had
somehow lost track that I was working with recipient restrictions.
These check_{client,sender}_access restrictions have been in the
recipient restrictions section for a long time, without realizing I was
doing it incorrectly.
Instead, I've configured sender, client, and helo restrictions, as such,
and removed them all from recipient restrictions:
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/sender_checks
reject_unknown_sender_domain
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/client_checks,
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_helo_restrictions =
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks
Does that now seem correct?
Thanks,
Alex
Transport maps and rate limiting
Hi, I have a fedora20 server with postfix-2.10.5 I'm trying to configure rate limiting for outbound mail to google, yahoo, etc, in hopes of not only building a better reputation with these systems, but also to prevent my outbound pipe from being saturated. I've configured a few of the rate_delay parameters according to the instructions here: http://steam.io/2013/04/01/postfix-rate-limiting/ It includes building two new transports in master.cf polite unix - - n - - smtp turtle unix - - n - - smtp And in /etc/postfix/transport gmail.com polite: yahoo.com turtle: hotmail.com polite: In main.cf I've configured: transport_maps = hash:/etc/postfix/transport polite_destination_concurrency_limit = 10 polite_destination_rate_delay = 0 polite_destination_recipient_limit = 5 turtle_destination_concurrency_limit = 5 turtle_destination_rate_delay = 3s turtle_destination_recipient_limit = 2 I believe the problem is that messages not destined for gmail, yahoo, or hotmail no longer have a path, correct? Do those rates and delays look okay? Feb 14 19:26:31 mail01 postfix/trivial-rewrite[16804]: warning: transport_maps lookup failure Feb 14 19:26:31 mail01 postfix/error[17775]: 7545542293: to=u...@example.com, relay=none, delay=27 985, delays=27985/0/0/0.01, dsn=4.3.0, status=deferred (address resolver failure) Any ideas greatly appreciated. Thanks, Alex
Re: Building a spam honeypot, or need to exclude domains/users from RBLs
Hi, Is there any existing documentation on how to create a spam honeypot as it relates to doing it on a production server, or do I really need to just create a virtual machine with a basic postfix configuration to do this? You can use postfix smtp-sink to implement a simple spam collector. It never rejects mail, it never delivers mail, it only saves all mail to file. smtp-sink is included with Postfix source code. Thanks guys for your help. I'll investigate. Thanks, Alex
Building a spam honeypot, or need to exclude domains/users from RBLs
Hi, I'm using postfix-2.10.5 on fedora20 with amavisd-new and spamassassin, as well as greylisting, and would like to create a spam honeypot. The problem is that postfix is configured on my system with zen, postscreen, and other methods to block spam based on IP. Is there any way to disable these checks for a specific domain or specific user in a specific domain such that I can create a bogus user email in my domain? Is there any existing documentation on how to create a spam honeypot as it relates to doing it on a production server, or do I really need to just create a virtual machine with a basic postfix configuration to do this? Thanks, Alex
