Fighting Backscatter

[Steve Jenkins]

I've read through the readme at:

http://www.postfix.org/BACKSCATTER_README.html

and thought I was doing everything right. but my personal mail server is
still getting listed at Backscatterer.org. :(

I'm running 2.6.5 and here's my postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:20209
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
smtpd_milters = inet:localhost:20209
smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_unauth_destination,
reject_unknown_recipient_domain,  
reject_unknown_sender_domain,   
reject_non_fqdn_recipient, 
reject_non_fqdn_sender, 
reject_invalid_hostname,
permit_mynetworks
permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_sender_domain
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = virtualdomain.com
virtual_alias_maps = hash:/etc/postfix/virtual


I suspect that I might have something wonky in the smtpd recipient and/or
sender restriction areas. Anyone see anything glaring that might be me
blacklisted? I've checked the maillogs around the time that backscatter.org
reports, and can't see anything obvious.

Thanks in advance,

SJ

RE: Fighting Backscatter

[Steve Jenkins]

There are a few entries in there that seem to match the "<>" bill, but I'm
not sure I'm understanding what they're saying, or even what I should be
looking for to troubleshoot.

For some background, this is my personal server that I run my family's mail
on. There are a few local IMAP/POP accounts for my immediate family members
(they are also allowed to relay mail using SMTP-AUTH), but most of the valid
destination addresses on this box are virtual aliases that forward
"firstn...@familyname.com" to everyone's respective gmail, aol, cox.net
addresses, etc.

Back to the logfile, here are some examples when I grep for <> (any
references to my users and/or hosts have been replaced with myhost,
mydomain, and myuser).

I have a bunch like these that appear harmless (although I'm not sure):

Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: BA1AE10423D2: from=<>,
size=4951, nrcpt=1 (queue active)
Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: 9A025104245A: from=<>,
size=8497, nrcpt=1 (queue active)
Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: 3B9EF10423F1:
from=, size=2790, nrcpt=67 (queue active)
Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: 526E71042420: from=<>,
size=8237, nrcpt=1 (queue active)
Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: 69B3B1042410: from=<>,
size=8472, nrcpt=1 (queue active)
Oct 10 03:30:24 carbonfiber postfix/qmgr[18644]: A929010423A9: from=<>,
size=8471, nrcpt=1 (queue active)

I've got a few like this, which looks more suspicious:

Oct 10 03:31:50 carbonfiber postfix/cleanup[3313]: 6B3BD104243D:
message-id=<20101010103150.6b3bd1042...@myhost.mydomain.com
Oct 10 03:31:50 carbonfiber postfix/bounce[3825]: 2164C10423F3: sender
non-delivery notification: 6B3BD104243D
Oct 10 03:31:50 carbonfiber postfix/qmgr[18644]: 6B3BD104243D: from=<>,
size=3876, nrcpt=1 (queue active)
Oct 10 03:31:51 carbonfiber postfix/smtp[3811]: certificate verification
failed for mx1.utc.iphmx.com[68.232.135.212]:25: self-signed certificate
Oct 10 03:31:51 carbonfiber postfix/smtp[3811]: 6B3BD104243D:
to=<0...@otis.com>, relay=mx1.utc.iphmx.com[68.232.135.212]:25, delay=0.87,
delays=0.03/0/0.71/0.13, dsn=2.0.0, status=sent (250 ok:  Message 65223
accepted) 
Oct 10 03:31:51 carbonfiber postfix/qmgr[18644]: 6B3BD104243D: removed

Also, should I be looking for any time that "postfix/bounce" appears in my
maillog? There seem to be a few of those, too, such as:

Oct 15 11:39:14 carbonfiber postfix/smtpd[21509]: 1E9E510423D3:
client=unknown[190.80.137.175]
Oct 15 11:39:14 carbonfiber postfix/cleanup[22200]: 1E9E510423D3:
message-id=<000d01cb6c98$3284e4b0$6400a...@idealistically7>
Oct 15 11:39:14 carbonfiber opendkim[5750]: 1E9E510423D3: [190.80.137.175]
[190.80.137.175] not internal
Oct 15 11:39:14 carbonfiber opendkim[5750]: 1E9E510423D3: not authenticated
Oct 15 11:39:14 carbonfiber opendkim[5750]: 1E9E510423D3: no signature data
Oct 15 11:39:14 carbonfiber postfix/qmgr[18644]: 1E9E510423D3:
from=, size=854, nrcpt=1 (queue active)
Oct 15 11:39:20 carbonfiber postfix/smtp[22201]: 1E9E510423D3:
to=, orig_to=,
relay=mx.east.cox.net[68.1.17.3]:25, delay=6.5, delays=0.81/0/5.3/0.34,
dsn=5.2.0, status=bounced (host mx.east.cox.net[68.1.17.3] said: 552 5.2.0
K6fE1f05J30Aua0016fLJA Message Rejected - Error Code: URLBL011 - Refer to
Error Codes section at
http://postmaster.cox.net/confluence/display/postmaster/Error+Codes for more
information. (in reply to end of DATA command))
Oct 15 11:39:20 carbonfiber postfix/bounce[22258]: 1E9E510423D3: sender
non-delivery notification: 7BC6710423FC
Oct 15 11:39:20 carbonfiber postfix/qmgr[18644]: 1E9E510423D3: removed

Sorry if I'm coming off as a n00b, but I'm still learning. :)

Thanks in advance for any guidance,

Steve


-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Friday, October 15, 2010 8:28 AM
To: Postfix users
Subject: Re: Fighting Backscatter

Steve Jenkins:
> I've read through the readme at:
> 
> http://www.postfix.org/BACKSCATTER_README.html
> 
> and thought I was doing everything right. but my personal mail server is
> still getting listed at Backscatterer.org. :(

Have you looked in your logfile for mail from <>, that is sent by
your Postfix machine?

Wietse

RE: Fighting Backscatter

[Steve Jenkins]

Hi, Wietse. Thanks for the speedy reply. I'm a big fan of Postfix, so first
of all, thank you for developing such a great product. I cringe thinking
about the days when I used to have to run Sendmail (shudder).

Ok... so let me see if I understand what is happening on my server.

1) SpamCo forges a message from innoc...@victim.com and sends it to
mya...@familyname.com

2) My server (familyname.com) accepts the message because mya...@familyname
is a valid recipient that appears in my virtual aliases file, then forwards
the message (based on the info in that virtual aliases file) to my aunt's
actual email address of auntiemildredloveskitt...@cox.net

3) Cox.net rejects the mail because it's SPAM and sends it back to the
spoofed "sender": innoc...@victim.com, basically saying "your message to
mya...@familyname.com was rejected because of xyz reason"

4) innoc...@victim.com's mail server receives the rejection from the ISP and
then reports the IP of familyname.com as a backscatterer.

Question 1) Is that an accurate representation of what is probably
happening?

Question 2) Isn't the ISP in step 3 truly responsible for the backscatter? I
was an innocent "middleman" and my Postfix did what it was supposed to do:
forwarded a message sent to a valid address on my system.

Question 3) Why can't my Aunt rely on her ISP's SPAM filters in step 3? I'm
just trying to be a friendly family member and provide everyone a
"permanent" email address of theirn...@familyname.com. I don't want to
administer a SPAM filter on my server and deal with everyone's complaints
about false positives. I want to set up my mail server so that it rejects
the most obviously misconfigured senders, but I'd prefer to leave SPAM
filtering up to the individual family members. My dad, for example, has his
alias forwarded to a gmail account, which is a great spam filter for his
needs.

Question 4) Any suggestions for an elegant solution? I want to be a
responsible mail server admin, but I also don't want to simply tell everyone
in my family that I can no longer forward their @familyname.com mail to the
accounts of their choice - many of them have relied on these email addresses
since I got the domain in 1996.

Thanks in advance,

Steve


-Original Message-
From: Wietse Venema [mailto:wie...@porcupine.org] 
Sent: Friday, October 15, 2010 12:13 PM
To: Steve Jenkins
Cc: Postfix users
Subject: Re: Fighting Backscatter

Steve Jenkins:
> There are a few entries in there that seem to match the "<>" bill, but I'm
> not sure I'm understanding what they're saying, or even what I should be
> looking for to troubleshoot.
> 
> For some background, this is my personal server that I run my family's
mail
> on. There are a few local IMAP/POP accounts for my immediate family
members
> (they are also allowed to relay mail using SMTP-AUTH), but most of the
valid
> destination addresses on this box are virtual aliases that forward
> "firstn...@familyname.com" to everyone's respective gmail, aol, cox.net
> addresses, etc.

If you forward spam, then it will be rejected, and that is when
Postfix starts sending spam back to innocent people.

Wietse

RE: Fighting Backscatter

[Steve Jenkins]

So, Cox rejects the message to me, and then I'm sending it back to an
innocent person?

SJ

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Friday, October 15, 2010 2:05 PM
To: Postfix users
Subject: Re: Fighting Backscatter

Steve Jenkins:
> Hi, Wietse. Thanks for the speedy reply. I'm a big fan of Postfix, so
first
> of all, thank you for developing such a great product. I cringe thinking
> about the days when I used to have to run Sendmail (shudder).
> 
> Ok... so let me see if I understand what is happening on my server.
> 
> 1) SpamCo forges a message from innoc...@victim.com and sends it to
> mya...@familyname.com
> 
> 2) My server (familyname.com) accepts the message because
mya...@familyname
> is a valid recipient that appears in my virtual aliases file, then
forwards
> the message (based on the info in that virtual aliases file) to my aunt's
> actual email address of auntiemildredloveskitt...@cox.net
> 
> 3) Cox.net rejects the mail because it's SPAM and sends it back to the
> spoofed "sender": innoc...@victim.com, basically saying "your message to
> mya...@familyname.com was rejected because of xyz reason"

Cox rejects the message; YOUR box sends it back to an innocent person.

Wietse

RE: Fighting Backscatter

[Steve Jenkins]

Gotit. Thanks again for helping me out. I'm still learning.

So it seems I need to figure out how to stop the backscatter process at step
6 and NOT return the bounce to the original sender.
 
I went through my log looking for an entire process like you described. I
think I found one:

Oct 18 18:22:36 carbonfiber postfix/smtpd[16152]: connect from
unknown[117.199.192.62]
Oct 18 18:22:39 carbonfiber postfix/smtpd[16152]: 7B3CC1042340:
client=unknown[117.199.192.62]
Oct 18 18:22:41 carbonfiber postfix/cleanup[16169]: 7B3CC1042340:
message-id=<000701cb6f2c$2b3e2bd0$42c5b...@procom.ca>
Oct 18 18:22:41 carbonfiber postfix/qmgr[18644]: 7B3CC1042340:
from=, size=969, nrcpt=1 (queue active)
Oct 18 18:22:42 carbonfiber postfix/smtpd[16152]: disconnect from
unknown[117.199.192.62]
Oct 18 18:22:42 carbonfiber postfix/smtp[16187]: 7B3CC1042340:
to=, orig_to=,
relay=mx.east.cox.net[68.1.17.3]:25, delay=4.5, delays=2.9/0/1.3/0.33,
dsn=5.2.0, status=bounced (host mx.east.cox.net[68.1.17.3] said: 552 5.2.0
LRNh1f01430Aua001RNica Message Rejected - Error Code: URLBL011 - Refer to
Error Codes section at
http://postmaster.cox.net/confluence/display/postmaster/Error+Codes for more
information. (in reply to end of DATA command))
Oct 18 18:22:42 carbonfiber postfix/cleanup[16195]: EC17E10423F3:
message-id=<20101019012242.ec17e1042...@carbonfiber.familyname.com>
Oct 18 18:22:42 carbonfiber postfix/bounce[16214]: 7B3CC1042340: sender
non-delivery notification: EC17E10423F3
Oct 18 18:22:42 carbonfiber postfix/qmgr[18644]: EC17E10423F3: from=<>,
size=3479, nrcpt=1 (queue active)
Oct 18 18:22:42 carbonfiber postfix/qmgr[18644]: 7B3CC1042340: removed
Oct 18 18:22:43 carbonfiber postfix/smtp[16185]: certificate verification
failed for procommail.procom.ca[216.138.225.134]:25: untrusted issuer
/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
Oct 18 18:22:43 carbonfiber postfix/smtp[16185]: EC17E10423F3:
to=,
relay=procommail.procom.ca[216.138.225.134]:25, delay=1,
delays=0.03/0/0.68/0.3, dsn=5.0.0, status=bounced (host
procommail.procom.ca[216.138.225.134] said: 550 No such user
(genevievegentr...@procom.ca) (in reply to RCPT TO command))
Oct 18 18:22:44 carbonfiber postfix/qmgr[18644]: EC17E10423F3: removed

The instructions at http://www.postfix.org/BACKSCATTER_README.html seem to
only address what to do if MY server is the one being forged. In the above
example, it seems that procom.ca is being forged. How should I configure my
Postfix installation so that I'm not sending the spam back to the innocent
sender? Let me know if you need me to post my postconf -n again.

Thanks,

Steve

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Monday, October 18, 2010 12:07 PM
To: Postfix users
Subject: Re: Fighting Backscatter

> 1) SpamCo forges a message from innoc...@victim.com and sends it to
> mya...@familyname.com
> 
> 2) My server (familyname.com) accepts the message because
> mya...@familyname is a valid recipient that appears in my virtual
> aliases file, then forwards the message (based on the info in that
> virtual aliases file) to my aunt's actual email address of
> auntiemildredloveskitt...@cox.net

3) YOUR SERVER tries to forward the SPAM to Cox.  

4) Cox rejects the SPAM. 

5) The SPAM is still on YOUR SERVER.

6) YOUR SERVER "returns" the SPAM to an innocent person.

7) YOUR SERVER is blacklisted because it sends backscatter.

Wietse

RE: Fighting Backscatter

[Steve Jenkins]

I will gladly solve the RIGHT problem. The fact that I'm here looking for
guidance should demonstrate that I'm looking to do exactly that.
Unfortunately, I can't simply put "DO NOT forward SPAM" in my main.cf and
have it work. ;) After reading through all the docs and various blog and
forum posts, and making my best efforts at incorporating what I've learned
into my configuration, it seems I'm still causing backscatter. That's
exactly why I'm posting on Postfix-users - because I need a little more
guidance than just "RTFM." :) So if anyone can help me with some SPECIFIC
steps to take, I'd be very appreciative.

I posted it initially, but here again is my postconf -n output:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:20209
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_milters = inet:localhost:20209
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination, reject_unknown_recipient_domain,
reject_unknown_sender_domain, reject_non_fqdn_recipient,
reject_non_fqdn_sender, reject_invalid_hostname, permit_mynetworks, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated,  permit_mynetworks,
reject_unknown_sender_domain
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = familyname.com
virtual_alias_maps = hash:/etc/postfix/virtual

I've been experimenting with various smtp recipient and sender restrictions,
but clearly haven't got the right mix yet. Any specific guidance there, or
anywhere else, is much appreciated.

Thanks,

SteveJ

-Original Message-
From: Wietse Venema [mailto:wie...@porcupine.org] 
Sent: Tuesday, October 19, 2010 5:16 AM
To: Steve Jenkins
Cc: Postfix users
Subject: Re: Fighting Backscatter

Steve Jenkins:
> Gotit. Thanks again for helping me out. I'm still learning.
> 
> So it seems I need to figure out how to stop the backscatter process at
step
> 6 and NOT return the bounce to the original sender.

No. Solve the RIGHT problem. DO NOT forward SPAM.

Wietse

RE: Fighting Backscatter

[Steve Jenkins]

Thanks for the reply. 

Forcing everyone to just check their mail with POP/IMAP was actually what I
was going to resort to if I couldn't figure out a way to do this with just
Postfix config settings. It seems that unless I want to manage a SPAM filter
on my server for everyone (which is not something I want to do) then that's
what I'm going to have to do.

So unless anyone sees anything glaring that I'm doing wrong from my postconf
-n, that's probably what I'm going to end up doing.

Thanks,

SteveJ

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of pf at alt-ctrl-del.org
Sent: Tuesday, October 19, 2010 8:04 AM
To: postfix-users@postfix.org
Subject: Re: Fighting Backscatter


> On 2010-10-18 9:58 PM, Steve Jenkins wrote:
>> The instructions at http://www.postfix.org/BACKSCATTER_README.html 
>> seem to only address what to do if MY server is the one being
>> forged. In the above example, it seems that procom.ca is being
>> forged. How should I configure my Postfix installation so that I'm
>> not sending the spam back to the innocent sender? Let me know if you
>> need me to post my postconf -n again.
> 
"Charles Marcus" October 19, 2010 7:38 AM:
> As has been told to you more than once, the correct solution is simple...
> 
> 1. Stop forwarding spam, or
> 
> 2. Do not forward *any* emails, period.
> 

The OP can actually do #2. He probably doesn't need to forward any email at
all.
gmail, yahoo, comcast all support POP3'ing third party email accounts,
straight to the mailbox.

Automatic POP3 retrieval...
No forwarding, no bounces.

But I'm not sure about cox support for auto POP3 retrieval.

RE: Fighting Backscatter

[Steve Jenkins]

THANK YOU Jeroen. J I really appreciate you taking the time to help me with
some specific steps I can try.

 

Here's the updated output of my postconf -n:

 

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

broken_sasl_auth_clients = yes

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

data_directory = /var/lib/postfix

debug_peer_level = 2

home_mailbox = Maildir/

html_directory = no

mailq_path = /usr/bin/mailq.postfix

manpage_directory = /usr/share/man

milter_default_action = accept

milter_protocol = 2

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain

mynetworks = 127.0.0.0/8

myorigin = $mydomain

newaliases_path = /usr/bin/newaliases.postfix

non_smtpd_milters = inet:localhost:20209

sendmail_path = /usr/sbin/sendmail.postfix

setgid_group = postdrop

smtp_tls_note_starttls_offer = yes

smtp_use_tls = yes

smtpd_data_restrictions = reject_unauth_pipelining, permit

smtpd_milters = inet:localhost:20209

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination,  reject_unknown_reverse_client_hostname,
warn_if_reject reject_non_fqdn_helo_hostname,   warn_if_reject
reject_invalid_helo_hostname,  warn_if_reject reject_unknown_helo_hostname,
reject_unauth_pipelining,   reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_non_fqdn_recipient,
reject_unknown_recipient_domain,reject_invalid_hostname,
permit

smtpd_sasl_auth_enable = yes

smtpd_sasl_authenticated_header = yes

smtpd_sasl_local_domain =

smtpd_sasl_security_options = noanonymous

smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem

smtpd_tls_auth_only = no

smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt

smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_session_cache_timeout = 3600s

smtpd_use_tls = yes

tls_random_source = dev:/dev/urandom

unknown_local_recipient_reject_code = 550

virtual_alias_domains = familyname.com

virtual_alias_maps = hash:/etc/postfix/virtual

 

The /etc/postfix/virtual is set up as follows. Every line in there is either
a local POP account or the destination forwarding address. I don't use any
catch-alls, and prefer that my server reject unknown local recipients (or in
this case, I should probably say "local").

 

Familyname.com #Family Domain for Mail

st...@familyname.comsteve

sis...@familyname.comsister

a...@familyname.com auntsaddr...@cox.net

d...@familyname.com   dadsaddr...@gmail.com

 

Like you, I'm also running a pre-2.8 build (2.6.5). I hadn't heard of
postscreen until just now, but I'll check it out.

 

Would you mind sharing (anonymized if you wish) some examples of
permutations of your IP and hostname(s) to reject from your helo_access
file? What types of permutations are classically used by spammers that I can
safely block without rejecting legitimate mail?

 

Thanks again,

 

Steve

 

 

From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen Geilman
Sent: Tuesday, October 19, 2010 7:10 PM
To: postfix-users@postfix.org
Subject: Re: Fighting Backscatter

 

On 10/20/2010 02:52 AM, Steve Jenkins wrote: 

I will gladly solve the RIGHT problem. The fact that I'm here looking for
guidance should demonstrate that I'm looking to do exactly that.
Unfortunately, I can't simply put "DO NOT forward SPAM" in my main.cf and
have it work. ;) After reading through all the docs and various blog and
forum posts, and making my best efforts at incorporating what I've learned
into my configuration, it seems I'm still causing backscatter.


Don't accept mail you cannot deliver. Really, that's Numero Uno.
Proper sender and recipient verification - insofar as is feasible for your
site - goes a long way to prevent that from happening.




 That's exactly why I'm posting on Postfix-users - because I need a little
more
guidance than just "RTFM." :) So if anyone can help me with some SPECIFIC
steps to take, I'd be very appreciative.
 
I posted it initially, but here again is my postconf -n output:
 
  





smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination, reject_unknown_recipient_domain,
reject_unknown_sender_domain, reject_non_fqdn_recipient,
reject_non_fqdn_sender, reject_invalid_hostname, permit_mynetworks, permit
  


You're missing some of the better spam prevention methods here, such as
decent HELO checks, and an RBL or two.

I'd suggest at least adding reject_unknown_reverse_client_hostname in there,
as well as (testing out) reject_[invalid|unknown|non_fqdn]_helo_hostname.

My personal server uses:

smtpd_recipient_restrictions =  pe

RE: Fighting Backscatter

[Steve Jenkins]

Hi, Terry. Again, very helpful advice presented in a way I understand. :)
Thank you.

Based on Jeroen's advice, I've modified my main.cf file to restrict much
more of the undeliverable mail on the way IN. Just from watching my logfile
over the past few minutes, I'm seeing a LOT more rejections for "Domain not
found" and "cannot find your reverse hostname" as well as warnings for
"address not listed for" and "Helo command rejected: need fully-qualified
hostname." That's awesome! I'm assuming that after watching these warnings
for a while and being satisfied that these warnings are appearing only for
SPAM that I can turn off the warning and simply reject. What should I use as
a good indicator for when it's time to do that?

Like you, I also tend to be more practical than pragmatic, so even if it
causes a few sighs and finger wags, I'm open to quietly sinking mail that I
can't deliver. Any pointers on exactly how to do that?

Thanks again,

Steve

-Original Message-
From: Terry Gilsenan [mailto:terry.gilse...@interoil.com] 
Sent: Tuesday, October 19, 2010 7:27 PM
To: Steve Jenkins; Postfix users
Subject: RE: Fighting Backscatter

From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] On
Behalf Of Steve Jenkins [st...@stevejenkins.com]
Sent: Wednesday, 20 October 2010 10:52 AM
To: Postfix users
Subject: RE: Fighting Backscatter

>I will gladly solve the RIGHT problem. The fact that I'm here looking for
>guidance should demonstrate that I'm looking to do exactly that.
>Unfortunately, I can't simply put "DO NOT forward SPAM" in my main.cf and
>have it work. ;) After reading through all the docs and various blog and
>forum posts, and making my best efforts at incorporating what I've learned
>into my configuration, it seems I'm still causing backscatter. That's
>exactly why I'm posting on Postfix-users - because I need a little more
>guidance than just "RTFM." :) So if anyone can help me with some SPECIFIC
>steps to take, I'd be very appreciative.

Steve, Backscatter is caused by a configuration that accepts all email and
then bounces email it cannot deliver. This is where your configuration is
faulty.

Only accept email that you can deliver! If you cannot deliver email for any
reason you should be determining this within the SMTP transaction phase and
responding to the sending MTA with the appropriate rejection code.

Any email that you do actually accept and for which your server tells the
sending MTA "OK", you either need to deliver or if your filters are setup
appropriately, quietly sink. (purists will say this should never happen, but
pragmatists reallize that some content inspection testing cannot be done
until the email has been fully rec'd)

If you have this sorted out then your backscatter problems will go away.

Rule of thumb: Start with a config that accepts nothing, then add exceptions
for things that you want to accept email for, and nothing else.

RE: Fighting Backscatter

[Steve Jenkins]

Well, let's say I can provide you with some pointers.
That doesn't absolve you of the responsibility to study the documentation
thoroughly.



Thank you nonetheless. I was starting to get the impression that doing
anything other than telling people to read the documentation was verboten.
;) I'm not looking to just blindly type in config settings. I really want to
understand what it is I should be doing and then do it properly. 

 

What are all these milters doing ?
Do you *know* ?
How can you use the same service for both smtp and non-smtp milters ? 
Presumably, they don't take the same input format.



Those lines are in my main.cf for OpenDKIM (opendkim.org). I don't reject
incoming mail (yet) if it fails DKIM authentication, but I do sign all my
personal outgoing mail sent from this server. I'm not sure how to answer
"How can you use the same service for both smtp and non-smtp milters ?" but
I'll look into confirming whether that's set up properly.

 

Still missing a good RBL check; check out zen (www.spamhaus.org/zen)



I've added "reject_rbl_client zen.spamhaus.org" to my
smtpd_recipient_restrictions as the second-to-last value, right before
"permit."


No, since these are virtual aliases, postfix will reject any *virtual*
recipients that don't appear here. It makes no judgement on the RHS of the
aliases.



Yes. I want Postfix to reject any virtual recipients that don't appear here.
I was trying to be witty by saying they aren't "local" recipients (with
local in quotes) since I'm forwarding their mail somewhere else. But yes, I
understand that Postfix will reject if their address doesn't appear in this
file.

 

Thx,

 

SJ 

RE: Fighting Backscatter

[Steve Jenkins]

Jeroen said:

My personal server uses:

smtpd_recipient_restrictions =  permit_mynetworks,
 
permit_sasl_authenticated,
 
reject_unauth_destination,
 
reject_unknown_reverse_client_hostname,
warn_if_reject
reject_non_fqdn_helo_hostname,
warn_if_reject
reject_invalid_helo_hostname,
warn_if_reject
reject_unknown_helo_hostname,
 
reject_unauth_pipelining,
 
reject_non_fqdn_sender,
 
reject_unknown_sender_domain,
 
reject_non_fqdn_recipient,
 
reject_unknown_recipient_domain,
check_helo_access
hash:/etc/postfix/helo_access,
permit

Out of curiosity, does anyone see any drawbacks (such as possibly rejecting
valid mail) to adding "reject_invalid_hostname" to those
smtpd_recipient_restrictions? Also, some other reading I've been doing
suggest adding "smtpd_helo_required = yes" to the main.cf file. Is that
helpful/necessary, or would I already be covered there with the
"reject_invalid_helo_hostname" in the above recipient restrictions?

 

I've also read another suggestion to add "smtpd_sender_restrictions =
reject_unknown_address" to reject mail that doesn't have any return address.
I've moved all my checks to the recipient restrictions, so if I added this,
it would be my only sender restriction. Am I wrong in thinking this check is
superfluous because of the "reject_non_fqdn_sender" already in the above
recipient restrictions?

 

It's slowly starting to make more sense. Thanks again to those who have
given me helpful nudges.

 

Thanks,

 

Steve

RE: Fighting Backscatter

[Steve Jenkins]

Stan Hoeppner said:
>This will probably be a big help to Steve.

Thanks, Stan. That fqrdns.pcre file rocks. Is that something you created?
May I share the link with others?

I had already added the spamhaus DBL checks (after Jeroen nudged me toward
their Zen IP blocklist), but Surriel PSBL is new to me and I'll check that
out now. I also just Googled postgrey and will check that out as well.

Thanks again - your post WAS a big help. I appreciate it.

SJ

RE: Fighting Backscatter

[Steve Jenkins]

Jeroen Geilman said:


Make sure you understand the difference between
smtpd_reject_unknown_helo_hostname and
smtpd_reject_unknown_[reverse_]client_hostname.



Ok - here's what I understand them each to be:

-reject_unknown_helo_hostname will reject a request if the remote
mail server doesn't have an A or MX record

-reject_unknown_client_hostname will reject if a) the remote server
fails a reverse lookup (IP points to name), b) fails a forward lookup (name
resolves to IP), or c) if the published DNS settings for the hostname state
that the IP for the hostname is different than what the remote server is
reporting it to be.

-reject_unknown_reverse_client_hostname is less restrictive and will
reject only if the remove server fails a reverse lookup.

 


No, you definitely want that set to "yes". Not requiring HELO means the helo
tests are skipped altogether as there's nothing to match them against.



Gotit. I've now got "smtpd_helo_required = yes" in my config.

 

So here are my current "spam fighting" settings, based on the input from
this list:

 

smtpd_helo_required = yes

disable_vrfy_command = yes

smtpd_recipient_restrictions =

permit_sasl_authenticated,

permit_mynetworks,

reject_unauth_destination,

reject_unknown_reverse_client_hostname,

warn_if_reject reject_non_fqdn_helo_hostname,

warn_if_reject reject_invalid_helo_hostname,

warn_if_reject reject_unknown_helo_hostname,

reject_non_fqdn_sender,

reject_unknown_sender_domain,

reject_non_fqdn_recipient,

reject_unknown_recipient_domain,

check_helo_access hash:/etc/postfix/helo_access,

check_client_access pcre:/etc/postfix/fqrdns.pcre,

reject_rbl_client zen.spamhaus.org,

reject_rbl_client psbl.surriel.com,

reject_rhsbl_client dbl.spamhaus.org,

reject_rhsbl_sender dbl.spamhaus.org,

reject_rhsbl_helo dbl.spamhaus.org,

permit

 

smtpd_data_restrictions =

reject_unauth_pipelining,

permit

 

I noticed Jeroen's smtpd_recipient_restrictions included
reject_unauth_pipelining, but from what I can tell in the docs I'm supposed
to put it in smtpd_data_restrictions. Am I misunderstanding that?

 

BIG thanks also to everyone who has given me friendly nudges in the right
direction. My server now rejects at least 10-20x what it was before, and my
client-side SPAM filter isn't getting that much to chew on any more (apart
from properly configured SPAM ;) ).

 

Thanks,

 

Steve

com.com weirdness and relay_domains warning

[Steve Jenkins]

My personal server is happily managing virtual mail domains without any
trouble, but I'm now trying to troubleshoot a work server that is being a
little more stubborn. It has one primary domain (booyahmedia) and two
virtual domains (teamsites.com and virtualvow.com).

I've set up a local test account on the server called "testaccount." Mail is
delivered just fine to that account on the primary domain:

Oct 22 10:02:37 booyahmedia postfix/smtpd[10240]: connect from
mail-yx0-f171.google.com[209.85.213.171]
Oct 22 10:02:43 booyahmedia postfix/smtpd[10240]: 3574630437:
client=mail-yx0-f171.google.com[209.85.213.171]
Oct 22 10:02:43 booyahmedia postfix/cleanup[10256]: 3574630437:
message-id=
Oct 22 10:02:43 booyahmedia postfix/qmgr[8636]: 3574630437:
from=, size=1639, nrcpt=1 (queue active)
Oct 22 10:02:43 booyahmedia postfix/local[10257]: 3574630437:
to=, relay=local, delay=5.8,
delays=5.8/0.02/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox)
Oct 22 10:02:43 booyahmedia postfix/qmgr[8636]: 3574630437: removed

Next, I set up a test virtual alias on each of the virtual domains. The
/etc/postfix/virtual file is:

teamsites.com   #Team Sites
testing...@teamsites.comtestaccount

virtualvow.com  #Virtual Vow
testing...@virtualvow.com   testaccount  

If I send a test email from Gmail to an address on either of the virtual
domains, I get some strange entries in the log:

Oct 22 10:04:32 booyahmedia postfix/smtpd[10507]: connect from
mail-yw0-f43.google.com[209.85.213.43]
Oct 22 10:04:32 booyahmedia postfix/trivial-rewrite[10510]: warning: do not
list domain teamsites.com in BOTH virtual_alias_domains and relay_domains
Oct 22 10:04:38 booyahmedia postfix/smtpd[10507]: C320B3041C:
client=mail-yw0-f43.google.com[209.85.213.43]
Oct 22 10:04:38 booyahmedia postfix/cleanup[10524]: C320B3041C:
message-id=
Oct 22 10:04:38 booyahmedia postfix/qmgr[10468]: C320B3041C:
from=, size=1631, nrcpt=1 (queue active)
Oct 22 10:05:08 booyahmedia postfix/smtp[10525]: connect to
com.com[216.239.113.101]: Connection timed out (port 25)
Oct 22 10:05:09 booyahmedia postfix/smtpd[10507]: disconnect from
mail-yw0-f43.google.com[209.85.213.43]
Oct 22 10:05:38 booyahmedia postfix/smtp[10525]: connect to
com.com[216.239.122.102]: Connection timed out (port 25)
Oct 22 10:05:38 booyahmedia postfix/smtp[10525]: C320B3041C:
to=, orig_to=, relay=none,
delay=66, delays=6.1/0.02/60/0, dsn=4.4.1, status=deferred (connect to
com.com[216.239.122.102]: Connection timed out)

First, I'm trying to figure out why it's giving me that trivial-rewrite
warning because teamsites.com appears only in virtual_alias_domains in
main.cf. The only references I can find with Google seem to address
subdomains of the primary domain, but that's not the case here.

Second, it seems that Postfix thinks that the local hostname or domain is
"com.com" instead of "booyahmedia.com" because it's trying to deliver the
message to testacco...@com.com instead of testacco...@booyahmedia.com. That
one's really got me scratching my head.

I can fudge it so that messages will get delivered to the local
"testaccount" account by editing /etc/postfix/virtual to read:

teamsites.com   #Team Sites
testing...@teamsites.comtestacco...@booyahmedia.com

That at least delivers mail sent to the virtual alias to the proper local
account, but I still get the "do not list teamsites.com in BOTH." warning in
the log. In any case, I don't want to fudge it anyway - I'd rather it work
correctly.

I've checked through all the network settings I can think of (/etc/hosts
/etc/resolv.conf) to see why Postfix might be thinking that com.com is the
localhost, 

Here are some outputs from the shell to help give some context and aid
troubleshooting:

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
html_directory = no
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_data_restrictions = reject_unauth_pipelining,permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,reject_unauth_destination,
reject_unknown_reverse_client_hostname,warn_if_reject
reject_non_fqdn_helo_hostname,warn_if_reject
reject_invalid_helo_hostname,warn_if_reject
reject_unknown_helo_hostname,reject_non_fqdn_sender,
reject_unknown_sender_domain,reject_non_fqdn_recipient,
reject_unknown_recip

RE: com.com weirdness and relay_domains warning

[Steve Jenkins]

On October 22, 2010 9:38 AM I wrote:

---
First, I'm trying to figure out why it's giving me that trivial-rewrite
warning because teamsites.com appears only in virtual_alias_domains in
main.cf. The only references I can find with Google seem to address
subdomains of the primary domain, but that's not the case here.

Second, it seems that Postfix thinks that the local hostname or domain is
"com.com" instead of "booyahmedia.com" because it's trying to deliver the
message to testacco...@com.com instead of testacco...@booyahmedia.com. That
one's really got me scratching my head.
---

Ok -I think I just figured it out and wanted to post the solution here in
case it helps someone else. Google didn't find the answer - it was there in
the main.cf comments:

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.

So I decided just to "hard-code" the following in my main.cf:

mydomain = booyahmedia.com
myhostname = booyahmedia.com

and leave myorigin set as:

myorigin = $mydomain

That solved BOTH problems. No more trivial-rewrite warning (although I'm not
sure WHY this solved that one), and Postfix now knows the correct domain and
hostname of the server (that one I DO understand why this fix works).

Best,

Steve

virtual_mailbox_domains Warning

[Steve Jenkins]

Hello, Postfix Users.

Our ultimate goal is to use Postfix to send mail to a large opt-in mailing
list "From: nore...@foobar.com" using a "Return-path:
addr...@bounce.foobar.com" where "address" is unique to each recipient
(a...@bounce.foobar.com, 1...@bounce.foobar.com, etc.) for bounce-processing
purposes. We want to do all this on a single server (named foo.foobar.com)
that acts as the sole SMTP server for the foobar.com domain and a couple
additional virtual alias domains (anotherdomain.com and thirddomain.com).

I'm trying to set up bounce.foobar.com to allow virtual mailboxes as per:
http://www.postfix.org/VIRTUAL_README.html and then set up a catchall
address on that virtual domain so that everything sent to @bounce.foobar.com
(except mail sent to postmaster or abuse) will be written to a single file
that we can process for bounces.

My /etc/postfix/vmailbox:
@bounce.foobar.com bounce.foobar.com/catchall

My /etc/postfix/virtual:
ab...@bounce.foobar.com   steve
postmas...@bounce.foobar.com   steve
anotherdomain.com  #Another Domain
d...@anotherdomain.com steve
thirddomain.com   #A Third Domain
d...@thirddomain.com steve

The virtual_* lines from main.cf (my entire postconf -n is included at the
end of this message):

# Virtual Domain Hosting
virtual_alias_domains = anotherdomain.com, thirddomain.com
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = bounce.foobar.com
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

The good news is that everything seems to be working like we want it to.
Mail to postmas...@bounce.foobar.com is delivered to the correct local
recipient (steve). Main sent to 123...@bounce.foobar.com gets written to
/var/mail/vhosts/bounce.foobar.com/catchall. But we're getting a warning in
our maillog that says:

Dec 27 18:13:43 foo postfix/trivial-rewrite[25643]: warning: do not list
domain bounce.foobar.com in BOTH virtual_mailbox_domains and relay_domains

My guess is that since I don't have a relay_domains explicitly set, the
default setting is somehow including bounce.foobar.com and generating the
warning. Do I need to explicitly set relay_domains to something other than
$mydestination to make this warning go away?

Thanks in advance,

Steve

postconf -n output:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
inet_interfaces = all
mailq_path = /usr/bin/mailq.postfix
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain
mydomain = foobar.com
myhostname = foo.foobar.com
mynetworks = 127.0.0.0/8, 123.123.123.0/24
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:20209
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_helo_required = yes
smtpd_milters = inet:localhost:20209
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,reject_unauth_destination,
reject_unknown_reverse_client_hostname,warn_if_reject
reject_non_fqdn_helo_hostname,warn_if_reject
reject_invalid_helo_hostname,warn_if_reject
reject_unknown_helo_hostname,reject_unauth_pipelining,
reject_non_fqdn_sender,reject_unknown_sender_domain,
reject_non_fqdn_recipient,reject_unknown_recipient_domain,
check_helo_access hash:/etc/postfix/helo_access,check_client_access
pcre:/etc/postfix/fqrdns.pcre,  reject_rbl_client
b.barracudacentral.org,reject_rbl_client zen.spamhaus.org,
reject_rbl_client psbl.surriel.com,reject_rhsbl_client
dbl.spamhaus.org,reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = anotherdomain.com, thirddomain.com
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:5000

RE: virtual_mailbox_domains Warning

[Steve Jenkins]

/dev/rob0 said:

>If you don't plan to use relay_domains, indeed, unset it:
>   relay_domains =
>The $mydestination default setting was for backward compatibility. 
>Combined with the default of parent_domain_matches_subdomains, this 
>can cause problems, because all subdomains of mydestination domains 
>are now relay_domains.

Thanks for the quick reply, /dev/rob0. I was just experimenting with setting

parent_domain_matches_subdomains =

just before your email arrived and that did shut off the warning. I'll try
setting relay_domains as you suggest, too.

For Wietse: There is no mention of parent_domain_matches_subdomains in
http://www.postfix.org/VIRTUAL_README.html. Perhaps it would be a useful
addition to the documentation to mention it there?

Thanks again,

SteveJ

Bounce Processing "Best Practices?"

[Steve Jenkins]

Happy New Year to you all.

This is a "best practices" question for other Postfix users who may be using
Postfix to send email to large opt-in mailing lists.

We have a subscriber list of 1MM+ registered members of a popular video game
website. The vast majority of them are also opted in for our monthly
newsletter (a separate checkbox during the registration process), but we
haven't sent out a newsletter in a few years. We've only been sending
transactional email to the "active" website members, as well as a few
thousand daily "new content" alerts to the users that have asked for them in
their notification options.

In getting our newsletter campaigns ready to send, we believe we've done
everything all the big ESPs ask: a relatively up-to-date version of Postfix
(2.3.3), a dedicated IP with a good reputation and no blacklists, valid SPF
record, valid DKIM signing, and we've signed up for every FBL we could find.

Before sending a newsletter to that large of a group, we decided to first
send out an account confirmation message to all our opted-in subscribers
which includes their name, login information, subscription date, and links
to unsubscribe and/or otherwise manage their delivery settings. The two
goals of this message were to a) do some much-needed housekeeping on our
list to clean out old addresses that bounce, and b) verify that the
addresses which don't bounce still want to hear from us and give them a
chance to unsubscribe if they don't.

We used Postfix to set up a number of virtual mailboxes for the FBL accounts
and one to receive unsubscribe requests from clients that support the
List-Unsubscribe: header. We also used Postfix to set up a virtual mail host
with a catchall address @bounce.ourdomain.com using virtual_mailbox_maps =
hash:/etc/postfix/vmailbox. We then sent out the account confirmation
messages using a custom Return-Path: for each message that is a combination
of the subscriber's user ID, then a plus sign as a delimiter, then an MD5
string (1234567+4s6d5f4a9s8d7f6a...@bounce.ourdomain.com). This is different
than the approach we've been taking with our transactional and alerts mails,
where we've been using a static Return-Path: to a virtual mailbox file
@ourdomain.com and then grep it nightly and unsubscribe any bounces we find
in there.

Sending is happening right now, and so far, everything seems to be working
nicely (we've only got a couple hundred thousand messages to go). Watching
the maillog in real-time, the ESPs are accepting our mails for delivery, the
FBL virtual mailboxes are receiving a moderate number of messages, the
List-Unsubscribe virtual mailbox is receiving a few, and the bounce catchall
is receiving A LOT of bounces. As expected, the older accounts are bouncing
the most.

So with all that explained, I have few questions:

1) What's the optimal way for us to process the bounces? Our plan is to grep
the catchall file and unsubscribe based on the user ID in the original
Return-Path. But will that get them ALL?

2) Should we also be grepping our /var/log/maillog* files and looking for
5xx errors? Or will those all end up in the catchall eventually, after
Postfix gives up trying to deliver? Should we be looking in our logs for
anything else to unsubscribe users?

3) Would we be better off using VERP instead of our custom Return-Path? I've
read through http://www.postfix.org/VERP_README.html but can't tell if that
gives us any advantage over the approach we're using.

4) We want to be good netizens and responsible senders, so can anyone see
any additional steps (general or specific) that we're NOT doing but should
be?

Thanks and Happy New Year,

Steve

smtp_fallback_relay and Sender Reputation

[Steve Jenkins]

We're exploring the possibility of using smtp_fallback_relay as a way to
offload re-delivery attempts of deferred mails when we send our weekly
newsletter to 700K+ recipients.

>From the docs at http://www.postfix.org/postconf.5.html#smtp_fallback_relay,
here's how I understand this would work:

1) mailer.sendingdomain.com sends the original message. Let's assume each
message has a Return-Path of "variableaddr...@bounce.sendingdomain.com" and
that bounce.sendingdomain.com is a virtual mail host of
mailer.sendingdomain.com with a catchall account to get the bounces (this is
how we're currently set up).

2) On the first delivery attempt, smtp.receivingdomain.com replies with a
4xx message saying "I can't deliver this right now, but try again later"

3) fallbackmailer.sendingdomain.com is set up as the smtp_fallback_relay, so
it handles subsequent re-delivery attempts, freeing up more resources on
mailer.sendingdomain.com to handle first attempts at deliveries and incoming
mail.

4) Successful re-deliveries get logged in fallback's /var/log/maillog

5) Hard bounces (whether 5xx messages from smtp.receivingdomain.com or
timeouts where fallbackmailer.sendingdomain.com gives up) get delivered to
the 
catchall on bounce.sendingdomain.com (where we can process them later).

Two questions:

1) Is that an accurate description of what would/could happen with
smtp_fallback_relay?

2) Am I accurate in assuming that smtp.receivingdomain.com will see delivery
attempts from both IP addresses for mailer.sendingdomain.com and
fallbackmailer.sendingdomain.com, and therefore I will need to manage the
Sender Reputations of both IPs, make sure they are both included in FBLs,
absent from blacklists, etc.?

3) Won't this cause an issue with DKIM validation? If the original message
was signed by mailer.sendingdomain.com, won't it fail validation on the
receiving end since the fallback relay has a different hostname? If so, any
possible solutions to this?

Thanks,

Steve

"Standard" options when compiling Postfix from source?

[Steve Jenkins]

Up to now, we've been running Postfix 2.3.3 that was installed on a number
of CentOS 5.5 production servers with a simple "yum install postfix"

We want to run an updated version, so I compiled 2.7.2 from source using the
information at http://postfix.wl0.org/en/building-rpms/

When creating the postfix.spec file, the only additional option I explicitly
added was:

export POSTFIX_PCRE=1

Everything seemed to go fine and the CentOS 5.5 test box I built and
installed it on appears to be sending test mails as expected. However, I
want to compile in the same options that are included in the "default" 2.3.3
version that we're running on our production servers.

However, I couldn't find a postconf option in the docs to show which options
were included at compile time. Is there a command that will show them, or a
list somewhere that shows which ones were included in Postfix 2.3.3
installed by yum on CentOS 5?

Thanks in advance,

Steve

RE: "Standard" options when compiling Postfix from source?

[Steve Jenkins]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Wietse Venema
> Sent: Sunday, January 09, 2011 8:03 PM
> Subject: Re: "Standard" options when compiling Postfix from source?

> Postfix from postfix.org stores the compile-time options in
> /etc/postfix/makedefs.out.  If your vendor distributes that file, look for
the
> EXPORT line. Here is an example:
> 
> EXPORT= AUXLIBS=' -L/usr/local/lib -lpcre' CCARGS=' -DHAS_PCRE -
> I/usr/local/include -DSNAPSHOT' OPT='-O' DEBUG='-g'
> 
> The AUXLIBS and CCARGS are what you would specify on the "make
> makefiles" command line.

Thanks, Wietse. The "vanilla" install of Postfix 2.3.3 on CentOS 5 via yum
does indeed include an /etc/postfix/makedefs.out file.

For the benefit of anyone else looking for this info in the archives, the
AUXLIBS and CCARGS for that CentOS version are:

AUXLIBS=' -L/usr/lib -lldap -llber -lpcre -L/usr/lib/sasl2 -lsasl2
-L/usr/kerberos/lib -lssl -lcrypto -ldl -lz  -pie -Wl,-z,relro'
CCARGS='-fPIC -DHAS_LDAP -DLDAP_DEPRECATED=1 -DHAS_PCRE -I/usr/include/pcre
-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/include/sasl -DUSE_TLS
-I/usr/kerberos/include '

The 2.3.3 makedefs.out file contains the AUXLIBS "-pie -Wl,-z,relro" and a
CCARGS of "-fPIC". Google finds lots of references to these options in
example spec files, but nothing seems to explain what they are. What are
they, and have they been deprecated in 2.7.2?

Thanks,

Steve

unknown tls_disable_workarounds value

[Steve Jenkins]

I just built and installed Postfix 2.8-RC2 using "make upgrade"
(upgraded from 2.3.3) and I'm getting the following warning in my
maillog:

postfix/smtpd[27208]: warning: unknown tls_disable_workarounds value
"CVE-2010-4180" in "CVE-2005-2969 CVE-2010-4180"

I'm able to make the error go away by adding this line to my main.cf:

tls_disable_workarounds = CVE-2005-2969

It seems something during the install apparently thought that I needed
the 2010-4180 workaround, but for some reason Postfix is unable to
find it. I'm not familiar enough with it to know if turning off the
workaround is the right thing to do, or if I should figure out how to
make that workaround "not unknown" to Postfix.

Either way, I wanted to report it here because Google returned exactly
zero results for "unknown tls_disable_workarounds value" :)

Steve

Re: Patch 2.8.0-RC[12]: was: unknown tls_disable_workarounds value

[Steve Jenkins]

On Tue, Jan 18, 2011 at 12:34 PM, Victor Duchovni
 wrote:
> Sorry, my mistake, when the OpenSSL team removes a work-around from
> SSL_OP_ALL, we should not remove its name from the list of names Postfix
> recognizes. It will do no harm.
>
> Please apply the following patch to 2.8.0-RC[12] or 2.9-2011011[67]



When attempting to apply this patch I get:

% patch -p0 

Re: Patch 2.8.0-RC[12]: was: unknown tls_disable_workarounds value

[Steve Jenkins]

On Tue, Jan 18, 2011 at 2:35 PM, Wietse Venema  wrote:
>
> The patch applies without error here. Be sure not to corrupt the
> file content with some word-wrapping program, or some DOS editor
> that appends control-z.
>
>        Wieste

Confirmed. I had initially copied and pasted it from my Gmail client
window to my Linux editor. Copying it from the message source instead
did the trick.

Will this patched version of tls_misc.c be in the final 2.8 release?

SJ

Re: Config check

[Steve Jenkins]

On Fri, Jan 21, 2011 at 6:50 PM, Walter Pinto  wrote:
> CentOS 5.5
>
> mail_version = 2.3.3

Hi Walter,

I realize that 2.3.3 is the version of Postfix that is installed by
the default CentOS repos, but as already recommended on this thread,
you may want to consider the jump to a newer version.

I recently upgraded directly from 2.3.3 to 2.8.0 on three of our
CentOS 5.5 boxes, and wrote a detailed how-to here (it's a very
painless process that takes less than 5 mins and keeps all your
existing config files intact):

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

>From the looks of your config, you'll need to modify the make
makefiles command from my how-to slightly to compile in MySQL support,
but if you have it running with 2.3.3 currently, then you probably
already know how to do that. :)

Best,

SteveJ

Multiple Milters Separator?

[Steve Jenkins]

If we're using mutliple milters (with smtpd_milters), is it
appropriate to separate them with:

a space?
smtpd_milters = inet:localhost:10035 inet:localhost:10036

a comma?
smtpd_milters = inet:localhost:10035,inet:localhost:10036

a comma and a space?
smtpd_milters = inet:localhost:10035, inet:localhost:10036

Or does it matter? They all seem to work, but I wanted to make sure
I'm doing it the "right" way for maximum compatibility with future
versions.

TIA,

SteveJ

Re: limit/tune the smtp sender dameon for specific destination domains

[Steve Jenkins]

On Sat, Jan 29, 2011 at 1:23 PM, mouss  wrote:
> Le 29/01/2011 22:19, David Touzeau a écrit :
>> Dear
>>
>> I would like to tune postfix smtp sender according specific destination
>> domains eg number of connexions, number of email per seconds, queue life
>> time
>>
>> Is there any documentation on this needs or how can i define settings in
>> order to achieve this task ?
>>
>
> clone the smtp transport in master.cf. for example:
>
> slowsmtp      unix  -       -       n       -       -       smtp
>
> foosmtp      unix  -       -       n       -       -       smtp
>
> barsmtp      unix  -       -       n       -       -       smtp
>
>
> then you can use
>
> foosmtp_some_variable = some_value

Ok - I read "man 5 master" to try and figure this out, but it still
didn't make sense.

So for example, let's say I wanted to limit outgoing mail to yahoo.com
to 10 simultaneous connections and 20 emails per second. In master.cf
I'm presuming I put:

yahoosmtp      unix  -       -       n       -       -       smtp

But then I didn't understand the "some_variable = some_value" part of
the solution. I'm assuming that part goes in main.cf, but beyond that
I'm stumped on how my "10" and "20" values get declared and
interpreted properly.

Thanks,

SteveJ

Order of restrictions

[Steve Jenkins]

After watching the recent thread about filtering restrictions, it's
got me curious as to whether mine are optimal. I've recently added
support for backscatterer checking in my restrictions, and I moved
Stan's fqrdns.pcre check higher in my list per his suggestion in an
earlier thread. Mine now look like:

smtpd_helo_required = yes

disable_vrfy_command = yes

smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
check_client_access pcre:/etc/postfix/fqrdns.pcre,
reject_unknown_reverse_client_hostname,
warn_if_reject reject_non_fqdn_helo_hostname,
warn_if_reject reject_invalid_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_helo_access hash:/etc/postfix/helo_access,
check_sender_access hash:/etc/postfix/check_backscatterer,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client psbl.surriel.com,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
permit

Do I have these listed in an optimal order (from least to most
"expensive")? Any other suggestions?

The check_backscatterer file setup is as suggested on
http://www.backscatterer.org/?target=usage, with the exception of
"hash" instead of "dbm."

FYI - Using Postfix 2.6.5 on this box, but looking to use the same
restrictions on two of my 2.8.0 boxes.

Thanks,

SteveJ

Re: Order of restrictions

[Steve Jenkins]

On Wed, Feb 2, 2011 at 11:09 AM, Ralf Hildebrandt
 wrote:
>>         check_sender_access hash:/etc/postfix/check_backscatterer,
>>
>> The check_backscatterer file setup is as suggested on
>> http://www.backscatterer.org/?target=usage, with the exception of
>> "hash" instead of "dbm."
>
> Have you tried cdb?

My postconf -m says:
btree
cidr
environ
hash
ldap
mysql
nis
pcre
proxy
regexp
static
unix

So I'd have to rebuild with cdb support explicitly. But before I go
through the steps of doing that, what's the advantage to doing so over
just using hash: ? We don't get massive amounts of incoming mail, so
I'm not sure if there'd be a noticeable performance improvement.

Thanks,

SteveJ

Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]

[Steve Jenkins]

On Wed, Feb 2, 2011 at 2:33 PM, Stan Hoeppner  wrote:
> In the mean time, maybe give this a go.  1600+ expressions matching rDNS
> patterns of many millions of broadband IPs worldwide that shouldn't be sending
> direct SMTP.  Catches quite a bit that PBL/CBL/SORBS-DYNA/etc don't and with
> less delay, reduced load on dnsbl servers and your own network.  Potential FPs
> will be SOHO and "Linux weenie" MTAs on consumer IPs.  Usage instructions are
> comments at the top of the file.  Insert the restriction above/before any
> greylisting daemons in main.cf, obviously.  Some on this list and many on the
> Dovecot list can testify to its effectiveness.
>
> http://www.hardwarefreak.com/fqrdns.pcre

I can attest to the awesomeness of Stan's pcre file. I run it on all 5
of our Postfix servers, and it catches a LOT of stuff. From my logs,
what it seems to do best is block zombie mailers on dynamic IPs.

And I updated to your latest version today, Stan. Thanks :)

SteveJ

Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]

[Steve Jenkins]

On Thu, Feb 3, 2011 at 1:44 AM, J4K  wrote:
> Its a good idea, but this would limit a user from using a server on his
> residential ADSL from being an Email server, and force them to use their
> ISPs relay.  Else they might have to upgrade to a business package or spend
> more money for a static IP address that they can amend the reverse lookup
> record for.  Pros and cons.

It's a GREAT idea. I don't want/need email from users with ADSL or
cable modem servers that refuse to use their ISP's relay. If enough of
us stand firm on our mail acceptance policies to the point where we
force SOHO and "Linux Weenies" to use their ISP's relay (which
shouldn't cost them any money), then SPAMmers would take a huge hit.

SteveJ

Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]

[Steve Jenkins]

On Fri, Feb 4, 2011 at 5:18 AM, J4K  wrote:
> I think there is a typo in the file:
>
> /^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
> PREPEND X-GenericStaticHELO: (versatel.ml)
> should read /ml/nl/
> /^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
> PREPEND X-GenericStaticHELO: (versatel.nl)

And likewise on line 1589:

/^adsl-dc-[0-9]{4,6}\.adsl\.wanadoo\.nl$/   REJECT  Generic -
Please relay via ISP (wanadoo.ml)

should probably be:

/^adsl-dc-[0-9]{4,6}\.adsl\.wanadoo\.nl$/   REJECT  Generic -
Please relay via ISP (wanadoo.nl)

That pesky m sits pretty close to the n on the keyboard. :)

SteveJ

Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]

[Steve Jenkins]

On Thu, Feb 3, 2011 at 7:48 PM, Stan Hoeppner  wrote:
>>> CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been
>>> supported by Wietse for quite some time.  A new install of CentOS 5.5
>>> gives you an officially unsupported Postfix, thought I'm sure CentOS
>>> will support it.
>>>
>>> Now _that_ is "lagging behind something awful".
>>
>> CentOS's support for current software is an abomination. I wonder why
>> anyone takes it seriously.
>
> I've pondered this myself, and the conclusion I come to is that they are
> ignorant newbs who are enamored with the "free" version of Red Hat Enterprise
> Linux.  They look at the price tag of RHEL and think they're getting something
> good for nothing.  They just don't realize RHEL is not "good" and is years
> behind current, and that CentOS is months to years behind RHEL.

Some of us with older (but not THAT old) DELL hardware in our racks
are forced to run RHEL and/or CentOS, since it's the only distro DELL
official supports on that hardware. VERY recently, they've started
partnering with SuSE and Ubuntu as well, but for most of the stuff in
our racks, we're required to run RHEL to if we want system management
software, remote access, firmware updates, current drivers for RAID
adapters, etc.

Still, I am (well, WAS) disappointed that Postfix 2.3.3 is what
installs on CentOS 5.5 by default. But Postfix 2.8 wasn't that hard to
compile. :)

SteveJ

Re: newbie question

[Steve Jenkins]

On Fri, Feb 11, 2011 at 3:38 PM, Gergely Buday  wrote:
> Dear Postfix experts,
>
> I'm new to mailing servers and need advice. Is it reasonable for my
> small company to use my own mail server? How much configuration is
> needed for a secure setup on a CentOS box? The requirements are: I
> have three domain names and only one user with some aliases. Google
> apps is not an option as I would like to run my own web server. I have
> some experience with Unices.

As a GENERAL starting place, I'd check out one of the "Perfect Server"
setups on HowTo Forge for CentOS. It will walk you through setting up
Dovecot and Postfix.

However, Postfix 2.3.3 is what installs from the CentOS default repos,
and the latest version (2.8) has vast improvements. I've written a
HowTo explaining how to easily update your Postfix from the default
2.3.3 to 2.8 on a CentOS 5 box:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

SteveJ

Postfix "fatal" message with Amavis-new

[Steve Jenkins]

I've recently installed Amavis-new with SpamAssassin and ClamAV on one
of my boxes running Postfix 2.6.5.

I'm now seeing this occasionally in the maillog:

Feb 14 20:42:47 carbonfiber postfix/smtp[19516]: fatal: garbage after
"]" in server description: [127.0.0.1] :10025
Feb 14 20:42:47 carbonfiber postfix/smtp[19517]: fatal: garbage after
"]" in server description: [127.0.0.1] :10025
Feb 14 20:42:47 carbonfiber postfix/smtp[19518]: fatal: garbage after
"]" in server description: [127.0.0.1] :10025
Feb 14 20:42:47 carbonfiber postfix/smtp[19519]: fatal: garbage after
"]" in server description: [127.0.0.1] :10025
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: private/smtp
socket: malformed response
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: transport
smtp failure -- see a previous warning/fatal/panic logfile record for
the problem description
Feb 14 20:42:48 carbonfiber postfix/master[10978]: warning: process
/usr/libexec/postfix/smtp pid 19516 exit status 1
Feb 14 20:42:48 carbonfiber postfix/master[10978]: warning:
/usr/libexec/postfix/smtp: bad command startup -- throttling
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: private/smtp
socket: malformed response
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: transport
smtp failure -- see a previous warning/fatal/panic logfile record for
the problem description
Feb 14 20:42:48 carbonfiber postfix/master[10978]: warning: process
/usr/libexec/postfix/smtp pid 19517 exit status 1
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: private/smtp
socket: malformed response
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: transport
smtp failure -- see a previous warning/fatal/panic logfile record for
the problem description
Feb 14 20:42:48 carbonfiber postfix/master[10978]: warning: process
/usr/libexec/postfix/smtp pid 19518 exit status 1
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: private/smtp
socket: malformed response
Feb 14 20:42:48 carbonfiber postfix/qmgr[17204]: warning: transport
smtp failure -- see a previous warning/fatal/panic logfile record for
the problem description
Feb 14 20:42:48 carbonfiber postfix/master[10978]: warning: process
/usr/libexec/postfix/smtp pid 19519 exit status 1

Port 10025 is stated in master.cf:

smtp-amavis unix -  -   n   -   2   smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

127.0.0.1:10025 inet n  -   n   -   -  smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks

And this is the content_filter line in main.cf:

content_filter = smtp-amavis:[127.0.0.1]:10024

It must be related to the content filter settings I just added. Anyone
familiar with how all these programs interact got any clues as to what
might be causing this error? Restarting Postfix seems to make the
errors stop for a while, but within a couple hours they are always
back.

Google produced a 2009 discussion on this discussion list re: a
similar error, but I didn't see any resolution. :(

Thanks,

SteveJ

Re: Postfix "fatal" message with Amavis-new

[Steve Jenkins]

On Mon, Feb 14, 2011 at 9:01 PM, Victor Duchovni
 wrote:
> On Mon, Feb 14, 2011 at 08:56:07PM -0800, Steve Jenkins wrote:
>
>> I'm now seeing this occasionally in the maillog:
>>
>> Feb 14 20:42:47 carbonfiber postfix/smtp[19516]: fatal: garbage after
>> "]" in server description: [127.0.0.1] :10025
>
> You have a transport setting or FILTER action, ... that specifies
> [127.0.0.1]:10024 as a nexthop. The error report is from
> the smtp(8) delivery agent, which is trying to process the nexthop.

Hi, Victor. Thanks for the prompt reply and your help, but I have to
admit that your reply went COMPLETELY over my head! But I'm gonna dive
back into the docs and Google using your reply in an attempt to learn
something. :)

>> Port 10025 is stated in master.cf:
>
> The master.cf file is irrelevant.

Okey-dokey!

>> And this is the content_filter line in main.cf:
>>
>> content_filter = smtp-amavis:[127.0.0.1]:10024
>
> This is a different port.

Yes, it is - but I wanted to be complete in explaining the changes I
made to Postfix, just in case they affected anything. Although, this
is the port that your reply said was the nexthop (I'm looking that up
next to understand that better).

> No, it is related to either an exising transport(5) nexthop or access(5)
> FILTER entry, or a past one recorded in a queue file (postsuper -r ALL
> could help).

Ahhh - I think you may have just solved it. Could it have been an
earlier message that was received when I was tinkering with the
settings (and perhaps didn't have everything sorted yet) that was
sitting in the queue and repeating this error?

The postsuper flush worked (there were 14 messages that successfully
redelivered when I did that). I'm keeping an eye on the maillog since
doing that, and I'm not seeing the message re-occur!

Thanks,

SteveJ

Re: 2.8.0 smtpd killed while using TLS + SASL AUTH

[Steve Jenkins]

On Tue, Feb 22, 2011 at 1:05 PM, Victor Duchovni
 wrote:
> By the way, the OP should NOT be compiling an official release with
> "-DSNAPSHOT". If a snapshot is desired, download a snapshot release.

Googling "DSNAPSHOT" didn't answer the question for me, so please
allow a non-programmer to ask what this argument does when compiling
Postfix?

Thanks,

SteveJ

Re: posfix rejected from google server

[Steve Jenkins]

On Wed, Mar 2, 2011 at 10:44 PM, kapetr  wrote:
> So once again, I am not spamer!
> I hate spam and spamers !!

Being on a blacklist doesn't automatically make you a spammer, but it
does mean something's wrong (possibly with your Postfix config... to
keep things back on topic).

Check here to see who's listing you:

http://multirbl.valli.org/lookup/85.71.234.108.html

Then figure out what's up with your outbound mail to cause it.

SteveJ

Re: Question on how to setup amavisd with dovecot

[Steve Jenkins]

On Thu, Mar 3, 2011 at 7:33 AM, Islam, Towhid  wrote:
> I am trying to set up a mail system with postfix being the core (smtp) and
> dovecot for imap/pop3 for end-user mail delivery/retrieval.  While I have
> configured spam and virus scanning for my postfix based mail relay hosts,
> I’m not sure how to incorporate amavisd (for clamav and spamassassin) in
> this new system.  My question is how does it work in theory and where to put
> the necessary configuration parameters in main.cf and/or master.cf in
> postfix?  The way it should work, as I  believe it should, would be: mail is
> received by postfix then sent to amavisd for virus/spam checking then it is
> returned to postfix when postfix sends it to dovecot.  Am I correct?

Hi, Towhid.

After setting this up myself a while back (Postfix + ClamAV +
SpamAsassin + Amavis-new), I wrote a blog post with links and tips
that I discovered along the way. You may need to tweak depending on
the distro you use, but this should help nudge you in the right
direction:

http://stevejenkins.com/blog/2011/02/tips-for-installing-amavis-new-clamav-and-spamassassin-using-postfix-on-fedora-12/

SteveJ

Re: Kernel Oops

[Steve Jenkins]

On Fri, Mar 4, 2011 at 8:01 AM, Denis Shulyaka  wrote:
> Thanks! I will try to do this and will update you with the result.

When I read Denis' first post I thought "WHAT? Postfix on a WRT54G? He's crazy!"

But now I'm rooting for you, Denis! I hope you get it working! :)

SteveJ

Re: transport throttling issue

[Steve Jenkins]

On Sat, Mar 5, 2011 at 12:04 PM,   wrote:
> Yes, I'll try. I hope that the upstream will accept it, they have a very low 
> (and weird) rate policy

This thread was helpful for me, too, since I'm trying to make sure our
Postfix settings are compliant with Yahoo!'s guidelines. Their
Postmaster site says:

"Yahoo! Mail accepts a maximum of 20 messages per SMTP connection. We
encourage you to cap the number of messages you send to Yahoo! Mail to
fall within this per-connection limit.
When this limit is reached, no further messages will be accepted for
delivery as our server automatically terminates the connection
(without giving an error code). If you are sending messages to a
significant number of Yahoo! Mail users, the suggestions below will
help ensure uninterrupted delivery for your messages."

So, since the default_destination_concurrency_limit = 20 on my system,
do I not need to worry about setting up a custom transport for Yahoo!?
Or have others on this list found that creating a transport for Yahoo!
with additional custom settings has been helpful when delivering to
them with Postfix?

Thanks,

SteveJ

Re: Problems with postfix while sending emails

[Steve Jenkins]

On Tue, Mar 15, 2011 at 12:23 PM, Murray S. Kucherawy  
wrote:
>> -Original Message-
>> From: owner-postfix-us...@postfix.org 
>> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Ralf Hildebrandt
>> Sent: Tuesday, March 15, 2011 9:55 AM
>> To: postfix-users@postfix.org
>> Subject: Re: Problems with postfix while sending emails
>>
>> * Rafael Azevedo :
>> > Ralf, you're the g-e-n-i-o-u-s
>> >
>> > The problem is with DK-MILTER not DKIM.
>>
>> Doesn't DK-Milter do DKIM?
>
> No, it only does DomainKeys, which is "historic".  And dk-milter has bugs, 
> and is no longer supported.
>
> Anybody running it should seriously consider turning it off.

Allow me to second Murray's statement. There's no need to sign with
DomainKeys any more, and anyone running a mail server should consider
replacing DK signing with DKIM signing (and anyone not signing should
consider it). Multiple packages are listed at
http://www.postfix.org/addon.html - but I recommend OpenDKIM
(http://opendkim.org/), which is insanely easy to set up as as a
milter in Posfix.

SteveJ

Re: Problems with postfix while sending emails

[Steve Jenkins]

On Tue, Mar 15, 2011 at 8:54 PM, Stan Hoeppner  wrote:
> Steve Jenkins put forth on 3/15/2011 1:34 PM:
>
>> and anyone not signing should consider it.
>
> "Anyone not using seat belts and turn signals should consider it".
>
> I can see a clear advantage to the latter, but not the former.  Can you
> briefly explain why you believe everyone should sign mail?

Hi, Stan.

Of course, we both know there's no magic bullet. But signing can help
receivers verify the true provenance of the sender's message. Does it
guarantee that the message isn't SPAM? Of course not. Every SPAM I've
received from a GMail account has been signed. :)

But can signing help identify and/or deter some spammers? Sure. And
with optional ADSP extension to DKIM, it's even better. I see no
downside to signing, and therefore ANY potential upside is a good
thing. The resource overhead of DKIM signing and verifying is very
low, so what good reason is there to NOT sign?

Frankly, I don't know how to answer your 20% question. Maybe on your
system, 20% is as good as it's gonna get! But based on what I know
about you, I get the sense you're someone who primarily deals with
lots of incoming mail. And it always seems that where one stands
depends on where one sits. :) I'm sitting on the other side. We
process very little incoming mail, but send millions of legitimate
emails to our customers every week. DKIM signing them has undeniably
increased our inbox deliverability rates, and inbound processors can
know that if a mail claims to come from us but isn't signed, it's
bogus.

Again, with no downside and little-to-no cost, even a small potential
upside is a good thing.

Respectfully,

SteveJ

Re: Postscreen + Postfix configuration

[Steve Jenkins]

On Thu, Mar 17, 2011 at 10:59 AM, Victor Duchovni
 wrote:
> On Wed, Mar 16, 2011 at 11:46:47PM -0500, Noel Jones wrote:
>
>>> if I configure postscreen to use DNSBL, may I remove the lines
>>> for DNSBL checking on main.cf  for postfix? I understand
>>> enabling that on both postscreen and postfix is doing the same thing
>>> twice... Am I wrong?
>>>
>>
>> DNSBL checks can be removed from postfix main.cf if you do the same checks
>> in postscreen.  No need to do the same checks twice.  RHSBL (domain name)
>> checks will still need to be done in main.cf.
>
> I would caution against removing DNSBL lookups in smtpd(8).
>
>    - postscreen whitelists hosts for some time, the DNSBL can change
>      in the mean-time.
>
>    - For newly admitted hosts, the main cost of the lookup is bringing
>      the data into the local DNS cache. A second lookup in smtpd(8)
>      shortly after the initial lookup in postscreen is very efficient.
>
> Not all the hosts listed in Zen are botnet zombies, some of them are
> snow-shoe spam networks, which are likely to have been sending mail for
> some time before they are listed.
>
> If however, the postscreen whitelist TTL is not "too long", on the plus
> side, one avoids the RBL lookup latency when the RBL is remote, and the
> impact on RBL accuracy may be low. So for large sites with local mirrors
> of RBL zones, there is no advantage to skipping the lookups, but smaller
> sites *may* find that postscreen RBL lookups are enough, but some metrics
> may be useful to determine the impact of doing the lookups only on first
> contact, and then intermittently.
>
> --
>        Viktor.
>

I implemented Postscreen today. I'm really enjoying watching my
maillog show how effectively it's working!

I'm glad we're discussing this, because I was also wondering whether
or not I should comment out the reject_rbl_client lines in my main.cf.
I have the following DNSBL/RHSBL entries in my main.cf:

smtpd_recipient_restrictions =
...
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client psbl.surriel.com,
   reject_rhsbl_client dbl.spamhaus.org,
   reject_rhsbl_sender dbl.spamhaus.org,
   reject_rhsbl_helo dbl.spamhaus.org,
...

I had commented them out initially, but I'm convinced by Viktor's
argument, and have uncommented the reject_rbl_client lines. I've also
left the reject_rhsbl_* lines intact based on my understanding that
Postscreen doesn't do those checks.

My Postscreen options in main.cf look like this:

postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites =
b.barracudacentral.org*2,
zen.spamhaus.org*2,
psbl.surriel.com*2
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce

Am I correct in assuming that giving each of my postscreen_dnsbl_sites
equal weighting at the threshold provides similar functionality as my
reject_rbl_client entries?

I'm also curious as to what types of postscreen_dnsbl_sites usages and
weights others are using with Postscreen, especially with the DNSBL
reply filters (postscreen_dnsbl_sites = example.com=127.0.0.4).

What are others using and what's working well for you?

SteveJ

Re: 1st post new to postfix and fixing a server crash!

[Steve Jenkins]

On Mar 18, 2011, at 2:50 PM, lance raymond  wrote:

> What a way to welcome myself to the group!  But with that, the mailserver 
> crashed (HD fail) and the backups from last night were in tact.  Problem is 
> the old os was a RH9 (I know) system, built from source, etc.  The new box is 
> staged (CentOS5), postfix installed via YUM and the config was then compared. 
> They were using virtual domains/users, so that part of the config was moved 
> and looks like this;
> 
> disable_mime_output_conversion = yes
> strict_mime_encoding_domain = yes
> maildrop_destination_recipient_limit = 1
> vacation_destination_recipient_limit = 1
> virtual_mailbox_domains = cdb:/etc/postfix/virtdomains
> virtual_mailbox_base = /mail
> virtual_mailbox_maps = cdb:/etc/postfix/virtmailboxes
> virtual_uid_maps = static:508
> virtual_gid_maps = static:508
> virtual_minimal_uid = 100
> virtual_alias_maps = cdb:/etc/postfix/virtaliases
> virtual_transport = maildrop
> transport_maps = cdb:/etc/postfix/virttrans
> smtpd_recipient_restrictions = permit_mynetworks check_client_access 
> cdb:/etc/postfix/popb4smtp check_relay_domains
> #smtpd_client_restrictions = permit_mynetworks, check_client_access 
> cdb:/etc/postfix/popb4smtp, reject_rbl_client replays.ordb.org, 
> reject_rbl_client bl.spamcop.net
> smtpd_client_restrictions = permit_mynetworks, check_client_access 
> cdb:/etc/postfix/popb4smtp
> 
> Now in the /etc/postfix folder, those virtdomain/virtusers files were put 
> there, the mynetworks IPs, etc. are all set. A start on postfix and no 
> errors.  They use some PHP webmail front end, debugging up and a test login 
> (forced fail since I don't have a valid user/pass) I saw this in the apache 
> log;
> grep: /etc/dtpasswd: No such file or directory
> 
> [Fri Mar 18 13:01:36 2011] [error] [client 1.1.1.1] PHP Warning:  fsockopen() 
> [function.fsockopen]: unable to connect to 
> localhost:143 (Connection refused) in 
> /var/www/html/webmail.simpedia.com/functions/imap_general.php on line 172, 
> referer: http://webmail.siahou.net/src/login.php
> grep: /etc/dtpasswd: No such file or directory
> 
> I don't have that /etc/dpasswd file anywhere, but seeing 143 (IMAP) refusing, 
> I installed dovecot via YUM since I know he's an IMAP server and rehitting 
> the page, login, still got the dpasswd file, but the 143 refused is now gone. 
>  On extracting the backups, I do see a userdb file which I can cat and looks 
> like my user info;  example;
> supp...@domain.com
> systempw=fwsNTHmHTI1t.|uid=509|mail=/mail/domain.com/support|home=/home/maildrop|gid=509
>  
> Now I need to have the following;
> 1. The server back where the users can login and get their mail.
> 2. Know how to add / delete users (not sure if the userdb is a backup, etc. 
> since the config says to use the cdb file)
> 3. Testing.  Comparing to mysql, can I connect locally via command line, test 
> login, etc.?
> 
> Once I have 2 working, I can use a 3rd party client, but as of now, I don't 
> even know if new mail is being recieved, etc. as paths like /mail/mail.domain 
> doesn't exist.
> 
> Since this is my 1st post, I may be leaving out something, feel free to let 
> me know what (how to get it) and I will provide.
> 
> Thanks to all for reading and bearing with a new user.

Before you get too far into config, may I suggest that you upgrade to Postfix 
2.8? The version from the CentOS repos is woefully outdated.

Postfix 2.8 for CentOS 5 instructions here:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

SteveJ

Re: Milter question - three milters co-existance (dkim spamass clamav)

[Steve Jenkins]

On Tue, Mar 22, 2011 at 9:34 AM, J4K  wrote:
>
> Hi there,
>
>    I had two milters running on postfix: dkim-filter, spamass-milter.
> Both of these worked fine.
> I have added the clamav-milter to the config, but  I noticed that now
> the spamass-milter does not 'seem' to do anything.
>
> System set-up:
> postfix v 2.8
> Debian Squeeze
>
> The dkim-filter  functions as I expect.
> The Clamav-milter functions as I expect.
> The spamass-milter does not fire.  ( Nothing logged in the mail.log,
> mail.err mail.warn. No msgs in spamd.log spamass-milter. There are
> messages from spamd when the message is sent into dovecot/spamd).
>
> I tested this by sending a know spam test string, which scored 1003.9 on
> SpamAssassin.  The spamass-milter is set to reject spam over the 10
> threshold, yet it did not reject a score of 1003.9.
>    X-Spam-Status:  Yes, score=1001.9 required=5.0
> tests=ALL_TRUSTED,DCC_CHECK,
>    GTUBE,MISSING_SUBJECT,TVD_SPACE_RATIO shortcircuit=no autolearn=no
> version=3.3.1
> This should have been caught by the spamass-milter.
>
> Here is the change afore and afterwards:
>
> * Before
> smtpd_milters = unix:/spamass/spamass.sock,
> unix:/dkim-filter/dkim-filter.sock
> milter_default_action = tempfail
>
> * After
> smtpd_milters = unix:/dkim-filter/dkim-filter.sock,
> unix:/spamass/spamass.sock, unix:/clamav/clamav-milter.ctl
> milter_default_action = tempfail
>
> Is this configuration correct, and can anyone think of what causes the
> spamass-milter to be ignored?
>
> Best wishes, S.
>
> Regards, s.

I wrote a blog post a while back with some notes about running ClamAV,
SA, and OpenDKIM as milters with Postfix on Fedora. You might get some
nudges in the right direction for your attempt with Debian:

http://stevejenkins.com/blog/2011/02/tips-for-installing-amavis-new-clamav-and-spamassassin-using-postfix-on-fedora-12/

SteveJ

Re: Limit the number of forwarded emails

[Steve Jenkins]

On Tue, Mar 22, 2011 at 5:45 AM, Brian Evans - Postfix List
 wrote:
> On 3/22/2011 8:33 AM, Kenneth Holter wrote:
>> Thanks for the quick reply.
>>
>> Your solution seems to be a very good one, but unfortunately that
>> default_destination_rate_delay parameter is not available in the
>> postfix version I'm running (2.3). I'm using the postfix
>> implementation shipped with RHEL 5, which is not the most current one.
>>
>
> The most recent release of Postfix is 2.8.2.   2.3 is ancient and no
> longer supported for updates.
>
> Redhat now has RHEL 6 which, I believe, uses Postfix 2.7.
>
> There are reliable (S)RPM packages available for RHEL 5 that will get
> you to the parameters/functionality you need.
> The most common is by Simon Mudd referenced on
> http://www.postfix.org/packages.html at http://ftp.wl0.org/official/
>
> Brian
>
>> - Kenneth
>>
>> On Tue, Mar 22, 2011 at 10:32 AM, Reindl Harald  
>> wrote:
>>> Am 22.03.2011 09:05, schrieb Kenneth Holter:
 Hi all.

 I'm new to the list, and quite new to postfix.

 I'm running postfix 2.3 on one of my RHEL 5 servers, and have set up
 postfix to forward all emails to our Microsoft Exchange
 infrastructure.
 On the server running postfix, I have an applications that
 automatically generates emails. The issue I'm trying to solve is that
 at times, the application generates enormous amounts of emails,
 causing nearly a DoS attack on the Exchange servers.

 What I'd like to do is to have my postfix server rate limit the number
 of emails it's forwarding to the Exchange servers. For example, if I
 could get it to queue up emails, either on the inbound side or the
 outbound side, and forward them on a steady rate, that would be great.
 Note that all emails are generated locally on the server.

 Postfix seems to be a rather complex software, and I've not been able
 to identify which component I should be tuning to accomplish rate
 limiting. Any advice on this is greatly appreciated.
>>> we are using this setting to only send one message per destination and 
>>> second
>>> the problem is that "default_destination_rate_delay" only accepts whole
>>> seconds as delay and it depends on the count of messages if you can
>>> live with this, with < 10.000 mails per day 1 second delay for every
>>> destination is ok
>>>
>>> initial_destination_concurrency                     = 5
>>> smtp_destination_concurrency_limit                  = 5
>>> default_destination_recipient_limit                 = 15
>>> default_destination_concurrency_limit               = 5
>>> default_destination_concurrency_failed_cohort_limit = 5
>>> default_destination_rate_delay                      = 1
>>> transport_retry_time                                = 30
>>>
>>> if there are too messages for wait a second maybe you
>>> should set concurrency even lower and disable rate_delay
>>>
>>>
>
>

I don't think Simon has updated his Postfix (S)RPMs since RHEL 4. :(

Kenneth's best option may be to just compile 2.8 and upgrade:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

SteveJ

Re: Limit the number of forwarded emails

[Steve Jenkins]

On Tue, Mar 22, 2011 at 11:50 AM, Brian Evans - Postfix List
 wrote:
> It is rather obscure.

To say the least. :)

>The first blog post, which references 2.6, has a
> link that also contains info for 2.8.

For the sake of anyone looking through the archives, that link is:

http://ftp.wl0.org/official/2.8/

FWIW, Simon's RPMs seem to only be available for x86_64. So 32-bit
users will need to use the SRPMs and build their own 32-bit RPM before
installing... but at that point I still think it's less work to simply
compile and "make upgrade" from the source code, not to mention
allowing more flexibility to choose support for LDAP, MySQL, etc.
Users who take the small amount of time required to learn how to do so
can update their Postfix (to 2.8.2, for example) as soon as a new
version is released, rather than wait for generous people like Simon
to take time out of their schedule to build RPMs. Those of us running
RH should be grateful to Simon for his efforts, but I hate to see
people become completely dependent on them. :)

> It seems that Simon has not been updating his blog, only his ftp server.

The FTP server is clearly the more important of the two, so I don't
blame him. :)

SteveJ

Address Tagging in Postfix?

[Steve Jenkins]

I've been reading through
http://www.postfix.org/ADDRESS_REWRITING_README.html and Googling in
an attempt to figure out how to allow "tagging" of email accounts for
SPAM fighting purposes (mail to bob+any...@server.com gets delivered
to b...@server.com), but haven't been able to figure it out.

Can anyone nudge me in the right direction?

Thx,

SteveJ

Re: Address Tagging in Postfix?

[Steve Jenkins]

On Tue, Mar 22, 2011 at 2:47 PM, Wietse Venema  wrote:
> Steve Jenkins:
>> I've been reading through
>> http://www.postfix.org/ADDRESS_REWRITING_README.html and Googling in
>> an attempt to figure out how to allow "tagging" of email accounts for
>> SPAM fighting purposes (mail to bob+any...@server.com gets delivered
>> to b...@server.com), but haven't been able to figure it out.
>>
>> Can anyone nudge me in the right direction?
>
> You use
>
> /etc/postfix/main.cf:
>    recipient_delimiter = +
>
> Then, Postfix will try to match user+extens...@example.com
> before trying u...@example.com in most tables, and the
> local delivery agent will try to match user+extension
> before user when looking up aliases or .forward files.
>
> http://www.postfix.org/postconf.5.html#recipient_delimiter
> http://www.postfix.org/postconf.5.html#forward_path
> http://www.postfix.org/access.5.html
> http://www.postfix.org/canonical.5.html
> http://www.postfix.org/virtual.5.html
> http://www.postfix.org/transport.5.html
>
>        Wietse

Perfect. That's exactly what I was looking for. Thanks! :)

SteveJ

Re: Address Tagging in Postfix?

[Steve Jenkins]

On Tue, Mar 22, 2011 at 4:08 PM, mouss  wrote:
> if you're not running mailing lists, then yes, '-' is ok. if the domain
> has mailing-lists, then '-' is already in use

Interesting. Could the '-' delimiter still work in this case, as long
as the tagged address doesn't match an existing address used by the
mailing list software? As long as the usernames are different than the
mailing list(s) name (which should be the case anyway), and/or none of
the user-selected tags match the tags expected by the mailing list
software, can recipient_delimiter = - and the mailing list software
co-exist? Or does everything with a delimiter of '-' get handed over
to the mailing list software first?

Thanks,

SteveJ

Re: Address Tagging in Postfix?

[Steve Jenkins]

On Tue, Mar 22, 2011 at 4:41 PM, Wietse Venema  wrote:
> Didn't I write that Postfix will attempt the unextended name first,
> before trying the name without the text after $recipient_delimiter?

I'm assuming you meant "extended name first" - otherwise I'm confused! :)

Yes. I understand that with 'recipient_delimiter = -' Postfix will try
to match user-extens...@example.com BEFORE attempting u...@example.com
(in most tables).

But I'm still confused about mouss' advice that I shouldn't use '-' as
the delimiter if I'm using mailing list software. As long as
'user-extension' doesn't match any 'listname-command' combinations or
match any other valid recipients that include a hyphen before the @,
why can't I?

Thanks,

SteveJ

Re: postfix performance

[Steve Jenkins]

On Wed, Mar 23, 2011 at 3:22 PM, Victor Duchovni
 wrote:
> All of this is overkill, but a local DNS resolver is a requirement.

With high volume outbound mail, any advantage to having a local DNS
resolver on the same machine as Postfix? We've got one that's provided
by our colo provider, but it's not on the same subnet.

SteveJ

Re: postfix performance

[Steve Jenkins]

On Wed, Mar 23, 2011 at 5:09 PM, Joe  wrote:
> IMNSHO it's standard practice to run a dns server on the MX host. If you
> don't want a full blown bind server, at least run some sort of caching dns
> server; the difference in the lookup times has a big impact when you're
> sending messages at a high rate.

Thx, Joe. Any advantage IYNSHO to running a full blown bind server as
opposed to something simpler like dnsmasq or nsd (or anything else
you're recommend)?

Thanks,

Steve

Re: postfix performance

[Steve Jenkins]

On Thu, Mar 24, 2011 at 8:28 AM, Victor Duchovni
 wrote:
> A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ...
> does not matter.

Thanks for all the nudges in the right direction. We're now running
Unbound on the same box as Postfix, getting cached responses in 0 msec
from the Postfix box, and 1 msec responses from all other boxes in the
rack. It was as easy as "yum install unbound" and then editing two
lines in the default config file.

We'll test this week with a big mailing to see if the overall delivery
times are noticeably improved.

SteveJ

Re: postfix performance

[Steve Jenkins]

On Thu, Mar 24, 2011 at 10:34 AM, Victor Duchovni
 wrote:
> If all you changed was adding a local DNS cache, unless your previous
> cache was >100ms away, you'll not see much change.

Actually, after doing some tests with dig on our colo provider's DNS
servers we noticed that they were taking an avg of 200+ msec for a
reply, and sometimes over 400! We had no idea it was that bad. Again,
we're not sure if this change will have any impact on Postfix's
delivery times yet, but it's fun to try and optimize. :)

> To get better
> treatment from remote systems, get whitelisted by the domains that
> represent the largest communities of users.

Agreed - which we've already done.

Re: postfix performance

[Steve Jenkins]

On Fri, Mar 25, 2011 at 5:20 AM, Stan Hoeppner  wrote:
> You simply need a caching resolver on an MX/outbound, not a zone server.
>  A zone server is useless in this case.

Yep - I know that now. :)

> I use PowerDNS Recursor on my MX/outbound and never had a problem.
> Under Debian it's a 3 minute install+configuration time, assuming you
> read the docs beforehand.  Simply, effective, low resource consumption.
>  Oh, and free.

I installed both pdns-recursor and unbound (running without any zone
data) on a test box and got very similar performance results from
both. We happened to go with unbound, but based on your
recommendation, maybe I'll give pdns-recursor another look (it's still
running on our test box).

SteveJ

Postfix for Kids

[Steve Jenkins]

I've set it up in /etc/postfix/virtual on my personal server so that
when our kids get mail at theirn...@ourfamilydomain.com, both parents
get a copy of the incoming message.

Is there a simple was to configure Postfix so that I also get a copy
of only selected users' (our kids in this case) outbound email?

How about setting up an incoming per-user blacklist only for certain
addresses (in case a creepy boy from school starts emailing one of our
daughters... :)).

Thanks,

SteveJ

Re: Postfix for Kids

[Steve Jenkins]

On Sun, Mar 27, 2011 at 2:22 PM, Wietse Venema  wrote:
> See: http://www.postfix.org/postconf.5.html#sender_bcc_maps

Perfect. Although, I can only seem to include one address as a valid
sender bcc. The following doesn't work (parent 1 is a local UNIX
account, parent 2 is a virtual alias):

/etc/postfix/sender_bcc_maps:
k...@example.comparent1, pare...@example.com

My workaround was to change the sender_bcc target to
"pare...@example.com" and then create another virtual alias in
/etc/virtual:
...
pare...@example.comparent1, pare...@example.com
...

> This will get you into the murky world of restriction classes.
> http://www.postfix.org/RESTRICTION_CLASS_README.html
>
> You'll need to make your own variant of one of the examples.

Murky. Awesome. :) I'm also using SpamAssassin, so it may be easier
just to add unwanted senders to individual kid's
~/.spamassassin/user_prefs.cf.

Thanks!

SteveJ

Postscreen + Logwatch = A bunch of unmatched entries

[Steve Jenkins]

Ever since turning on Postscreen (which I love), my nightly LogWatch
reports (running 7.3.6) have bunches of unmatched entries due to
Postscreen. Anyone know if LogWatch 7.4.0 recognizes them, or how to
configure it so that I get usable Postscreen stats?

Thanks,

SteveJ

Re: Postscreen + Logwatch = A bunch of unmatched entries

[Steve Jenkins]

On Thu, Mar 31, 2011 at 12:29 PM, Steve Jenkins  wrote:
> Anyone know if LogWatch 7.4.0 recognizes them

Well, I can answer my first question myself. I just installed it and
can confirm that Logwatch 7.4.0 (released earlier this month) does NOT
recognize Postscreen entries:

 **Unmatched Entries**

 CONNECT from [127.0.0.1]:39527
 WHITELISTED [127.0.0.1]:39527
 CONNECT from [66.34.88.172]:33743
 addr 66.34.88.172 listed by domain b.barracudacentral.org as 127.0.0.2
 DNSBL rank 2 for [66.34.88.172]:33743
 NOQUEUE: reject: RCPT from [66.34.88.172]:33743: 550 5.7.1 Service
unavailable; client [66.34.88.172] blocked using
b.barracudacentral.org; from=,
to=, proto=ESMTP, helo=
 DISCONNECT [66.34.88.172]:33743

Anyone had any luck getting Postscreen and Logwatch to play nice together?

SteveJ

Re: Performance or delivery problems caused by "sleep"?

[Steve Jenkins]

On Friday, April 8, 2011, Stan Hoeppner  wrote:
> email builder put forth on 4/8/2011 10:14 PM:
>> Hello,
>>
>> I'm thinking about trying the example suggested in the documentation for
>> "sleep":
>>
>>
>> /etc/postfix/main.cf:
>> smtpd_client_restrictions =
>>         sleep 1, reject_unauth_pipelining
>> smtpd_delay_reject = no
>
> To achieve what goal?  Stopping bot spam?  There are much better methods
> available today.
>
>> In general, I try to order smtpd_*_restrictions with the least costly first, 
>> so
>
> Good habit.
>
>> this would be an exception.  Has "sleep" shown to be:
>>
>>   * effective?
>>   * cause performance issues?
>>   * cause any delivery problems?
>
> AIUI, this will delay every smtpd connection by 1 second.  Since each
> smtpd process can only process one transaction at a time, on a busy
> server you'll end up with lots of smtpd processes eating resources, and
> possibly mail delays if you reach the process limit of 100--incoming
> connections must wait for an smtpd to become available.  As to the
> effectiveness of sleep in combating bot spam, I have no idea as I've
> never tried it.
>
>> Or is this merely a poor-man's greylisting?
>
> In essence, yes.
>
>> Am I better off with a policy
>> server that can selectively implement a greylisting delay?
>
> No, you're better off using postscreen and or
> http://www.hardwarefreak.com/fqrdns.pcre instead of greylisting, which
> has its own set of performance and resource problems.
>
>> I'm using version 2.3.3
>
> You *need* to upgrade.  2.3.3 is ancient and no longer supported.  You
> need 2.8 to get access to postscreen.  fqrdns.pcre will work with any
> version containing pcre support.  I'm making an educated guess that
> you're using CentOS 5.5.  I believe the following is a binary rpm for
> rhel5 x86-64 (CentOS 5), which should be the package you need assuming
> you're running 64bit CentOS.
>
> http://ftp.wl0.org/official/2.8/RPMS-rhel5-x86_64/postfix-2.8.2-1.rhel5.x86_64.rpm
>
> This rpm is labeled "experimental" by Simon likely simply because it
> hasn't seen wide use yet.  If you want 2.8 and postscreen, this is
> likely the quickest way to get there.  Or you can download the source
> from postfix.org and build it yourself.

If you don't have a 64-bit system and/or want to upgrade using the
Postfix source, very easy instructions are here:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

SteveJ

Am I sending backscatter?

[Steve Jenkins]

I saw this in my maillog just now:

Apr 15 09:03:00 carbonfiber postfix/qmgr[28665]: 53D87104259C:
from=, size=16858, nrcpt=1 (queue
active)
Apr 15 09:03:01 carbonfiber amavis[28076]: (28076-20) Blocked
BAD-HEADER, [50.22.180.134] [50.22.180.134]
 -> , Message-ID:
<3297072511617582...@ibu134.olepykorin.info>, mail_id: mlACmT6BzNRX,
Hits: -, size: 17055,
dkim_id=shoppers_cent...@olepykorin.info,shoppers_cent...@olepykorin.info,
181 ms
Apr 15 09:03:04 carbonfiber postfix/smtp[31065]: 17795104259D:
to=,
relay=ibu134.olepykorin.info[50.22.180.134]:25, delay=3.5,
delays=0.05/0/3.5/0, dsn=4.0.0, status=deferred (host
ibu134.olepykorin.info[50.22.180.134] refused to talk to me: 421
ibu134.olepykorin.info out of connection slots)
Apr 15 09:12:50 carbonfiber postfix/smtp[31179]: 17795104259D:
to=,
relay=ibu134.olepykorin.info[50.22.180.134]:25, delay=590,
delays=586/0.01/3.7/0, dsn=4.0.0, status=deferred (host
ibu134.olepykorin.info[50.22.180.134] refused to talk to me: 421
ibu134.olepykorin.info out of connection slots)
Apr 15 09:22:51 carbonfiber postfix/smtp[31320]: 17795104259D:
to=,
relay=ibu134.olepykorin.info[50.22.180.134]:25, delay=1190,
delays=1186/0.01/3.6/0, dsn=4.0.0, status=deferred (host
ibu134.olepykorin.info[50.22.180.134] refused to talk to me: 421
ibu134.olepykorin.info out of connection slots)
Apr 15 09:42:53 carbonfiber postfix/smtp[6303]: 17795104259D:
to=,
relay=ibu134.olepykorin.info[50.22.180.134]:25, delay=2392,
delays=2386/0.01/3.6/2.5, dsn=2.6.0, status=sent (250 2.6.0 message
received)

Is that first "postfix/smtp" line sending a reject message to olepykorin.info?

Thanks,

SteveJ

Re: Am I sending backscatter?

[Steve Jenkins]

On Fri, Apr 15, 2011 at 3:19 PM, Sahil Tandon  wrote:
> On Fri, 2011-04-15 at 09:50:16 -0700, Steve Jenkins wrote:
>
>> I saw this in my maillog just now:
>>
>> Apr 15 09:03:00 carbonfiber postfix/qmgr[28665]: 53D87104259C:
>> from=, size=16858, nrcpt=1 (queue
>> active) Apr 15 09:03:01 carbonfiber amavis[28076]: (28076-20) Blocked
>> BAD-HEADER, [50.22.180.134] [50.22.180.134]
>>  -> , Message-ID:
>> <3297072511617582...@ibu134.olepykorin.info>, mail_id: mlACmT6BzNRX,
>> Hits: -, size: 17055,
>> dkim_id=shoppers_cent...@olepykorin.info,shoppers_cent...@olepykorin.info,
>> 181 ms Apr 15 09:03:04 carbonfiber postfix/smtp[31065]: 17795104259D:
>> to=,
>> relay=ibu134.olepykorin.info[50.22.180.134]:25, delay=3.5,
>> delays=0.05/0/3.5/0, dsn=4.0.0, status=deferred (host
>> ibu134.olepykorin.info[50.22.180.134] refused to talk to me: 421
>> ibu134.olepykorin.info out of connection slots)
>>
>> Is that first "postfix/smtp" line sending a reject message to
>> olepykorin.info?
>
> Did you set $final_bad_header_destiny (in amavisd-new) to something
> other than D_PASS or D_DISCARD, even though you configured Postfix to
> consult your content filter after-queue?

Thanks, Sahil. That was it. It was set to D_BOUNCE. I set it to D_PASS
for now, but will set it to discard later if that's problematic. I
love how Postfix logs everything, so that even if the problem is with
a third-party content filter, Postfix can help me track it down. :)

Best,

SteveJ

FYI - Postfix 2.8.2 and CentOS 5.6

[Steve Jenkins]

This isn't a Postfix issue, just an FYI for those running updated
versions of Postfix on CentOS.

I recently updated one of my CentOS 5.5 systems (which was running
Postfix 2.8.2 compiled from source) to CentOS 5.6. The Postfix package
appeared nowhere on the upgrade list, and my /etc/yum.conf has
"exclude=postfix*" However, after the upgrade and a reboot, Postfix
wouldn't start. The maillog complained about the "smtpd pass" settings
in master.cf that I had uncommented to enable Postscreen.

A postconf -d | grep version revealed that somehow, my Postfix version
had reverted to 2.3.3 (the default for new CentOS installs). I thought
this was strange, but since I had previously downloaded and compiled
Postfix 2.8.2 on that system, I did a "cd
/usr/local/src/postfix-2.8.2" and a "make upgrade" and was able to
start Postfix 2.8.2 successfully within a few seconds.

I wasn't sure if this was a one time thing, but confirmed the issue
last night when the same thing happened after upgrading another system
from CentOS 5.5 -> 5.6. I haven't been able to find the exact cause
yet, but I at least wanted to post a workaround for the archives in
case anyone else goes searching for this issue.

Thanks,

SteveJ

Re: FYI - Postfix 2.8.2 and CentOS 5.6

[Steve Jenkins]

On Mon, May 2, 2011 at 2:39 PM, Ned Slider  wrote:
> There was a (Red Hat/CentOS) security update to Postfix issued almost 3
> months after the upstream release of 5.6:
>
> https://rhn.redhat.com/errata/RHSA-2011-0422.html
>
> However, because CentOS were slow with the release of 5.6, the base update
> from 5.5 to 5.6, and subsequent errata to 5.6 were all rolled out
> simultaneously, including the Postfix update.

Ah, yep! That would explain it!

> To exclude postfix updates, you'd need to add the exclude line to both the
> [base] and [updates] sections of your /etc/yum.repos.d/CentOS-Base.repo
> config file. From your description I'd guess you've perhaps only excluded
> postfix from [base] and not [updates].

I actually didn't have it in either - I was under the (apparently
false) impression that just putting the exclude in yum.conf would
apply to any repo. It's in the CentOS-Base.repo file in [base] and
[updates] now, tho. Thank you. :)

> Looking at the install scripts run from the Postfix RPM package in CentOS,
> looks like it's reset itself as the default Postfix install as you've
> surmised.
>
> Running 'rpm -q postfix' would confirm if the latest Postfix RPM package
> slipped through your net during the 5.6 update.

Yep!

% rpm -q postfix
postfix-2.3.3-2.2.el5_6

Thanks for the excellent detective work, Ned. :)

SteveJ

Re: FYI - Postfix 2.8.2 and CentOS 5.6

[Steve Jenkins]

On Tue, May 3, 2011 at 2:48 AM, Nikolaos Milas  wrote:
> I only have an exclude for postfix* in yum.conf and all upgrades (with "yum
> update") went without problems. My Postfix was not replaced by the
> distribution's package.

Ahhh... found the problem. I had excluded postfix-* instead of postfix*

Just tested it on a diff box, and changing that in the /etc/yum.conf
excluded it properly with a yum check-update. :)

Thanks!

SteveJ

Re: fqrdns.regexp

[Steve Jenkins]

On Tue, Jun 7, 2011 at 7:06 AM, Бак Микаел  wrote:
> Hi list,
> Reading the archives I saw that there is a nice regexp with dynamic
> hostnames available here: www.hardwarefreak.com/fqrdns.regexp
>
> Unfortunately this file seems to be unavailable at the moment for some
> reason.
>
> Do you guys happen to know from where this file (latest) version can be
> downloaded.
>
> TIA,
> Mikael
>

It's http://www.hardwarefreak.com/fqrdns.pcre

Re: signing multiple domains with dkim

[Steve Jenkins]

Easy instructions for signing for multiple domains AND setting up with
Postfix here:

http://stevejenkins.com/blog/2010/09/how-to-get-dkim-domainkeys-identified-mail-working-on-centos-5-5-and-postfix-using-opendkim/

On Mon, Jun 20, 2011 at 10:59 AM, Murray S. Kucherawy  
wrote:
> OpenDKIM has ample documentation.  Did you try working with that first?
>
>
>
> http://www.opendkim.org/docs
>
>
>
> -MSK
>
>
>
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of kshitij mali
> Sent: Monday, June 20, 2011 1:04 AM
> To: Patrick Ben Koetter
> Cc: postfix-users@postfix.org
> Subject: Re: signing multiple domains with dkim
>
>
>
> Hello Patrick ,
>
> Will u share some doc how to get opendkim work with postfix MTA.
> Such has installation and administration , configuration , troubleshooting
> etc.
>
> Regards,
> Kshitij
>
> On Mon, Jun 20, 2011 at 12:52 PM, Patrick Ben Koetter 
> wrote:
>
> Am 20.06.2011 07:50, schrieb Suresh Kumar Prajapati:
>
>> Hi,
>>
>> Can anyone tell me how to sign mails for multiple domains .
>
> My recommendation: Drop dkim-milter because IIRC it is unmaintained.
> Get the followup opendkim  instead.
>
> If you follow dkim-filter read into KeyList:
>
> # KeyList is a file containing tuples of key information. Requires
> # KeyFile to be unset. Each line of the file should be of the format:
> #    sender glob:signing domain:signing key file
> # Blank lines and lines beginning with # are ignored. Selector will be
> # derived from the key's filename.
> #KeyList                /etc/dkim-keys.conf
>
>
> p@rick
>
>>
>> here is my dkim conf file
>>
>> # To sign only, use -bs
>> # EXTRA_FLAGS=-bs
>> USER="dkim-milter"
>> SOCKET="inet:8891@localhost"
>> #PORT="inet:10034@localhost"
>> SIGNING_DOMAIN=""
>> SELECTOR_NAME="dktest"
>> KEYFILE="/etc/mail/domainkeys/dkim_${SELECTOR_NAME}.pem"
>> SIGNER=yes
>> VERIFIER=yes
>> CANON=simple
>> SIGALG=rsa-sha1
>> REJECTION="bad=r,dns=t,int=t,no=a,miss=r"
>> EXTRA_ARGS="-h -l -D"
>> MILTER_GROUP="mail"
>>
>>
>
> --
>
> state of mind ()
> Digitale Kommunikation
>
> http://www.state-of-mind.de
>
> Franziskanerstraße 15      Telefon +49 89 3090 4664
> 81669 München              Telefax +49 89 3090 4666
>
> Amtsgericht München        Partnerschaftsregister PR 563
>
>

Re: fqrdns.pcre and IPv6

[Steve Jenkins]

On Thu, Jul 7, 2011 at 2:04 PM, Noel Jones  wrote:
> On 7/7/2011 3:42 PM, mouss wrote:
>
>>
>> Noel, are you telling me that check_reverse... will match the client IP?
>> my understanding is that it will only match against the PTR.
>
> It's even documented.
> http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access
>
> And I can say with authority that it works as documented.
>
>  -- Noel Jones

I was confused, then I wasn't, now I am again. :)

I'm currently using Stan's pcre file with check_client_access. But
even after re-reading this while thread and that doc link, I can't
tell whether I should keep it as-is or switch to
check_reverse_client_hostname_access.

SteveJ

Re: Upgrade 2.3.3 to 2.8.4 problems

[Steve Jenkins]

On Sat, Jul 9, 2011 at 8:32 AM, Jeffrey Starin  wrote:
> On 7/9/2011 10:53 AM, Reindl Harald wrote:
>>
>> Am 09.07.2011 16:40, schrieb Jeffrey Starin:
>>
 NEVER do any source-install over a installed RPM and i guess yu
 can not remove the rpm-package beause of dependencies

 the other option would be using a prebuilt RPM
 even as fedora user i guess there are some for CentOS 5
 but they are not included upstream - so you have to trust the builder

>>> Thank you!
>>>
>>> As I'm relatively new to these things when you say take a src.rpm from
>>> centOS6 might you mean this?
>>>
>>>
>>> http://pkgs.org/download/centos-6-rhel-6/epel-i386/spamass-milter-postfix-0.3.1-21.el6.noarch.rpm.html
>>>
>>> I just want to make extra sure I'm getting the right package.
>>> Thanks
>>
>> .SRC.rpm NOT .rpm, what you linked is a binary rpm
>> you have to rebuild (recompile) this with rpmbuil --rebuild file.src.rpm
>>
>> but since you want to download "spamass-milter-postfix" while search for
>> "postfix"
>> i would recommend let that do somebody who knows a little bit about
>> administration
>> because we can not learn you basic-knowledges on a mailing-list
>>
>>
> Thank you.  You've been more than helpful already.
>
> Cheers.

Jeffrey:

Have the technician read this:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

It will walk him through upgrading from 2.3.3 to 2.8.3 on CentOS
(which is what I'm guessing your OS is). The same instructions can be
used for 2.8.4.

SteveJ

CentOS 6: Good News and Bad News

[Steve Jenkins]

Yes, I realize that many on this list are not CentOS fans, but the
RHEL distro it's based on is the only one officially supported on a
big chunk of our hardware (some older Dell boxes) so it's what we use.
And because it's free, it's also used by a good number of sysadmins.

So the GOOD news is that after installing the recently released CentOS
6, I discovered that Sendmail is no longer the default MTA. The
default is Postfix. Yay! Of course, that's old news to anyone running
the full blown RHEL6, but I thought it was cool anyway. Congrats,
Wietse. :)

The BAD news is that while the installed version is newer than 2.3.3
(which was in CentOS 5), it's only 2.6.6. I suppose that's still
progress, but I'm working on an updated version of my "Installing the
latest Postfix on CentOS" blog article to walk people through using a
spec file to build their own 2.8.4 RPM and upgrade with it.

SteveJ

Tool(s) for locating Postfix Bottlenecks to increase performance?

[Steve Jenkins]

We send a moderately decent amount of legitimate mail to our
subscribers (about 400K opt-in newsletter members) using Postfix. We
get excellent inbox deliverability percentages, because we use the
latest version of Postfix with settings we've arrived at with the help
of many on this list, are on the major whitelists and feedback loops,
etc.

Now, we want to turn our focus to delivery speed. We use a local
resolver (Unbound), which seems to have sped things up a bit. We also
use Postscreen, so our SMTP processes are busy sending mail, instead
of dealing with bots. We use a fallback relay to re-attempt deliveries
that don't go the first time from our primary server. But it still
takes the better part of a day to send all the mails out. We'd like to
shrink that time as much as (reasonably) possible.

I know nothing about Postfix optimization, and therefore have no idea
where to even start. Are there any tools that anyone can recommend to
help us track down where our limiting factors are when it comes to
mail delivery? At this point, we don't know if it's CPU, memory, disk
access speed (which is what I suspect), or something else altogether.
We don't even know how to measure how many messages are being
delivered on average every second/minute/hour, etc. so that we can
start with a baseline to measure improvements.

I'm sure many have been down this road before - care to shove a n00b
in the right direction?

Thanks,

SteveJ

Re: Tool(s) for locating Postfix Bottlenecks to increase performance?

[Steve Jenkins]

On Tue, Jul 26, 2011 at 3:47 PM, /dev/rob0  wrote:
> postscreen(8) protects smtpd(8), not smtp(8). Bots are not a problem
> for the latter. You might want to take some time to review this:
>    http://www.postfix.org/OVERVIEW.html

Hi, Rob. Thanks for the quick reply. And cool - learned something
already. Thanks. That makes sense.

> http://www.postfix.org/QSHAPE_README.html
> http://www.postfix.org/TUNING_README.html#mailing_tips

QSHAPE is one tool we were already using, and the good news is that
even during a send process (one of which is going on right now), the
active queue is generally very small. Like so:

 T  5 10 20 40 80 160 320 640 1280 1280+
  TOTAL  9  9  0  0  0  0   0   0   00 0
  yahoo.com  3  3  0  0  0  0   0   0   00 0
  gmail.com  2  2  0  0  0  0   0   0   00 0
  ymail.com  2  2  0  0  0  0   0   0   00 0
   yahoo.in  1  1  0  0  0  0   0   0   00 0
hotmail.com  1  1  0  0  0  0   0   0   00 0

And here's the qshape deferred output on our fallback relay:

 T  5 10 20 40 80 160 320 640 1280 1280+
  TOTAL 25  2  2  1  3  8   6   0   00 3
 abv.bg  3  0  0  0  1  2   0   0   00 0
   www.facebook.com  3  0  0  0  0  1   0   0   00 2
  tmail.com  2  1  0  0  1  0   0   0   00 0
myemail.com  2  0  0  0  0  2   0   0   00 0
 at.net  1  0  0  0  0  0   1   0   00 0
   bebo.com  1  0  0  0  0  1   0   0   00 0
   2323.com  1  0  0  0  0  1   0   0   00 0
  umail.com  1  0  0  0  1  0   0   0   00 0
  tahoo.com  1  0  0  0  0  0   1   0   00 0
 global.net  1  0  0  0  0  0   0   0   00 1
gotmail.com  1  0  0  0  0  0   1   0   00 0
   100gmail.com  1  0  0  0  0  0   1   0   00 0
   earthlik.net  1  0  0  1  0  0   0   0   00 0
  gamerbeta.com  1  0  0  0  0  0   1   0   00 0
 123hotmail.com  1  0  0  0  0  0   1   0   00 0
 etu.unistra.fr  1  0  1  0  0  0   0   0   00 0
 suddenlink.net  1  0  0  0  0  1   0   0   00 0
msps.vic.edu.au  1  1  0  0  0  0   0   0   00 0
 landgate.wa.gov.au  1  0  1  0  0  0   0   0   00 0

We've been through the General Delivery tips section of the TUNING_README:

- Read and understand the maildrop queue, incoming queue, active queue
and deferred queue discussions in the QSHAPE_README document.
- In case of slow delivery, run the qshape tool as described in the
QSHAPE_README document.

The queue looks good and empties quickly.

- Submit multiple recipients per message instead of submitting
messages with only a few recipients.

We do this one, because each message is unique (has to have an
individual unsub link and contains the subscriber's name)

- Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to
adjust the smtpd_recipient_limit parameter setting.

SwiftMail is submitting via SMTP.

- Don't overwhelm the disk with mail submissions. Optimize the mail
submission rate by tuning the number of parallel submissions and/or by
tuning the Postfix in_flow_delay parameter setting.

As far as parallel submissions, we're only doing three at a time
(three SwiftMail processes sending at a time). Our in_flow_delay
parameter is set to 0. We aren't receiving a lot of mail on this box,
so I'm not sure that delay would even kick in if it were set to the 1s
default. Beyond this, we're not sure how to check to see if the disk
is being "overwhelmed with mail submissions."  Out iowait% is 0.23, so
the CPU isn't waiting for the disk. How else can we tell if we're
overwhelming the disk?

- Run a local name server to reduce slow-down due to DNS lookups. If
you run multiple Postfix systems, point each local name server to a
shared forwarding server to reduce the number of lookups across the
upstream network link.

- We run unbound on our main mailer, and the fallback_relay points to
it, as well.

- Reduce the smtp_connect_timeout and smtp_helo_timeout values so that
Postfix does not waste lots of time connecting to non-responding
remote SMTP servers.

Our smtp_connect_timeout is 10s and our smtp_helo_timeout is 60s.

- Use a dedicated mail delivery transport for problematic
destinations, with reduced time

Re: Tool(s) for locating Postfix Bottlenecks to increase performance?

[Steve Jenkins]

On Wed, Jul 27, 2011 at 12:26 AM,   wrote:
> Dual-Proc with around 50% percent usage looks like a saturated cpu core. Is
> SwiftMail single process/thread at some point. What is the CPU usage per
> process?

Watching a "top," CPU usage per process on the PHP script that is
running the mailer hovers between 55-85%

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
30812 root  16   0 30128  15m 5296 R 85.7  0.5   3:44.91
gid_send_newsle
31014 root  16   0 27168  11m 4760 S 84.7  0.4   2:02.50
gid_send_newsle
30629 root  16   0 28812  13m 5292 R 64.5  0.5   5:22.92
gid_send_newsle
27027 opendkim  15   0 79928 3836 1632 S  4.6  0.1  32:03.86 opendkim
30727 root  15   0  2428 1128  800 R  1.0  0.0   0:02.31 top
 2615 unbound   15   0 46012  27m 1640 S  0.7  0.9  78:27.71 unbound
21655 postfix   15   0  7392 2104 1548 S  0.7  0.1   4:12.98 qmgr
29641 postfix   15   0  9692 4556 2896 S  0.7  0.1   0:02.42 smtpd
31214 postfix   15   0  9732 4704 3040 S  0.7  0.2   0:00.22 smtpd
31257 postfix   16   0  7400 2388 1852 S  0.7  0.1   0:00.14 cleanup
31269 postfix   15   0  7404 2356 1852 S  0.7  0.1   0:00.12 cleanup
31541 postfix   15   0  7400 2356 1852 S  0.7  0.1   0:00.02 cleanup
 2889 root  15   0  1816  580  484 S  0.3  0.0   2:10.09 syslogd
31036 postfix   15   0  7488 2952 2404 S  0.3  0.1   0:00.18 smtp
31050 postfix   15   0  7572 3100 2444 S  0.3  0.1   0:00.25 smtp
31086 postfix   15   0  9688 4540 2896 S  0.3  0.1   0:00.42 smtpd
31143 postfix   15   0  7500 2936 2388 S  0.3  0.1   0:00.11 smtp
31146 postfix   15   0  7576 3108 2448 S  0.3  0.1   0:00.14 smtp
31178 postfix   15   0  7484 2836 2304 S  0.3  0.1   0:00.11 smtp
1 root  15   0  2160  648  568 S  0.0  0.0   2:33.29 init

>Do you have many using small parts or one using a big share?

Sorry - I didn't understand this question. Are you referring to using
multiple partitions to store the logs and queue?

Thanks,

Steve

Re: Tool(s) for locating Postfix Bottlenecks to increase performance?

[Steve Jenkins]

On Wed, Jul 27, 2011 at 1:15 AM, Ralf Hildebrandt
 wrote:
> * Steve Jenkins :
>
>> QSHAPE is one tool we were already using, and the good news is that
>> even during a send process (one of which is going on right now), the
>> active queue is generally very small. Like so:
>
> The output looks very good. No room for optimization!

Cool - that's what we were seeing, too.

>> We do this one, because each message is unique (has to have an
>> individual unsub link and contains the subscriber's name)
>
> Good!

:)

>> As far as parallel submissions, we're only doing three at a time
>> (three SwiftMail processes sending at a time). Our in_flow_delay
>> parameter is set to 0. We aren't receiving a lot of mail on this box,
>> so I'm not sure that delay would even kick in if it were set to the 1s
>> default. Beyond this, we're not sure how to check to see if the disk
>> is being "overwhelmed with mail submissions."  Out iowait% is 0.23, so
>> the CPU isn't waiting for the disk. How else can we tell if we're
>> overwhelming the disk?
>
> When you're overwhelming the disk, all IO would be dedicated to
> accepting the mail from SwiftMail, not Sending the Mail out.

Okay - makes sense.

>> We're not really seeing problematic destinations. The mail is getting
>> delivered right away when we attempt to deliver. it's just that our
>> attempts don't seem to happen very quickly.
>
> Maybe your upstream network link is saturated?

Not likely, it's a pretty large pipe, and everything looks clear there
(and all other traffic through our switch is moving normally).

>> Before we just blindly throw bigger hardware at the issue, we'd still
>> love some ideas to help research what else could be slowing us down.
>
> default_process_limit is set to what?

We haven't set it, so I presume that means it's using the default of
100. I just checked, and we're using 44 of them.

I'm gonna take a hard look at the PHP script running the mailer
through SwiftMailer today. At first I was thinking disk IO, but CPU is
seeming to be a strong culprit.

Thanks,

SteveJ

Using same SSL cert for HTTPS and TLS?

[Steve Jenkins]

I'm currently using a self-signed cert for TLS in Postfix, but I have
a standard SSL cert from GoDaddy for my personal web domain. Is it
possible to use the same cert for both? Would I have to change
'myhostname=' in Postfix to simply be domain.tld (since I don't have a
wildcard cert)? Any other changes I'd need to make (apart from
pointing smtpd_tls_key_file and smtpd_tls_cert_file to the new key and
cert)?

Thanks,

SteveJ

smtp_bind_address came in handy today

[Steve Jenkins]

We're migrating our mail servers to new IPs on a different subnet
(we're not happy about it, but our ISP gave us little choice). so we
activated the second NICs in our mail servers and connected them to
the separate subnet, with the plan to deac the NICs on the old subnet
after a week or so. However, while the DNS was propagating, we were
getting rejected mail from some remote servers that complained that
our forward and reverse lookups didn't match because our mail was
still going out the old IP.

http://www.postfix.org/postconf.5.html#smtp_bind_address saved our
bacon. We told Postfix to use just the new IP, and the rejections
stopped.

So if anyone else has multiple IPs on the same server, but you want to
force your mail out on a specific IP, smtp_bind_address is for you. :)

Thanks,

SteveJ

Re: DKIM milter

[Steve Jenkins]

On Wed, Sep 7, 2011 at 7:15 AM, Kirill Bychkov  wrote:
> Someone has a server with DKIM check? Can I send a email there?

I like this one:

http://www.brandonchecketts.com/emailtest.php

and there are a few more listed in the "Testing Things Out" section of
this post:

http://stevejenkins.com/blog/2011/08/installing-opendkim-via-rpm-with-postfix-or-sendmail-for-rhel-centos-fedora/

SteveJ

Re: DKIM milter

[Steve Jenkins]

On Wed, Sep 7, 2011 at 8:57 AM, Wietse Venema  wrote:
> This means they broke it (assuming you aren't doing special
> processing for Mail.RU etc. destinations).

Agreed. I generally test by sending a message to my GMail account. If
it says "Signed by:" in the header details, I'm satisfied that I'm
successfully sending mail with valid DKIM sigs. If anyone else says it
fails, it's likely they're breaking it themselves. GMail isn't
infallible, but they're reliable enough to depend on for testing.

SteveJ

Re: DKIM signing problem

[Steve Jenkins]

On Sun, Sep 18, 2011 at 11:14 PM, Murray S. Kucherawy  
wrote:
> I suggest trying again with OpenDKIM (http://www.opendkim.org).  The 
> dkim-milter package has been unmaintained for a couple of years now.  It 
> lives on under the new name, with lots of bug fixes and new features since 
> dkim-milter's final release.

+1. Anyone who is still running dkim-milter can swap over to OpenDKIM
in a matter of minutes - keeping your existing keys, DNS settings,
etc.

In fact, since you're running CentOS 6, if you have EPEL enabled you
can just do "yum install opendkim" and it will install the latest
release version of OpenDKIM with the most common default
configuration, including a set of default keys for your server. The
opendkim package is available in the stable repos for Fedora 14-17 and
EL 5-6.

SteveJ

Any way to minimize Postscreen logging?

[Steve Jenkins]

I couldn't find anything in the docs, but is there an option to
minimize Postscreen's log output? For troubleshooting I'd turn logging
back to full, but perhaps an option to only show the NOQUEUE output in
the maillog? Assuming this doesn't exist, I think that might be a nice
feature for future versions.

SteveJ

Re: Off Topic: Auto-whitelisting from sent mail?

[Steve Jenkins]

On Wed, Sep 21, 2011 at 7:35 AM, Stan Hoeppner  wrote:
> On 9/20/2011 6:54 PM, Peter Blair wrote:
>>
>> On Tue, Sep 20, 2011 at 9:16 AM, Stan Hoeppner
>>  wrote:
>>>
>>> On 9/19/2011 5:38 PM, john wrote:

 I think this is off topic.

 I am running Ubuntu 11.04 as a SOHO server with
 postfix/dovecot/Amavis-new/Spamassassin/Clamav setup as my email
 service.

 Does anybody know of a program... that can white list inbound email
 based upon the addresses of emails that have been sent?
>>>
>>> This simple 7 line bash script does the trick superbly on Debian.  Thus
>>> it
>>> should work fine on Ubuntu as well.
>>>
>>> http://www.hardwarefreak.com/whtlst_gen.sh.txt
>>>
>>> Drop it in an executable search path, then do a chmod +x and follow the
>>> instructions in the file.
>>
>> Nice. But if you're running a multi-tennant system, you'll need a way
>> to map sender/recipient pairs to the inbound.  We do that with a
>> postfix policy server that hooks into the END-OF-MESSAGE stage, which
>> will provide the SASL authenticated user, and the smtp-envelope
>> recipient (there are problems with multi-recipients that you have to
>> work out).  Feed this into something like
>> http://wiki.apache.org/spamassassin/ManualWhitelist and you're good to
>> go.
>
> As the comments state:
> # Postfix quick/dirty auto whitelisting script
> :)

AWESOME little script. Nice, Stan!

One minor detail stops me from using it, however. I have an old domain
hosted on my server that no longer gets any legit mail, but that
serves as a great honeypot. So I direct any emails sent to that domain
via Postfix to a file, and then I point my spam filtering software at
it nightly to learn from it. However, those addresses all show up in
the maillog as "SENT" - which adds them to the raw file in your
script. I'm not a scripter, so any ideas on how to work around that,
either via Postfix or via the script?

Thanks,

SteveJ

Re: Any way to minimize Postscreen logging?

[Steve Jenkins]

On Wed, Sep 21, 2011 at 3:03 PM, mouss  wrote:
> Le 21/09/2011 16:02, Steve Jenkins a écrit :
>> I couldn't find anything in the docs, but is there an option to
>> minimize Postscreen's log output? For troubleshooting I'd turn logging
>> back to full, but perhaps an option to only show the NOQUEUE output in
>> the maillog? Assuming this doesn't exist, I think that might be a nice
>> feature for future versions.
>>
>
> so you'd like to have
>        if (shouldlog(feature)) {
>                logit(...)
>        }
> all around the code?

Saying I'd "like to have" that is incorrect, because that's how a
programmer thinks about it - which is fine. However, I'm thinking
about it only from the user's perspective, and from that perspective,
I always enjoy programs that have a scale of verbosity levels in their
programs. I was troubleshooting Unbound earlier today, and had to
crank the logging all the way up to level 5 to find what I needed, and
then turned it back down to 1. This is a great feature. As far as what
it takes to program that feature, I hope none of the programmers on
this list won't be offended when I say that users don't really care
what it will take to provide something. It's just not how most
consumers in any markets are "wired."

> the fact that postfix provides "incremental" logs is not without reason.
> you may be happy to see Apache logs a line per request, and unhappy to
> see that postfix gives you many lines for a single transaction. but for
> those of us who care about security, postfix logging is the way: if the
> system is compromised in the middle of a transaction, we get some
> information to work with. of course, most of the time, this is useless,
> but when you need it, it's there.

I won't argue with your reasoning - of course having information
available when you need it is important. Logging is the key to
troubleshooting. I'm simply saying that there are some of us out here
who could function just fine with varying amounts of that information,
especially after our setups are "stable." Personally, I want every
smtpd and qmgr line that Postfix generates in my maillog. But since
I'm happy with my DNSBL setup, I could gladly do without the "addr
188.53.28.175 listed by domain zen.spamhaus.org as 127.0.0.11" or
"DNSBL rank 6 for [91.226.113.62]:1732" entries, for example. Others
will have different wants and needs, of course.

Logfiles are knowledge, and knowledge is power, as they say. But as a
part-time karate instructor when I'm not being a computer geek, I can
attest that flexibility is just as important as power. :)

SteveJ

Re: Off Topic: Auto-whitelisting from sent mail?

[Steve Jenkins]

On Thu, Sep 22, 2011 at 3:38 AM, Stan Hoeppner  wrote:
> On 9/21/2011 1:48 PM, Steve Jenkins wrote:
>
>> AWESOME little script. Nice, Stan!
>>
>> One minor detail stops me from using it, however. I have an old domain
>> hosted on my server that no longer gets any legit mail, but that
>> serves as a great honeypot. So I direct any emails sent to that domain
>> via Postfix to a file, and then I point my spam filtering software at
>> it nightly to learn from it. However, those addresses all show up in
>> the maillog as "SENT" - which adds them to the raw file in your
>> script. I'm not a scripter, so any ideas on how to work around that,
>> either via Postfix or via the script?
>
> I'm not sure how this could be an issue.  The only addresses added to this
> whitelist are smtp recipient addresses successfully delivered to via the
> smtp(8) service.  Rerouting your trap mail to a local file is going to occur
> via local(8), pipe(8), or another mechanism, depending on how exactly you're
> doing it, but not via smtp(8).  Thus you should be able to use the script as
> is without issue, unless you're running something other than GNU/Linux, in
> which case you may be having sed/sort/uniq switch issues I discussed
> earlier.
>
> If you are truly having undesirable addresses added to the whitelist file,
> maybe you could share some log snippets and sections of the file
> /tmp/wrkng-whtlst.tmp showing the address(es) in question, obfuscated of
> course, or send me the real data off list.

Running Fedora. After reading your reply I did some more snooping. The
issue is that I use a catchall address for my honeypot domain
(jenesys.com) in /etc/postfix/virtual to redirect to the honeypot
address for the primary mail domain on that box
(honey...@stevejenkins.com). I don't mind sharing the actual addresses
publicly, because if they get harvested and spammed, they'll just go
to my honeypot. :) Anyway, here's the line in my /etc/postfix/virtual:

@jenesys.com  honeypot

The "sent" in the logfile is happening when the virtual alias hands
off the message to the honeypot alias:

Sep 18 21:31:41 carbonfiber postfix/smtp[12860]: D73201042498:
to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=3.5, delays=1/0/0/2.5,
dsn=2.0.0, status=sent (250 2.0.0 Ok, id=09206-09, from
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as EC7381042499)

The honey...@stevejenkins.com address on the primary mail domain
points to the /var/spool/mail/spam file for later processing. I tried
doing changing the line in my virtual file to:

@jenesys.com /var/spool/mail/spam

But that didn't work. Anyone got a method to get an incoming message
to a virtual address to write to a file without a SENT command?

SteveJ

Re: No default or sample aliases file

[Steve Jenkins]

On Sun, Sep 25, 2011 at 9:46 AM, Reindl Harald  wrote:
>
>
> Am 25.09.2011 17:51, schrieb John Hinton:
>> On 9/25/2011 10:56 AM, /dev/rob0 wrote:
>>> On Sunday 25 September 2011 07:27:59 Phill Edwards wrote:
> Where did you look? A source install of Postfix using default
> paths places an /etc/postfix/aliases file.
 I installed from CentOS RPMs. The version I have  is
 postfix-2.3.3-2.3.el5_6.
>>> FYI that version was EOL in 2009.
>> Note that CentOS is a clone of RedHat. Redhat has always has the motto of 
>> staying with base version numbering for
>> packages contained in the original release... or at least when possible. 
>> They then 'backport' all security fixes
>> to these old numbered versions. Why? Well, after running RedHat based 
>> servers for a bit over 15 years, I can
>> count on one hand the number of times updates broke something. Config files 
>> don't change, or if they do, they are
>> written as filename.rpmnew and you are warned. Rarely do you have to do 
>> anything about these.
>
> all correct
>
> but that means that recent documentations and howtos for complexer setups
> are useless for RHEL/CentOS if you are not using a recent build what
> is done in few minutes in the case of postfix
>
> i have not seen any problem upgrading postfix in the last 5 years
> on a lot of machines and with the complexest configurations you
> can imagine

+1. Anyone running RedHat/CentOS really should consider upgrading to
the latest Postfix. This procedure has been tested personally by me
and performed at least hundreds (maybe thousands?) of times, based on
the traffic to the article:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

It's targeted directly at users running Postfix 2.3 on RedHat/CentOS
who want to upgrade to Postfix 2.8. Nothing will break. It just works.

SteveJ

Re: upgrade to 2.8.5 with src rpm

[Steve Jenkins]

On Mon, Oct 3, 2011 at 2:32 AM, Nikolaos Milas  wrote:
> I would suggest you to use source code and build according to these
> directions:
> http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

At the risk of sounding biased, +1 to Nikolaos' thoughts. :)

>>> Have you used sasl auth with packages built from this rpm? I've had a
>>> heck
>>> of a time trying to build with the pertinent features enabled on centos
>>> 5.

>> sasl authentication for sending mail works, but the package that manages
>> the
>> authentication is broken and only supports PLAIN authentication type as
>>
>> I want to reconfigure these packages for several types of authentication
>> but I
>> do not know how

Normally, I like to use RPMs when possible. However, in the case of
Postfix, I've found it's much easier, and allows for much more
flexibility, to simply declare the settings you need with "make
makefiles" and then just build from the source as explained in my
HowTo.

The Postfix RPMs I've seen floating around out there seem to have a
number of patches. I've discussed them with Simon Mudd (who build the
original Postfix RPMs a while back) and he warns that his spec file
(and the ones derived from it) is very old and based on much earlier
versions of Postfix, and that he's not following Postfix's progress
any more. Many of the available patches address issues that are
already addressed in the current Postfix version, and attempt to solve
issues that are no longer issues - thereby creating new issues. :)

Again, I like RPMs - but in Postfix's case, the "make upgrade" path as
designed by Wietse works wonderfully, and it's what I recommend with
RedHat/CentOS.

SteveJ

Re: upgrade to 2.8.5 with src rpm

[Steve Jenkins]

On Mon, Oct 3, 2011 at 10:02 AM, Reindl Harald  wrote:
> it takes 5 minutes to clean the SPEC-File and remove
> these patches - really i do not understand your problem

It takes 5 minutes for YOU to clean the SPEC file, because you're
familiar with Postfix, you know precisely what you want in a Postfix
installation, and know precisely WHAT to clean to get it. :)

However, most don't have the experience that you and the other senior
members of the Postfix community, and can easily get confused. From
the questions I get through that blog article, it's clear there is a
wide range of expertise levels when it comes to Postfix, RPMs, and
source compiling. That's how this whole thread got started! :)

SteveJ

Re: Content filter after DKIM proxy

[Steve Jenkins]

>
> I think the hour or less it would take to replace dkimproxy with
> OpenDKIM would be well spent.
>
>
A big +1 on this. I wrestled with DKIM-Proxy for a couple of afternoons
before stumbling upon OpenDKIM. I had it up and running and playing nicely
with Amavis-new in under an hour.

The following isn't one of my normal walkthrough HowTo blog posts, but it
does contain some notes I wrote to myself about things to consider when
deploying OpenDKIM with Amavis-new. I've also got additional stuff there
detailing how to configure OpenDKIM, too (disclosure: I'm the maintainer of
the Fedora / EPEL OpenDKIM package).

The OpenDKIM developer announced the newest beta yesterday, including "An
experimental implementation of a DKIM-based reputation system is present,
and support for it as a reputation client (in the filter) and as a server
are present in the package."

The main reason I'm a fan of using OpenDKIM over Amavis-new's for signing is
that OpenDKIM keeps pace more rapidly with changes to the DKIM standards,
and is looking forward to reputation-based decision making based on DKIM
signatures. Most Postfix admins could get OpenDKIM up and running on their
lunch break, and still have time to eat. :)

SteveJ

Re: Content filter after DKIM proxy

[Steve Jenkins]

On Wed, Oct 19, 2011 at 12:03 PM, Steve Jenkins wrote:

> The following isn't one of my normal walkthrough HowTo blog posts, but it
>> does contain some notes I wrote to myself about things to consider when
>> deploying OpenDKIM with Amavis-new. I've also got additional stuff there
>> detailing how to configure OpenDKIM, too (disclosure: I'm the maintainer of
>> the Fedora / EPEL OpenDKIM package).
>
>
Drat - forgot the link. Sorry. :)

http://stevejenkins.com/blog/2011/02/tips-for-installing-amavis-new-clamav-and-spamassassin-using-postfix-on-fedora-12/

SteveJ

Re: postfix on virtual machine

[Steve Jenkins]

On Fri, Oct 28, 2011 at 5:55 AM, Wietse Venema  wrote:
> Amira Othman:
>> Hi all
>>
>> Iam using postfix 2.3 on virual machine cento 5.7 when I send mail from
>> virtual machine to yahoo or gmail I get error

As an aside, may I recommend updating your Postfix to the latest
version (2.8)? The default CentOS version of 2.3 is ancient in Postfix
years. :)

Google "postfix centos 2.8" and a howto I wrote will pop up as the top
hit. All settings from your current Postfix install will be
maintained.

SteveJ

Re: dkim-milter verify, but don't sign.

[Steve Jenkins]

2011/11/7 Robert Schetterer :
> post your problem dkim-milter list
>
> http://sourceforge.net/mail/?group_id=139420

FYI - that list doesn't exist any more. dkim-milter has been
deprecated in favor of OpenDKIM (http://opendkim.org/). It's an
actively-supported milter project, and switching over from dkim-milter
is painless. :)

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:00 PM, Wietse Venema  wrote:

> The way smtp_fallback_relay is implemented, it adds each relay as
> a low-priority MX host with a safety check: if the relay does not
> resolve, then mail is not bounced.
>

Hey, Wietse. I appreciate the reply.

Ok - as far as I can tell, the relay IS resolving. And actually, I've got
it configured as smtp_fallback_relay = [mailer2.example.com] in brackets to
eliminate the MX lookup.


> If you see deferred mail on mailer1, then it still needs to be
> forwarded to the smtp_fallback_relay. The maillog file should
> say why that hasn't happened yet.
>

qshape isn't showing deferred mail on mailer1, though. qshape deferred is
all zeros. The active queue is massive, however (over 91K messages in it
now) and more than half of them are in the 1280 column.

When a destination replies to mailer1 like this:

Jan 16 16:10:15 mailer1 postfix-aol/smtp[1744]: 41C4F4F6F7D: host
mailin-04.mx.aol.com[64.12.90.34] refused to talk to me: 554
mtain-mh04.r1000.mx.aol.com ESMTP not accepting connections

Should that not trigger handing the message over to the fallback relay for
subsequent attempts?

Thx,

Steve

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:12 PM, Steve Jenkins wrote:

> Should that not trigger handing the message over to the fallback relay for
> subsequent attempts?
>

Hold on... maybe it IS handing it off, now that I look at it more closely.
This is from mailer1:

Jan 16 16:14:32 mailer1 postfix-aol/smtp[1732]: 97092438FFD: host
mailin-01.mx.aol.com[64.12.90.1] refused to talk to me: 554
mtain-me04.r1000.mx.aol.com ESMTP not accepting connections
Jan 16 16:14:35 mailer1 postfix-aol/smtp[1732]: 97092438FFD: host
mailin-02.mx.aol.com[64.12.90.65] refused to talk to me: 554
mtain-ma05.r1000.mx.aol.com ESMTP not accepting connections
Jan 16 16:14:36 mailer1 postfix-aol/smtp[1732]: 97092438FFD: host
mailin-04.mx.aol.com[205.188.146.194] refused to talk to me: 554
mtain-dh06.r1000.mx.aol.com ESMTP not accepting connections
Jan 16 16:14:37 mailer1 postfix-aol/smtp[1732]: 97092438FFD: host
mailin-02.mx.aol.com[64.12.137.162] refused to talk to me: 554
mtain-mj01.r1000.mx.aol.com ESMTP not accepting connections
Jan 16 16:14:40 mailer1 postfix-aol/smtp[1732]: 97092438FFD: host
mailin-03.mx.aol.com[64.12.90.97] refused to talk to me: 554
mtain-mc05.r1000.mx.aol.com ESMTP not accepting connections
Jan 16 16:14:40 mailer1 postfix-aol/smtp[1732]: 97092438FFD: to=<
xx...@example.com>, relay=mailer2.example.com[xx.xx.xx.xx]:25, delay=7365,
delays=6096/1261/8.3/0.13, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
1AB9F142131)

And then over on mailer2 I'm seeing the message to to
xx...@example.com(which is actually an
aol.com address) get delivered.

So I guess I should change my question - it looks like mailer1 is
attempting to deliver to 5 AOL mail servers before passing off to the
relay. Any way I can make it hand off to the fallback relay with fewer
attempts?

Thanks,

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:22 PM, Wietse Venema  wrote:

> With "smtp_skip_5xx_greeting = yes" by default, Postfix pretends
> that the session failed due to a temporary error and tries the next
> MX host (or fall-back relay).
>
> If the mail is still in the active queue then Postfix is still
> trying other hosts.
>

OK - that makes sense and explains my huge queue!


> grep '41C4F4F6F7D' will show some of the delivery history, but
> you will need grep 'smtp.1744' for details.
>

Yes - as I discovered in the message above, after looking at more log lines
together it seems mailer1 is trying multiple mailers on AOL's network (and
I assume the number of MX servers Postfix tries is controlled by AOL's DNS
records) before passing off to mailer2. So I suppose it's working like it's
supposed to.

I guess my only other option is to turn off smtp_skip_5xx_greeting, in
which case it will hand off to mailer2 on the first failure, correct? Is
there any option to configure the number of failed attempts before handing
off to the fallback relay, other than just ON/OFF?

Thx,

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:35 PM, Stan Hoeppner 
 wrote:

> Why not simply spread the newsletter load over both your outbounds to
> begin with?
>

Until this week, we were using an OLD server to act as our fallback relay
(graveyard) machine and nothing else, since we really couldn't lean on it
that hard (or depend on it for anything mission-critical) . But we've
upgraded it to one that's the exact same specs as our primary mailer, so
moving forward that's probably what we'll do.

And BTW, if you're not a spammer, don't say "double opt in".  There is
> no such thing.  Spammers invented this term.  If you are a legit sender,
> the proper term is "confirmed opt in", or "COI".
>

Gotit - thanks. I am certainly NOT a spammer. Although a spammer probably
wouldn't admit to being a spammer anyway... So COI it is. :)

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema  wrote:

> You can twiddle with smtp_mx_mumble_limit, but why bother sending
> from mailer1, when the mail is accepted only from mailer2?
>

I think mailer1 got blocked initially by AOL because my
aol_destination_concurrency_limit, aol_destination_recipient_limit, and
aol_destination_rate_delay were probably set too aggressively when we
initiated the send last night. I've since cranked them down on mailer1 to
match the settings of mailer2, but AOL hasn't reacted yet. We're still
twiddling with those settings, too. :)

Our PHP script we use to send the mail is currently only configured to run
from mailer1, and is running right now, and we don't want to have to
interrupt it to move a copy over to mailer2 and write something that keeps
track of which mailer sent the newsletter to which recipients.

Any way to use the transport maps on mailer1 to tell Postfix to use mailer2
for aol.com addresses? Then I could just change that setting, do a postfix
reload, and let mailer1 "cool off" in AOL's eyes.

Thx,

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema  wrote:

> You can twiddle with smtp_mx_mumble_limit


FYI - Google returns NO results (nor does the search function on
Postfix.org... since it's Google-powered) for "smtp_mx_mumble_limit." Any
docs on that?

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 5:27 PM, Wietse Venema  wrote:

> mumble is a wild-card.
>
> grep smtp_mx_ in postconf output.
>

DOH! Roger that. :)

Also, any way to use transport in some way on mailer1 to tell Postfix to
use mailer2 for aol.com addresses? I could set that temporarily for the
remainder of this mailing.

Thx,

SteveJ

Re: Fiddling with smtp_fallback_relay

[Steve Jenkins]

On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema  wrote:

> You can twiddle with smtp_mx_mumble_limit, but why bother sending
>  from mailer1, when the mail is accepted only from mailer2?
>

For those who are learning along with me, since I didn't want to leave the
smtp_mx_address_limit settings at the default of 5 for all other
destinations, and I already had a transport set up for a number of
aol.comrelated domains, I added -o smtp_mx_address_limit=2 to my AOL
section in
master.cf, and then restarted Postfix.

SteveJ