null envelope and reject_authenticated_sender_login_mismatch

[Marco]

Hello,

 I have the following problem.
I configured Postfix 3.0.1 to force SASL auth and permit only a set of  
envelope sender addresses for each login  
(reject_authenticated_sender_login_mismatch).


I would like to understand why the null envelope sender address ("<>")  
is always permitted for all logins, even if it doesn't match the  
smtpd_sender_login_maps table.
reject_authenticated_sender_login_mismatch works as expected for all  
other envelopes.



Could you help me to know why?

Thank you very much
Marco


2bounce_notice_recipient = a...@example.com
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 5m
append_at_myorigin = no
append_dot_mydomain = no
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 3
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_recipient_limit = 1
delay_warning_time = 3h
disable_vrfy_command = yes
enable_long_queue_ids = yes
error_notice_recipient = a...@example.com
hopcount_limit = 50
html_directory = no
inet_interfaces = $myhostname
inet_protocols = all
mail_name = 
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 1d
message_size_limit = 10485760
meta_directory = /usr/share/postfix
mydestination =
mynetworks =
newaliases_path = /usr/bin/newaliases.postfix
parent_domain_matches_subdomains =
proxy_interfaces = DD.DD.DD.DD
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-3.0.1/README_FILES
relay_domains =
sample_directory = /usr/share/doc/postfix-3.0.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = no
smtp_helo_name = .example.com
smtp_helo_timeout = 30
smtp_mail_timeout = 30
smtp_quit_timeout = 30
smtpd_banner = $myhostname ESMTPSA $mail_name Welcome to Mail Submit
Agent!
smtpd_client_connection_rate_limit = 40
smtpd_client_message_rate_limit = 600
smtpd_client_recipient_rate_limit = 3000
smtpd_client_restrictions = permit_mynetworks,  
permit_sasl_authenticated, reject

smtpd_error_sleep_time = 20
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname
smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket
unix:/run/rate-limit/rate-limit.sock
smtpd_recipient_limit = 1
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_login_maps = ldap:/etc/postfix/ldap-loginmap.cf
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_authenticated_sender_login_mismatch,
smtpd_tls_CAfile = /etc/postfix/certs/CA.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/certs/.pem
smtpd_tls_key_file = /etc/postfix/certs/.privkey.pem
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache
unknown_local_recipient_reject_code = 550


master.cf
submission inet  n   -   n   -   -   smtpd
pickup unix  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache

Re: null envelope and reject_authenticated_sender_login_mismatch

[Viktor Dukhovni]

On Tue, Apr 28, 2015 at 09:03:51AM +0200, Marco wrote:

> I would like to understand why the null envelope sender address ("<>") is
> always permitted for all logins, even if it doesn't match the
> smtpd_sender_login_maps table.
> reject_authenticated_sender_login_mismatch works as expected for all other
> envelopes.

This address can't be reasonably owned by any particular login.
If any of your submission clients are MTAs, they need to be able
to send bounces.

If you don't want to allow authentication submission from the null
sender address, you can restrict that sender address via access(5):

null-sender:
<>  permit_mynetworks, reject_unauth_destination

main.cf:
unindexed = texthash:${config_directory}/

smtpd_sender_restrictions =
check_sender_access ${unindexed}null-sender,
reject_sender_login_mismatch

smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

...

-- 
Viktor.

RE: spam fighting

[Marius Gologan]

Hi Terry,

I use amavisd-new/spamassassin in post-queue configuration with few
adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
Bayes_95, Bayes_99, Bayes_999 and few others.
Local DNS server - critical for RBL queries.
As for postscreen, I preffer "postscreen_greet_action = enforce" only which
doesn't require the client to retry (as opposite to greylist behavior),
while is pretty effective against bots.

Marius.


-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
Sent: Tuesday, April 28, 2015 1:15 AM
To: postfix users
Subject: spam fighting

We've been using postscreen and dspam for quite some time but in the past
couple months more spam is making it through. I realize there's no
one-size-fits-all approach but because dspam isn't actively developed
anymore I've started looking around and am curious what others are using. Is
amavisd-new/spamassassin the preferred solution? My company is small with
<30 users.

Perhaps my postscreen settings could be improved? postscreen_access.cidr is
a small file with 4 entries to whitelist customers that aren't implicated in
the increase in spam.

$ postconf -n
broken_sasl_auth_clients = yes
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
debugger_command =
PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_privs = nobody
delay_warning_time = 4h
dovecot_destination_recipient_limit = 1
dspam-lmtp_destination_recipient_limit = 1
home_mailbox = Maildir/
html_directory = no
inet_protocols = ipv4
mail_owner = _postfix
mailq_path = /opt/local/bin/mailq
manpage_directory = /opt/local/share/man
message_size_limit = 5120
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = mailbox.dop.com
mynetworks = 192.168.0.0/23, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /opt/local/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/opt/local/etc/postfix/postscreen_access.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = 
 b.barracudacentral.org=127.0.0.2*7 
 dnsbl.inps.de=127.0.0.2*7 
 bl.mailspike.net=127.0.0.2*5 
 bl.mailspike.net=127.0.0.[10;11;12]*4 
 dnsbl.sorbs.net=127.0.0.10*8 
 dnsbl.sorbs.net=127.0.0.5*6 
 dnsbl.sorbs.net=127.0.0.7*3 
 dnsbl.sorbs.net=127.0.0.8*2 
 dnsbl.sorbs.net=127.0.0.6*2 
 dnsbl.sorbs.net=127.0.0.9*2 
 zen.spamhaus.org=127.0.0.[10;11]*8 
 zen.spamhaus.org=127.0.0.[4..7]*6 
 zen.spamhaus.org=127.0.0.3*4 
 zen.spamhaus.org=127.0.0.2*3 
 hostkarma.junkemailfilter.com=127.0.0.2*3 
 hostkarma.junkemailfilter.com=127.0.0.4*1 
 hostkarma.junkemailfilter.com=127.0.1.2*1 
 wl.mailspike.net=127.0.0.[18;19;20]*-2 
 list.dnswl.org=127.0.[0..255].0*-2 
 list.dnswl.org=127.0.[0..255].1*-3 
 list.dnswl.org=127.0.[0..255].2*-4 
 list.dnswl.org=127.0.[0..255].3*-5 
 hostkarma.junkemailfilter.com=127.0.0.1*-2
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 5m
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
proxy_interfaces = 70.167.15.110
queue_directory = /opt/local/var/spool/postfix
readme_directory = /opt/local/share/postfix/readme
sample_directory = /opt/local/share/postfix/sample
sendmail_path = /opt/local/sbin/sendmail
setgid_group = _postdrop
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = 
 permit_mynetworks,
 permit_sasl_authenticated, 
 reject_non_fqdn_sender, 
 reject_non_fqdn_recipient, 
 reject_unknown_sender_domain, 
 reject_unknown_recipient_domain, 
 reject_unauth_pipelining, 
 reject_unauth_destination, 
 reject_unlisted_recipient, 
 check_recipient_access pcre:/opt/local/etc/postfix/recipient_checks.pcre, 
 check_helo_access hash:/opt/local/etc/postfix/helo_checks, 
 check_sender_access hash:/opt/local/etc/postfix/sender_checks, 
 check_client_access hash:/opt/local/etc/postfix/client_checks, 
 check_client_access pcre:/opt/local/etc/postfix/fqrdns.pcre, 
 reject_rhsbl_client dbl.spamhaus.org, 
 reject_rhsbl_sender dbl.spamhaus.org, 
 reject_rhsbl_helo dbl.spamhaus.org, 
 check_client_access pcre:/opt/local/etc/postfix/dspam_filter_access
smtpd_reject_unlisted_sender = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks, reject_unknown_address
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /opt/local/etc/postfix/ssl/certs/postfix.cert
smtpd_tls_key_file = /opt/local/etc/postfix/ssl/private/postfix.key
smtpd_tls_loglev

Re: Conversation with x.x.x.x[x.x.x.x] timed out while sending end of data

[Kristjan Nii]

Thank you for your response!
I viewed the some emails in the queue and did not see DKIM signatures in
them. Also, our network guys confirmed, that ASA version is 7.3, which
should be bug-free.
Any other ideas or things I should/could check and test?

Kristjan

On Mon, Apr 27, 2015 at 5:09 PM, Wietse Venema  wrote:

> Kristjan Nii:
> > Apr 22 16:55:01 mailhost postfix/qmgr[30648]: E2A36C84B2:
> > from=, size=7385, nrcpt=1 (queue active)
> > Apr 22 16:55:22 mailhost postfix/smtp[23649]: E2A36C84B2: enabling PIX
> > workarounds: disable_esmtp delay_dotcrlf for x.x.x.x[x.x.x.x]:25
> > Apr 22 17:05:32 mailhost postfix/smtp[23649]: E2A36C84B2:
> > to=, relay=x.x.x.x[x.x.x.x]:25, delay=1999,
> > delays=1369/20/0.02/610, dsn=4.4.2, status=deferred (conversation with
> > x.x.x.x[x.x.x.x] timed out while sending end of data -- message may be
> sent
> > more than once)
>
> The Cisco PIX (ASA) has a history of bugs that break email.  As the
> logging shows, Postfix can work around some bugs but but it cannot
> work around other bugs, such as bugs in their handling of DKIM-signed
> email.
>
> Wietse
>

Re: Conversation with x.x.x.x[x.x.x.x] timed out while sending end of data

[Bill Cole]

On 28 Apr 2015, at 8:45, Kristjan Nii wrote:


Thank you for your response!
I viewed the some emails in the queue and did not see DKIM signatures 
in

them. Also, our network guys confirmed, that ASA version is 7.3, which
should be bug-free.


Perhaps it "should be" (a slippery English idiom that might mean a few 
different things...) but your logging indicates otherwise. The "enabling 
PIX workarounds" warnings are not random accidents.


The Cisco implementation of semi-transparent SMTP proxying that 
interferes with what extensions a server is allowed to advertise to a 
client is one big bug in design: a functional mode that should not have 
ever been offered. It is impossible to operate a sound modern mail 
server behind that filter. Historically it has also had a series of 
implementation bugs as well (i.e. malfunctions that were not part of the 
intentional design) and it would be unwise to assume that series has 
ended, but ultimately any MTA behind an ASA with that switched on will 
have chronic insoluble problems even if Cisco's code is finally doing 
precisely all that they intend and nothing more.



Any other ideas or things I should/could check and test?


Note that by obliterating all of the domain name and IP address details 
from your log excerpt you protect nothing and assure that no one else is 
able to examine the problem directly or inform your troubleshooting with 
specific useful information. The relationship between these two machines 
is unclear and made more so by your obfuscation. So my recommendations 
are necessarily vague...


Examine the behavior of any other devices and software besides the 
supposedly "bug-free" ASA that might be interfering with the 
conversation. This could include other networking devices or local 
packet filtering software with an unusual configuration. If this 
connection is not using TLS, you might also benefit from an examination 
of packet captures of a session on both ends.


Also, you may need to figure out exactly what this log line means:

Apr 22 16:32:12 mailhost amavis[22879]: (22879-15-3) Passed BAD-HEADER-8 
{RelayedInbound,Quarantined}, [xxx.xxx.xxx.xxx]:55925 [xx.xx.xx.xx] 
 -> , quarantine: 
k/badh-kptbg9M-W8dx, Queue-ID: 04F22C848E, mail_id: kptbg9M-W8dx, Hits: 
-0.041, size: 6451, queued_as: E2A36C84B2, 2886 ms


I don't run Amavis so I don't know exactly what that signifies, but it 
looks a bit ominous. I suppose it might be possible that Amavis is doing 
something unobvious to the messages that is somehow causing the inside 
machine to take a very long time to analyze them and so causing the 
timeouts at end of data.


Correlating the log entries of the internal and external machines for a 
more complete picture may also help.





Kristjan

On Mon, Apr 27, 2015 at 5:09 PM, Wietse Venema  
wrote:



Kristjan Nii:

Apr 22 16:55:01 mailhost postfix/qmgr[30648]: E2A36C84B2:
from=, size=7385, nrcpt=1 (queue active)
Apr 22 16:55:22 mailhost postfix/smtp[23649]: E2A36C84B2: enabling 
PIX

workarounds: disable_esmtp delay_dotcrlf for x.x.x.x[x.x.x.x]:25
Apr 22 17:05:32 mailhost postfix/smtp[23649]: E2A36C84B2:
to=, relay=x.x.x.x[x.x.x.x]:25, delay=1999,
delays=1369/20/0.02/610, dsn=4.4.2, status=deferred (conversation 
with
x.x.x.x[x.x.x.x] timed out while sending end of data -- message may 
be

sent

more than once)


The Cisco PIX (ASA) has a history of bugs that break email.  As the
logging shows, Postfix can work around some bugs but but it cannot
work around other bugs, such as bugs in their handling of DKIM-signed
email.

 Wietse

Re: Stan Hoeppner's fqrdns.pcre file?

[Alex Regan]

Hi,


check_client_access uses the verified name, which is more conservative.
I wasn't convinced this was a good idea, so I played it safe.


So check_client_access is performing an additional DNS query on the
hostname to check if it matches the IP?



Right.


Awesome, thanks. I'm learning all the time :-)


It does, but RDNS_DYNAMIC matches fewer patterns.


Are you concerned about duplicate points for effectively the same rule?


A little bit, but not nearly enough to figure out how the two overlap
and do something about it. I've never had a false positive report
involving my GENERIC_RDNS, so it can't be *that* bad. If it ever causes
an issue I'll probably drop the rule entirely.


Okay, good point. I did see quite a few FPs when I was rejecting with 
the fqrdns.pcre file outright, however.


Thanks,
Alex

Re: Stan Hoeppner's fqrdns.pcre file?

[Alex Regan]

Hi,


I should have mentioned that I actually did that, once I couldn't
find Stan's site:

https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre


For those who are using it, I've replaced it with a version from March
2013 instead of March 2012.

https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre

I don't know when Stan did his final update, but if anyone has one newer
than Mar 27 2013, please send it to me off-list and I'll update it.


I've forwarded to Steve my version from Oct 2014, but also just happened 
across this, from Stan, in 2012:


http://postfix.1071664.n5.nabble.com/postscreen-supersedes-fqrdns-pcre-table-td46419.html

As we all look to utilize every mechanism possible in the fight against 
spam, perhaps this list is now too rudimentary and antiquated to be used 
any longer?


Thanks,
Alex

ERRATA(?): MILTER_README

[Bill Cole]

Postfix v.3.0.0 MILTER_README says:


Sendmail macro emulation

	Postfix emulates a limited number of Sendmail macros, as shown in the 
table.

Some macro values depend on whether a recipient is rejected (rejected
	recipients are available on request by the Milter application). 
Different
	macros are available at different Milter protocol stages (EOH = 
end-of-header,
	EOM = end-of-message); their availability is not always the same as 
in

Sendmail. See the workarounds section below for solutions.


	|Sendmail macro  |Milter protocol stage|Description   
|
	|| |  
|
	|i   |DATA, EOH, EOM   |Queue ID, also 
Postfix|
	|| |queue file name   
|
	|| |  
|


And in the "Workarounds" section



  The problem is that Milter applications expect that the queue ID is 
known
  before the MTA accepts the MAIL FROM (sender) command. Postfix does 
not
  choose a queue ID, which is used as the queue file name, until after 
it

  accepts the first valid RCPT TO (recipient) command.



However:

# postconf -d milter_rcpt_macros
milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer}


Also, the setting "smtpd_delay_open_until_valid_rcpt = no" assures that 
the queue ID is known at RCPT time, making it possible for Postfix to 
provide it to milters as the default setting says it will.


( Complicating matters, the only milter I use, MIMEDefang, seems to have 
internalized the principle that Postfix will never tell it an ID at RCPT 
time. Hurrah for implementation-agnostic standard APIs... )

Re: spam fighting

[Terry Barnum]

> On Apr 28, 2015, at 1:47 AM, Marius Gologan  wrote:
> 
> Hi Terry,
> 
> I use amavisd-new/spamassassin in post-queue configuration with few
> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
> Bayes_95, Bayes_99, Bayes_999 and few others.
> Local DNS server - critical for RBL queries.
> As for postscreen, I preffer "postscreen_greet_action = enforce" only which
> doesn't require the client to retry (as opposite to greylist behavior),
> while is pretty effective against bots.
> 
> Marius.

Thank you for the reply Marius. Do the RBL queries from 
amavisd-new/spamassassin require a local DNS because they're more resource 
intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?

I've received 16 UCE emails in the last hour--weight loss, wrinkle creams, bird 
feeders, pharmacies. More pointers (favorite postfix techniques and/or add-ons, 
sites to read, etc.) from those who've been successful in reducing spam load 
are greatly appreciated.

Thanks,
-Terry

> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
> Sent: Tuesday, April 28, 2015 1:15 AM
> To: postfix users
> Subject: spam fighting
> 
> We've been using postscreen and dspam for quite some time but in the past
> couple months more spam is making it through. I realize there's no
> one-size-fits-all approach but because dspam isn't actively developed
> anymore I've started looking around and am curious what others are using. Is
> amavisd-new/spamassassin the preferred solution? My company is small with
> <30 users.
> 
> Perhaps my postscreen settings could be improved? postscreen_access.cidr is
> a small file with 4 entries to whitelist customers that aren't implicated in
> the increase in spam.
> 
> $ postconf -n
> broken_sasl_auth_clients = yes
> command_directory = /opt/local/sbin
> daemon_directory = /opt/local/libexec/postfix
> data_directory = /opt/local/var/lib/postfix
> debugger_command =
> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
> $daemon_directory/$process_name $process_id & sleep 5
> default_privs = nobody
> delay_warning_time = 4h
> dovecot_destination_recipient_limit = 1
> dspam-lmtp_destination_recipient_limit = 1
> home_mailbox = Maildir/
> html_directory = no
> inet_protocols = ipv4
> mail_owner = _postfix
> mailq_path = /opt/local/bin/mailq
> manpage_directory = /opt/local/share/man
> message_size_limit = 5120
> mydestination = $myhostname, localhost.$mydomain, localhost
> myhostname = mailbox.dop.com
> mynetworks = 192.168.0.0/23, 127.0.0.0/8
> myorigin = $mydomain
> newaliases_path = /opt/local/bin/newaliases
> postscreen_access_list = permit_mynetworks,
> cidr:/opt/local/etc/postfix/postscreen_access.cidr
> postscreen_bare_newline_action = enforce
> postscreen_bare_newline_enable = yes
> postscreen_blacklist_action = drop
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = 
> b.barracudacentral.org=127.0.0.2*7 
> dnsbl.inps.de=127.0.0.2*7 
> bl.mailspike.net=127.0.0.2*5 
> bl.mailspike.net=127.0.0.[10;11;12]*4 
> dnsbl.sorbs.net=127.0.0.10*8 
> dnsbl.sorbs.net=127.0.0.5*6 
> dnsbl.sorbs.net=127.0.0.7*3 
> dnsbl.sorbs.net=127.0.0.8*2 
> dnsbl.sorbs.net=127.0.0.6*2 
> dnsbl.sorbs.net=127.0.0.9*2 
> zen.spamhaus.org=127.0.0.[10;11]*8 
> zen.spamhaus.org=127.0.0.[4..7]*6 
> zen.spamhaus.org=127.0.0.3*4 
> zen.spamhaus.org=127.0.0.2*3 
> hostkarma.junkemailfilter.com=127.0.0.2*3 
> hostkarma.junkemailfilter.com=127.0.0.4*1 
> hostkarma.junkemailfilter.com=127.0.1.2*1 
> wl.mailspike.net=127.0.0.[18;19;20]*-2 
> list.dnswl.org=127.0.[0..255].0*-2 
> list.dnswl.org=127.0.[0..255].1*-3 
> list.dnswl.org=127.0.[0..255].2*-4 
> list.dnswl.org=127.0.[0..255].3*-5 
> hostkarma.junkemailfilter.com=127.0.0.1*-2
> postscreen_dnsbl_threshold = 3
> postscreen_dnsbl_ttl = 5m
> postscreen_greet_action = enforce
> postscreen_non_smtp_command_enable = yes
> postscreen_pipelining_action = enforce
> postscreen_pipelining_enable = yes
> proxy_interfaces = 70.167.15.110
> queue_directory = /opt/local/var/spool/postfix
> readme_directory = /opt/local/share/postfix/readme
> sample_directory = /opt/local/share/postfix/sample
> sendmail_path = /opt/local/sbin/sendmail
> setgid_group = _postdrop
> smtpd_banner = $myhostname ESMTP $mail_name
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
> reject_non_fqdn_helo_hostname
> smtpd_recipient_restrictions = 
> permit_mynetworks,
> permit_sasl_authenticated, 
> reject_non_fqdn_sender, 
> reject_non_fqdn_recipient, 
> reject_unknown_sender_domain, 
> reject_unknown_recipient_domain, 
> reject_unauth_pipelining, 
> reject_unauth_destination, 
> reject_unlisted_recipient, 
> check_recipient_access pcre:/opt/local/etc/postfix/recipient_checks.pcre, 
> check_helo_access hash:/opt/local/etc/postfix/helo_checks, 
> check_sender_access hash:/opt/local/etc/postfix/sender_checks, 
> check_client_access hash:/opt/local

Re: Conversation with x.x.x.x[x.x.x.x] timed out while sending end of data

[Wietse Venema]

Kristjan Nii:
> Thank you for your response!
> I viewed the some emails in the queue and did not see DKIM signatures in
> them. Also, our network guys confirmed, that ASA version is 7.3, which
> should be bug-free.
> Any other ideas or things I should/could check and test?

Other issues may have to do with broken IP path MTU discovery
(which an be worked around by turning that off in the sender's
TCP/IP stack), or broken window scaling, or some other bug.
This can be diagnosed by looking at a packet recording.

And one should not exclude the possibility that your email 
is blocked by some firewalling rule, which will have te same
result that packets are silently discarded.

Wietse

Re: ERRATA(?): MILTER_README

[Wietse Venema]

Bill Cole:
> Also, the setting "smtpd_delay_open_until_valid_rcpt = no" assures that 
> the queue ID is known at RCPT time, making it possible for Postfix to 
> provide it to milters as the default setting says it will.

This is not the default because it can increase queue activity by
an order of magnitude or more, at least for servers that reject the
majority of all mail delivery requests (creating and deleting queue
files is by far the most expensive part of Postfix queue management).

In the time since that text in MILTER_README was written, Milter
applications have been written to handle the case that {i} is not
available before the DATA command.

Wietse

Re: Stan Hoeppner's fqrdns.pcre file?

[Quanah Gibson-Mount]

--On Monday, April 27, 2015 10:10 PM -0700 Steve Jenkins 
 wrote:



I don't know when Stan did his final update, but if anyone has one newer
than Mar 27 2013, please send it to me off-list and I'll update it.


Hi Steve,

I had just set this up on March 11, 2015.  The version I downloaded at that 
time has a timestamp of:


# Postfix PCRE bot spam killer
#
# Updated 10/2/2014
#

If you want a copy, let me know.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: spam fighting

[CSS]

On Apr 28, 2015, at 1:04 PM, Terry Barnum  wrote:

>> 
>> On Apr 28, 2015, at 1:47 AM, Marius Gologan  wrote:
>> 
>> Hi Terry,
>> 
>> I use amavisd-new/spamassassin in post-queue configuration with few
>> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
>> Bayes_95, Bayes_99, Bayes_999 and few others.
>> Local DNS server - critical for RBL queries.
>> As for postscreen, I preffer "postscreen_greet_action = enforce" only which
>> doesn't require the client to retry (as opposite to greylist behavior),
>> while is pretty effective against bots.
>> 
>> Marius.
> 
> Thank you for the reply Marius. Do the RBL queries from 
> amavisd-new/spamassassin require a local DNS because they're more resource 
> intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?

Regarding DNS lookups, depending on your mail volume, between postscreen, 
spamassassin and whatever else you’re running, you can generate quite a few 
queries on every connection attempt.  Depending on your overall architecture, 
having a dedicated recursor instance (or two or three) can really help.  You 
don’t want a large influx of email to have an impact on other consumers of DNS 
lookups.

I really like PowerDNS (recursor), as it’s quite efficient - at one point I had 
it running on an ancient dual P-III box and peaked at 10K queries/second, which 
was about double what I could achieve on the same hardware with dnscache 
(djbdns).  BIND is probably not at all appropriate for this (but may be perfect 
for other internal use where you need more features).

Charles

> 
> I've received 16 UCE emails in the last hour--weight loss, wrinkle creams, 
> bird feeders, pharmacies. More pointers (favorite postfix techniques and/or 
> add-ons, sites to read, etc.) from those who've been successful in reducing 
> spam load are greatly appreciated.
> 
> Thanks,
> -Terry
> 
>> -Original Message-
>> From: owner-postfix-us...@postfix.org
>> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
>> Sent: Tuesday, April 28, 2015 1:15 AM
>> To: postfix users
>> Subject: spam fighting
>> 
>> We've been using postscreen and dspam for quite some time but in the past
>> couple months more spam is making it through. I realize there's no
>> one-size-fits-all approach but because dspam isn't actively developed
>> anymore I've started looking around and am curious what others are using. Is
>> amavisd-new/spamassassin the preferred solution? My company is small with
>> <30 users.
>> 
>> Perhaps my postscreen settings could be improved? postscreen_access.cidr is
>> a small file with 4 entries to whitelist customers that aren't implicated in
>> the increase in spam.
>> 
>> $ postconf -n
>> broken_sasl_auth_clients = yes
>> command_directory = /opt/local/sbin
>> daemon_directory = /opt/local/libexec/postfix
>> data_directory = /opt/local/var/lib/postfix
>> debugger_command =
>> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
>> $daemon_directory/$process_name $process_id & sleep 5
>> default_privs = nobody
>> delay_warning_time = 4h
>> dovecot_destination_recipient_limit = 1
>> dspam-lmtp_destination_recipient_limit = 1
>> home_mailbox = Maildir/
>> html_directory = no
>> inet_protocols = ipv4
>> mail_owner = _postfix
>> mailq_path = /opt/local/bin/mailq
>> manpage_directory = /opt/local/share/man
>> message_size_limit = 5120
>> mydestination = $myhostname, localhost.$mydomain, localhost
>> myhostname = mailbox.dop.com
>> mynetworks = 192.168.0.0/23, 127.0.0.0/8
>> myorigin = $mydomain
>> newaliases_path = /opt/local/bin/newaliases
>> postscreen_access_list = permit_mynetworks,
>> cidr:/opt/local/etc/postfix/postscreen_access.cidr
>> postscreen_bare_newline_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_blacklist_action = drop
>> postscreen_dnsbl_action = enforce
>> postscreen_dnsbl_sites = 
>> b.barracudacentral.org=127.0.0.2*7 
>> dnsbl.inps.de=127.0.0.2*7 
>> bl.mailspike.net=127.0.0.2*5 
>> bl.mailspike.net=127.0.0.[10;11;12]*4 
>> dnsbl.sorbs.net=127.0.0.10*8 
>> dnsbl.sorbs.net=127.0.0.5*6 
>> dnsbl.sorbs.net=127.0.0.7*3 
>> dnsbl.sorbs.net=127.0.0.8*2 
>> dnsbl.sorbs.net=127.0.0.6*2 
>> dnsbl.sorbs.net=127.0.0.9*2 
>> zen.spamhaus.org=127.0.0.[10;11]*8 
>> zen.spamhaus.org=127.0.0.[4..7]*6 
>> zen.spamhaus.org=127.0.0.3*4 
>> zen.spamhaus.org=127.0.0.2*3 
>> hostkarma.junkemailfilter.com=127.0.0.2*3 
>> hostkarma.junkemailfilter.com=127.0.0.4*1 
>> hostkarma.junkemailfilter.com=127.0.1.2*1 
>> wl.mailspike.net=127.0.0.[18;19;20]*-2 
>> list.dnswl.org=127.0.[0..255].0*-2 
>> list.dnswl.org=127.0.[0..255].1*-3 
>> list.dnswl.org=127.0.[0..255].2*-4 
>> list.dnswl.org=127.0.[0..255].3*-5 
>> hostkarma.junkemailfilter.com=127.0.0.1*-2
>> postscreen_dnsbl_threshold = 3
>> postscreen_dnsbl_ttl = 5m
>> postscreen_greet_action = enforce
>> postscreen_non_smtp_command_enable = yes
>> postscreen_pipelining_action = enforce
>> postscreen_pipelining_enable = yes
>> proxy_interfaces = 70.167.1

Re: ERRATA(?): MILTER_README

[Bill Cole]

On 28 Apr 2015, at 13:30, Wietse Venema wrote:


Bill Cole:
Also, the setting "smtpd_delay_open_until_valid_rcpt = no" assures 
that

the queue ID is known at RCPT time, making it possible for Postfix to
provide it to milters as the default setting says it will.


This is not the default because it can increase queue activity by
an order of magnitude or more, at least for servers that reject the
majority of all mail delivery requests (creating and deleting queue
files is by far the most expensive part of Postfix queue management).


Understood. I'm not arguing against that default, which is important for 
machines that have substantial volume and don't turn away most of it 
with postscreen. However, the existence of postscreen has substantially 
expanded the range of sites where the disk-thrashing risk of 
"smtpd_delay_open_until_valid_rcpt = no" is small enough to be worth 
gaining deterministic log correlation.



In the time since that text in MILTER_README was written, Milter
applications have been written to handle the case that {i} is not
available before the DATA command.


Yes, but that text in conjunction with the table of macro availability 
has apparently led to at least one Milter application (MIMEDefang) to be 
written to presume the unconditional unavailability of {i} at RCPT in 
all cases, even though {i} is provided for all recipients when 
smtpd_delay_open_until_valid_rcpt = no and apparently (based on the 
default milter_rcpt_macros) also would be for recipients subsequent to 
Postfix accepting a valid one for the message with the default setting.


Are you are willing to consider changing MILTER_README to more precisely 
describe that conditional availability of {i} if I propose specific 
wording?

Re: Stan Hoeppner's fqrdns.pcre file?

[DTNX Postmaster]

On 28 Apr 2015, at 18:04, Alex Regan  wrote:

> Hi,
> 
>>I should have mentioned that I actually did that, once I couldn't
>>find Stan's site:
>> 
>>https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre
>> 
>> 
>> For those who are using it, I've replaced it with a version from March
>> 2013 instead of March 2012.
>> 
>> https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre
>> 
>> I don't know when Stan did his final update, but if anyone has one newer
>> than Mar 27 2013, please send it to me off-list and I'll update it.
> 
> I've forwarded to Steve my version from Oct 2014, but also just happened 
> across this, from Stan, in 2012:
> 
> http://postfix.1071664.n5.nabble.com/postscreen-supersedes-fqrdns-pcre-table-td46419.html
> 
> As we all look to utilize every mechanism possible in the fight against spam, 
> perhaps this list is now too rudimentary and antiquated to be used any longer?

Postscreen certainly made a dent, but we have always had it in use as a 
HELO blacklist, turned out to be more effective in terms of false 
positives than filtering it on the reverse lookup for the IP address.

What mostly superseded it for us is running our own DNS-based 
blacklists for IPv4, reverse DNS, and HELO hostnames. It still catches 
stuff, though. Mostly a few complex RDNS patterns that don't easily fit 
into a rbldnsd-based list.

Oh, and they are patterns that rarely change, once they are set.

Probably not a bad idea to clean it up a bit at some point, but as long 
as it's not causing any problems and still rejecting garbage, well ... 
not that high on the prio list :-)

Mvg,
Joni

RE: spam fighting

[Marius Gologan]

Shared DNS as Google's 8.8.8.8 is not accepted by some RBLs such as
spamhaus. They have an ACL in place.
You will lose about 2 points from Spam scoring when you use a public DNS
causing some spam to pass.

Spamassassin (SA) uses many RBL services checking Domain & IP of the Sender;
Domains, IPs and Name Servers in URLs. One email may generate even more than
10 RBL queries. Due that, SA has a protection in order to prevent flooding
those service providers. You may consider reducing the amavis throttle from
Postfix's master.cf, by reducing the no of processes.
In addition, network tests such as Pyzor, Razor2 and DCC require these ports
to be opened: out 6277 UDP - DCC service, out 2703 TCP - Razor2 service, out
24441 UDP - Pyzor service.

I heard many saying that Spamassassin is weak, while they don't understand
how it works.

Bottom line, a machine with 2 GB of RAM can easily handle 10k-15k messages a
day.

-Original Message-
From: Terry Barnum [mailto:te...@dop.com] 
Sent: Tuesday, April 28, 2015 8:04 PM
To: Marius Gologan
Cc: postfix users
Subject: Re: spam fighting


> On Apr 28, 2015, at 1:47 AM, Marius Gologan 
wrote:
> 
> Hi Terry,
> 
> I use amavisd-new/spamassassin in post-queue configuration with few
> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
> Bayes_95, Bayes_99, Bayes_999 and few others.
> Local DNS server - critical for RBL queries.
> As for postscreen, I preffer "postscreen_greet_action = enforce" only
which
> doesn't require the client to retry (as opposite to greylist behavior),
> while is pretty effective against bots.
> 
> Marius.

Thank you for the reply Marius. Do the RBL queries from
amavisd-new/spamassassin require a local DNS because they're more resource
intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?

I've received 16 UCE emails in the last hour--weight loss, wrinkle creams,
bird feeders, pharmacies. More pointers (favorite postfix techniques and/or
add-ons, sites to read, etc.) from those who've been successful in reducing
spam load are greatly appreciated.

Thanks,
-Terry

> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
> Sent: Tuesday, April 28, 2015 1:15 AM
> To: postfix users
> Subject: spam fighting
> 
> We've been using postscreen and dspam for quite some time but in the past
> couple months more spam is making it through. I realize there's no
> one-size-fits-all approach but because dspam isn't actively developed
> anymore I've started looking around and am curious what others are using.
Is
> amavisd-new/spamassassin the preferred solution? My company is small with
> <30 users.
> 
> Perhaps my postscreen settings could be improved? postscreen_access.cidr
is
> a small file with 4 entries to whitelist customers that aren't implicated
in
> the increase in spam.
> 
> $ postconf -n
> broken_sasl_auth_clients = yes
> command_directory = /opt/local/sbin
> daemon_directory = /opt/local/libexec/postfix
> data_directory = /opt/local/var/lib/postfix
> debugger_command =
> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
> $daemon_directory/$process_name $process_id & sleep 5
> default_privs = nobody
> delay_warning_time = 4h
> dovecot_destination_recipient_limit = 1
> dspam-lmtp_destination_recipient_limit = 1
> home_mailbox = Maildir/
> html_directory = no
> inet_protocols = ipv4
> mail_owner = _postfix
> mailq_path = /opt/local/bin/mailq
> manpage_directory = /opt/local/share/man
> message_size_limit = 5120
> mydestination = $myhostname, localhost.$mydomain, localhost
> myhostname = mailbox.dop.com
> mynetworks = 192.168.0.0/23, 127.0.0.0/8
> myorigin = $mydomain
> newaliases_path = /opt/local/bin/newaliases
> postscreen_access_list = permit_mynetworks,
> cidr:/opt/local/etc/postfix/postscreen_access.cidr
> postscreen_bare_newline_action = enforce
> postscreen_bare_newline_enable = yes
> postscreen_blacklist_action = drop
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = 
> b.barracudacentral.org=127.0.0.2*7 
> dnsbl.inps.de=127.0.0.2*7 
> bl.mailspike.net=127.0.0.2*5 
> bl.mailspike.net=127.0.0.[10;11;12]*4 
> dnsbl.sorbs.net=127.0.0.10*8 
> dnsbl.sorbs.net=127.0.0.5*6 
> dnsbl.sorbs.net=127.0.0.7*3 
> dnsbl.sorbs.net=127.0.0.8*2 
> dnsbl.sorbs.net=127.0.0.6*2 
> dnsbl.sorbs.net=127.0.0.9*2 
> zen.spamhaus.org=127.0.0.[10;11]*8 
> zen.spamhaus.org=127.0.0.[4..7]*6 
> zen.spamhaus.org=127.0.0.3*4 
> zen.spamhaus.org=127.0.0.2*3 
> hostkarma.junkemailfilter.com=127.0.0.2*3 
> hostkarma.junkemailfilter.com=127.0.0.4*1 
> hostkarma.junkemailfilter.com=127.0.1.2*1 
> wl.mailspike.net=127.0.0.[18;19;20]*-2 
> list.dnswl.org=127.0.[0..255].0*-2 
> list.dnswl.org=127.0.[0..255].1*-3 
> list.dnswl.org=127.0.[0..255].2*-4 
> list.dnswl.org=127.0.[0..255].3*-5 
> hostkarma.junkemailfilter.com=127.0.0.1*-2
> postscreen_dnsbl_threshold = 3
> postscreen_dnsbl_ttl = 5m
> postscreen_greet_action = enforce
> postscreen_no

RE: spam fighting

[Marius Gologan]

To be more specific about using a notorious DNS such as Google's
8.8.8.8(4.4):
When many uses that DNS for RBL, Google queries the RBL from different IP
pools (IPv4 and IPv6) and not from 8.8.8.8(4.4) as some might think.
As a result, the popular provider has the "feeling" of a constant DNS DDoS
attack from those IP pools.

-Original Message-
From: Marius Gologan [mailto:marius.golo...@gmail.com] 
Sent: Tuesday, April 28, 2015 10:34 PM
To: 'Terry Barnum'
Cc: 'postfix users'
Subject: RE: spam fighting

Shared DNS as Google's 8.8.8.8 is not accepted by some RBLs such as
spamhaus. They have an ACL in place.
You will lose about 2 points from Spam scoring when you use a public DNS
causing some spam to pass.

Spamassassin (SA) uses many RBL services checking Domain & IP of the Sender;
Domains, IPs and Name Servers in URLs. One email may generate even more than
10 RBL queries. Due that, SA has a protection in order to prevent flooding
those service providers. You may consider reducing the amavis throttle from
Postfix's master.cf, by reducing the no of processes.
In addition, network tests such as Pyzor, Razor2 and DCC require these ports
to be opened: out 6277 UDP - DCC service, out 2703 TCP - Razor2 service, out
24441 UDP - Pyzor service.

I heard many saying that Spamassassin is weak, while they don't understand
how it works.

Bottom line, a machine with 2 GB of RAM can easily handle 10k-15k messages a
day.

-Original Message-
From: Terry Barnum [mailto:te...@dop.com] 
Sent: Tuesday, April 28, 2015 8:04 PM
To: Marius Gologan
Cc: postfix users
Subject: Re: spam fighting


> On Apr 28, 2015, at 1:47 AM, Marius Gologan 
wrote:
> 
> Hi Terry,
> 
> I use amavisd-new/spamassassin in post-queue configuration with few
> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
> Bayes_95, Bayes_99, Bayes_999 and few others.
> Local DNS server - critical for RBL queries.
> As for postscreen, I preffer "postscreen_greet_action = enforce" only
which
> doesn't require the client to retry (as opposite to greylist behavior),
> while is pretty effective against bots.
> 
> Marius.

Thank you for the reply Marius. Do the RBL queries from
amavisd-new/spamassassin require a local DNS because they're more resource
intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?

I've received 16 UCE emails in the last hour--weight loss, wrinkle creams,
bird feeders, pharmacies. More pointers (favorite postfix techniques and/or
add-ons, sites to read, etc.) from those who've been successful in reducing
spam load are greatly appreciated.

Thanks,
-Terry

> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
> Sent: Tuesday, April 28, 2015 1:15 AM
> To: postfix users
> Subject: spam fighting
> 
> We've been using postscreen and dspam for quite some time but in the past
> couple months more spam is making it through. I realize there's no
> one-size-fits-all approach but because dspam isn't actively developed
> anymore I've started looking around and am curious what others are using.
Is
> amavisd-new/spamassassin the preferred solution? My company is small with
> <30 users.
> 
> Perhaps my postscreen settings could be improved? postscreen_access.cidr
is
> a small file with 4 entries to whitelist customers that aren't implicated
in
> the increase in spam.
> 
> $ postconf -n
> broken_sasl_auth_clients = yes
> command_directory = /opt/local/sbin
> daemon_directory = /opt/local/libexec/postfix
> data_directory = /opt/local/var/lib/postfix
> debugger_command =
> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
> $daemon_directory/$process_name $process_id & sleep 5
> default_privs = nobody
> delay_warning_time = 4h
> dovecot_destination_recipient_limit = 1
> dspam-lmtp_destination_recipient_limit = 1
> home_mailbox = Maildir/
> html_directory = no
> inet_protocols = ipv4
> mail_owner = _postfix
> mailq_path = /opt/local/bin/mailq
> manpage_directory = /opt/local/share/man
> message_size_limit = 5120
> mydestination = $myhostname, localhost.$mydomain, localhost
> myhostname = mailbox.dop.com
> mynetworks = 192.168.0.0/23, 127.0.0.0/8
> myorigin = $mydomain
> newaliases_path = /opt/local/bin/newaliases
> postscreen_access_list = permit_mynetworks,
> cidr:/opt/local/etc/postfix/postscreen_access.cidr
> postscreen_bare_newline_action = enforce
> postscreen_bare_newline_enable = yes
> postscreen_blacklist_action = drop
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = 
> b.barracudacentral.org=127.0.0.2*7 
> dnsbl.inps.de=127.0.0.2*7 
> bl.mailspike.net=127.0.0.2*5 
> bl.mailspike.net=127.0.0.[10;11;12]*4 
> dnsbl.sorbs.net=127.0.0.10*8 
> dnsbl.sorbs.net=127.0.0.5*6 
> dnsbl.sorbs.net=127.0.0.7*3 
> dnsbl.sorbs.net=127.0.0.8*2 
> dnsbl.sorbs.net=127.0.0.6*2 
> dnsbl.sorbs.net=127.0.0.9*2 
> zen.spamhaus.org=127.0.0.[10;11]*8 
> zen.spamhaus.org=127.0.0.[4..7]*6 
> zen.spamhaus.org=127.0.0.3*4 
> z

Re: spam fighting

[Terry Barnum]

> On Apr 28, 2015, at 12:33 PM, Marius Gologan  wrote:
> 
> Shared DNS as Google's 8.8.8.8 is not accepted by some RBLs such as
> spamhaus. They have an ACL in place.
> You will lose about 2 points from Spam scoring when you use a public DNS
> causing some spam to pass.

Thank you Marius! I did not know that using Google's DNS would reduce or remove 
the points scoring for postscreen RBLs. I now see this small blurb on the 
spamhaus faq: 

This is likely a huge contributor to our spam increase since spamhaus return a 
"not listed" when using a public DNS.

> Spamassassin (SA) uses many RBL services checking Domain & IP of the Sender;
> Domains, IPs and Name Servers in URLs. One email may generate even more than
> 10 RBL queries. Due that, SA has a protection in order to prevent flooding
> those service providers. You may consider reducing the amavis throttle from
> Postfix's master.cf, by reducing the no of processes.
> In addition, network tests such as Pyzor, Razor2 and DCC require these ports
> to be opened: out 6277 UDP - DCC service, out 2703 TCP - Razor2 service, out
> 24441 UDP - Pyzor service.

Do most who use postfix/amavisd-new/spamassassin also use shared services like 
pyzor?

> I heard many saying that Spamassassin is weak, while they don't understand
> how it works.
> 
> Bottom line, a machine with 2 GB of RAM can easily handle 10k-15k messages a
> day.

Good info to hear.

Thanks,
-Terry


> -Original Message-
> From: Terry Barnum [mailto:te...@dop.com] 
> Sent: Tuesday, April 28, 2015 8:04 PM
> To: Marius Gologan
> Cc: postfix users
> Subject: Re: spam fighting
> 
> 
>> On Apr 28, 2015, at 1:47 AM, Marius Gologan 
> wrote:
>> 
>> Hi Terry,
>> 
>> I use amavisd-new/spamassassin in post-queue configuration with few
>> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, Bayes_80,
>> Bayes_95, Bayes_99, Bayes_999 and few others.
>> Local DNS server - critical for RBL queries.
>> As for postscreen, I preffer "postscreen_greet_action = enforce" only
> which
>> doesn't require the client to retry (as opposite to greylist behavior),
>> while is pretty effective against bots.
>> 
>> Marius.
> 
> Thank you for the reply Marius. Do the RBL queries from
> amavisd-new/spamassassin require a local DNS because they're more resource
> intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?
> 
> I've received 16 UCE emails in the last hour--weight loss, wrinkle creams,
> bird feeders, pharmacies. More pointers (favorite postfix techniques and/or
> add-ons, sites to read, etc.) from those who've been successful in reducing
> spam load are greatly appreciated.
> 
> Thanks,
> -Terry
> 
>> -Original Message-
>> From: owner-postfix-us...@postfix.org
>> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
>> Sent: Tuesday, April 28, 2015 1:15 AM
>> To: postfix users
>> Subject: spam fighting
>> 
>> We've been using postscreen and dspam for quite some time but in the past
>> couple months more spam is making it through. I realize there's no
>> one-size-fits-all approach but because dspam isn't actively developed
>> anymore I've started looking around and am curious what others are using.
> Is
>> amavisd-new/spamassassin the preferred solution? My company is small with
>> <30 users.
>> 
>> Perhaps my postscreen settings could be improved? postscreen_access.cidr
> is
>> a small file with 4 entries to whitelist customers that aren't implicated
> in
>> the increase in spam.
>> 
>> $ postconf -n
>> broken_sasl_auth_clients = yes
>> command_directory = /opt/local/sbin
>> daemon_directory = /opt/local/libexec/postfix
>> data_directory = /opt/local/var/lib/postfix
>> debugger_command =
>> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
>> $daemon_directory/$process_name $process_id & sleep 5
>> default_privs = nobody
>> delay_warning_time = 4h
>> dovecot_destination_recipient_limit = 1
>> dspam-lmtp_destination_recipient_limit = 1
>> home_mailbox = Maildir/
>> html_directory = no
>> inet_protocols = ipv4
>> mail_owner = _postfix
>> mailq_path = /opt/local/bin/mailq
>> manpage_directory = /opt/local/share/man
>> message_size_limit = 5120
>> mydestination = $myhostname, localhost.$mydomain, localhost
>> myhostname = mailbox.dop.com
>> mynetworks = 192.168.0.0/23, 127.0.0.0/8
>> myorigin = $mydomain
>> newaliases_path = /opt/local/bin/newaliases
>> postscreen_access_list = permit_mynetworks,
>> cidr:/opt/local/etc/postfix/postscreen_access.cidr
>> postscreen_bare_newline_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_blacklist_action = drop
>> postscreen_dnsbl_action = enforce
>> postscreen_dnsbl_sites = 
>> b.barracudacentral.org=127.0.0.2*7 
>> dnsbl.inps.de=127.0.0.2*7 
>> bl.mailspike.net=127.0.0.2*5 
>> bl.mailspike.net=127.0.0.[10;11;12]*4 
>> dnsbl.sorbs.net=127.0.0.10*8 
>> dnsbl.sorbs.net=127.0.0.5*6 
>> dnsbl.sorbs.net=127.0.0.7*3 
>> dnsbl.sorbs.net=127.0.0.8*2 
>

RE: spam fighting

[Marius Gologan]

I don't know about others, but Pyzor is quite accurate in my experience. I
think I will increase its score because, for example, most Russian spam
don't include links.
Pyzor is generating a digest key based on the content which is checked
against a database. In return, it gets two values: positive and negative
reports/complaints. Based on that, Pyzor decides the likelihood of spam, but
the default score in SA is low, between 0.5 - 1.5 (aprox.), not a decisive
one.
You can install your own local Pyzor and RBL servers (package rbldnsd), but
you'll need ... data. I use the second one to manually block or whitelist
certain Domains, IPs and Name Servers (mostly private).


-Original Message-
From: Terry Barnum [mailto:te...@dop.com] 
Sent: Tuesday, April 28, 2015 11:08 PM
To: Marius Gologan
Cc: postfix users
Subject: Re: spam fighting


> On Apr 28, 2015, at 12:33 PM, Marius Gologan 
wrote:
> 
> Shared DNS as Google's 8.8.8.8 is not accepted by some RBLs such as 
> spamhaus. They have an ACL in place.
> You will lose about 2 points from Spam scoring when you use a public 
> DNS causing some spam to pass.

Thank you Marius! I did not know that using Google's DNS would reduce or
remove the points scoring for postscreen RBLs. I now see this small blurb on
the spamhaus faq: 

This is likely a huge contributor to our spam increase since spamhaus return
a "not listed" when using a public DNS.

> Spamassassin (SA) uses many RBL services checking Domain & IP of the 
> Sender; Domains, IPs and Name Servers in URLs. One email may generate 
> even more than
> 10 RBL queries. Due that, SA has a protection in order to prevent 
> flooding those service providers. You may consider reducing the amavis 
> throttle from Postfix's master.cf, by reducing the no of processes.
> In addition, network tests such as Pyzor, Razor2 and DCC require these 
> ports to be opened: out 6277 UDP - DCC service, out 2703 TCP - Razor2 
> service, out
> 24441 UDP - Pyzor service.

Do most who use postfix/amavisd-new/spamassassin also use shared services
like pyzor?

> I heard many saying that Spamassassin is weak, while they don't 
> understand how it works.
> 
> Bottom line, a machine with 2 GB of RAM can easily handle 10k-15k 
> messages a day.

Good info to hear.

Thanks,
-Terry


> -Original Message-
> From: Terry Barnum [mailto:te...@dop.com]
> Sent: Tuesday, April 28, 2015 8:04 PM
> To: Marius Gologan
> Cc: postfix users
> Subject: Re: spam fighting
> 
> 
>> On Apr 28, 2015, at 1:47 AM, Marius Gologan 
>> 
> wrote:
>> 
>> Hi Terry,
>> 
>> I use amavisd-new/spamassassin in post-queue configuration with few
>> adjustments: increased score for SPF_FAIL, DKIM_ADSP_DISCARD, 
>> Bayes_80, Bayes_95, Bayes_99, Bayes_999 and few others.
>> Local DNS server - critical for RBL queries.
>> As for postscreen, I preffer "postscreen_greet_action = enforce" only
> which
>> doesn't require the client to retry (as opposite to greylist 
>> behavior), while is pretty effective against bots.
>> 
>> Marius.
> 
> Thank you for the reply Marius. Do the RBL queries from 
> amavisd-new/spamassassin require a local DNS because they're more 
> resource intensive than postscreen_dnsbl_sites or reject_rhsbl_* queries?
> 
> I've received 16 UCE emails in the last hour--weight loss, wrinkle 
> creams, bird feeders, pharmacies. More pointers (favorite postfix 
> techniques and/or add-ons, sites to read, etc.) from those who've been 
> successful in reducing spam load are greatly appreciated.
> 
> Thanks,
> -Terry
> 
>> -Original Message-
>> From: owner-postfix-us...@postfix.org 
>> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Terry Barnum
>> Sent: Tuesday, April 28, 2015 1:15 AM
>> To: postfix users
>> Subject: spam fighting
>> 
>> We've been using postscreen and dspam for quite some time but in the 
>> past couple months more spam is making it through. I realize there's 
>> no one-size-fits-all approach but because dspam isn't actively 
>> developed anymore I've started looking around and am curious what others
are using.
> Is
>> amavisd-new/spamassassin the preferred solution? My company is small 
>> with
>> <30 users.
>> 
>> Perhaps my postscreen settings could be improved? 
>> postscreen_access.cidr
> is
>> a small file with 4 entries to whitelist customers that aren't 
>> implicated
> in
>> the increase in spam.
>> 
>> $ postconf -n
>> broken_sasl_auth_clients = yes
>> command_directory = /opt/local/sbin
>> daemon_directory = /opt/local/libexec/postfix data_directory = 
>> /opt/local/var/lib/postfix debugger_command = 
>> PATH=/opt/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
>> $daemon_directory/$process_name $process_id & sleep 5 default_privs = 
>> nobody delay_warning_time = 4h dovecot_destination_recipient_limit = 
>> 1 dspam-lmtp_destination_recipient_limit = 1 home_mailbox = Maildir/ 
>> html_directory = no inet_protocols = ipv4 mail_owner = _postfix 
>> mailq_pa

Re: Stan Hoeppner's fqrdns.pcre file?

[Steve Jenkins]

On Tue, Apr 28, 2015 at 10:50 AM, Quanah Gibson-Mount 
wrote:

> Hi Steve,
>
> I had just set this up on March 11, 2015.  The version I downloaded at
> that time has a timestamp of:
>
> # Postfix PCRE bot spam killer
> #
> # Updated 10/2/2014
> #


Thanks, Quanah. That's actually the version I have up there now. :)

https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/blob/master/fqrdns.pcre

Interesting to click the history button and see that it didn't really
change all that much from 2012-2014.

SteveJ

Re: Stan Hoeppner's fqrdns.pcre file?

[Terry Barnum]

> On Apr 28, 2015, at 1:31 PM, Steve Jenkins  wrote:

> https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/blob/master/fqrdns.pcre
> 
> Interesting to click the history button and see that it didn't really change 
> all that much from 2012-2014.
> 
> SteveJ

github URL for curl:

$ curl 
https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre

Terry Barnum
digital OutPost
http://www.dop.com

Re: Stan Hoeppner's fqrdns.pcre file?

[Steve Jenkins]

On Tue, Apr 28, 2015 at 2:13 PM, Terry Barnum  wrote:

> github URL for curl:
>
> $ curl
> https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre


Thanks, Terry. The same URL will also work for a wget, and I recommend
using the -N option for timestamping (will only download if remote file is
newer):

$ /usr/bin/wget -q -N -P /etc/postfix
https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre

I've also noticed that on my older systems I have have to bypass the
certificate check to avoid a "certificate common name" error:

$ /usr/bin/wget --no-check-certificate -q -N -P /etc/postfix
https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre

SteveJ

Question wrt partial migration from old postfix to newer one on two servers

[Jérôme Alet]

Hello,

As a part of our existing mail setup we've got something like this :

  Internet ==> MX ==> Server1 ==> Backend1
  Internet <== Server1 <== Backend1

Backend1 handles SMTP authentication and is used as the end users' SMTP
server in their MUAs whenever they want to send emails to anywhere (even
internally). When sending, Backend1 forwards to Server1 which sends to
the Internet or sends back to Backend1 if needed (dest on same domain).

Server1 is an old release of Postfix which mostly handles virtual maps
expansion and mailing lists, and then forward all messages to a
different MTA (not Postfix) located on Backend1 which is the final
destination.

For a few users only, we are planning to have, in addition to
the setup above :

  Internet ==> MX ==> Server1 ==> Backend2
  Internet <== Server1 <== Backend2

Where Backend2 is a Debian Wheezy machine hosting Postfix 2.9.6

So we've modified our transports on Server1 to read something like :

  example.com   relay:[Backend1-IP]
  newu...@example.com   relay:[Backend2-IP]
  ...

So incoming messages passing through Server1 and sent to
any...@example.com are delivered to Backend1, excepted for the messages
sent to newu...@example.com which are delivered to Backend2.

So far so good, it works perfectly.

But now we want 'newuser' to use Backend2 as his SMTP server to
authenticate and send messages to anywhere.

In particular we want that messages from "newu...@example.com" (migrated
to Backend2) to "any...@example.com" (not migrated yet from Backend1 to
Backend2) still pass through Server1. In fact, even a message from
"newu...@example.com" to "newu...@example.com" should still pass through
Server1.

Unfortunately Postfix on Backend2 tries to deliver such messages
locally, instead of forwarding them to Server1 first.

Any idea how to achieve the desired result without creating any nasty
loop ?

FYI the transports map on Backend2 is empty

On Backend2 mydestination is defined as :

   mydestination = example.com, backend2.example.com,
   localhost.localdomain, localhost

The long term goal is to migrate all users, one at a time (upon request)
from Backend1 to Backend2.

Thanks in advance for any pointer or help.

PS : of course the lists of migrated and not migrated yet users id and
email addresses are known

--
Jérôme Alet -  - Direction du Système d'Information
  Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX
   Tél : +687 290081  Fax : +687 254829

Re: Question wrt partial migration from old postfix to newer one on two servers

[Viktor Dukhovni]

On Wed, Apr 29, 2015 at 11:18:47AM +1100, J?r?me Alet wrote:

> For a few users only, we are planning to have, in addition to
> the setup above :
> 
>   Internet ==> MX ==> Server1 ==> Backend2
>   Internet <== Server1 <== Backend2
> 
> Where Backend2 is a Debian Wheezy machine hosting Postfix 2.9.6
> 
> So we've modified our transports on Server1 to read something like :
> 
>   example.com   relay:[Backend1-IP]
>   newu...@example.com   relay:[Backend2-IP]
>   ...

Replace this (on Server1) with a rewriting configuration:

virtual:
newu...@example.com newu...@backend2.example.com

transport:
example.com relay:[backend1.example.com]
backend1.example.comrelay
backend2.example.comrelay

> In particular we want that messages from "newu...@example.com" (migrated
> to Backend2) to "any...@example.com" (not migrated yet from Backend1 to
> Backend2) still pass through Server1. In fact, even a message from
> "newu...@example.com" to "newu...@example.com" should still pass through
> Server1.
> 
> Unfortunately Postfix on Backend2 tries to deliver such messages
> locally, instead of forwarding them to Server1 first.

On "Backend2":

main.cf:
mydomain = example.com
myorigin = $mydomain
relayhost = [server1.example.com]

# Uncomment one of the below.  Set the other to what remains
# after removing $myhostname:
#
# mydestination = $myhostname, localhost, localhost.$mydomain
# virtual_mailbox_domains = $myhostname

Mail to the domain goes to the smarthost, and from there dispatched
to the right account (via rewriting).


> On Backend2 mydestination is defined as :
> 
>mydestination = example.com, backend2.example.com,
>localhost.localdomain, localhost

Looks like you're using local(8) delivery, I'd like to strongly
urge you to go with virtual(8) (or similar, e.g. Dovecot IMAP)
delivery for a new installation.  Avoid local(8) mailboxes.  Use
local(8) only for mailing lists large enough to need owner-aliases.

-- 
Viktor.

Re: ERRATA(?): MILTER_README

[Wietse Venema]

Bill Cole:
> Are you are willing to consider changing MILTER_README to more precisely 
> describe that conditional availability of {i} if I propose specific 
> wording?

You can draft some text if you like. But, unless the text is really
simple, I don't expect that it is worth the trouble. If a system
is complicated to explain, then people will not use it, or will use
it incorrectly.  Blaming the user for that would be too easy.

Wietse

Re: Question wrt partial migration from old postfix to newer one on two servers

[Jérôme Alet]

Hi, and thanks for your fast answer,

On Wed, Apr 29, 2015 at 12:34:35AM +, Viktor Dukhovni wrote:
> > On Backend2 mydestination is defined as :
> >
> >mydestination = example.com, backend2.example.com,
> >localhost.localdomain, localhost
>
> Looks like you're using local(8) delivery, I'd like to strongly
> urge you to go with virtual(8) (or similar, e.g. Dovecot IMAP)
> delivery for a new installation.  Avoid local(8) mailboxes.  Use
> local(8) only for mailing lists large enough to need owner-aliases.

I'll try your previous suggestions ASAP, and I'm confident this will
work. Many thanks !

I don't exactly understand your last paragraph though, since (but I
didn't delve into the details) Dovecot (IMAP and POP) is installed on
Backend2.

Please could you elaborate ?

Thanks for your time.

--
Jérôme Alet -  - Direction du Système d'Information
  Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX
   Tél : +687 290081  Fax : +687 254829

Re: Question wrt partial migration from old postfix to newer one on two servers

[Jérôme Alet]

Hi again,

On Wed, Apr 29, 2015 at 12:34:35AM +, Viktor Dukhovni wrote:
>
> Replace this (on Server1) with a rewriting configuration:
>
> virtual:
>   newu...@example.com newu...@backend2.example.com
>
> transport:
>   example.com relay:[backend1.example.com]
>   backend1.example.comrelay
>   backend2.example.comrelay
>
> > In particular we want that messages from "newu...@example.com" (migrated
> > to Backend2) to "any...@example.com" (not migrated yet from Backend1 to
> > Backend2) still pass through Server1. In fact, even a message from
> > "newu...@example.com" to "newu...@example.com" should still pass through
> > Server1.
> >
> > Unfortunately Postfix on Backend2 tries to deliver such messages
> > locally, instead of forwarding them to Server1 first.
>
> On "Backend2":
>
> main.cf:
>   mydomain = example.com
>   myorigin = $mydomain
>   relayhost = [server1.example.com]
>
>   # Uncomment one of the below.  Set the other to what remains
>   # after removing $myhostname:
>   #
>   # mydestination = $myhostname, localhost, localhost.$mydomain
>   # virtual_mailbox_domains = $myhostname
>
> Mail to the domain goes to the smarthost, and from there dispatched
> to the right account (via rewriting).

I've tried several combinations of your suggestions, but now
unfortunately delivery doesn't work anymore (it used to, as explained
previously) : newu...@backend2.example.com is always rejected as unknown
in local recipient table.

This is because the real email address is newu...@example.com and not
newu...@backend2.example.com

In my original message, to simplify my question I didn't mention that
Backend2 also hosts 3 subdomains of example.com, and that the
virtual_mailbox_maps is computed with an LDAP query, so of course
newu...@backend2.example.com is not found in our LDAP directory...

Now I understand I shouldn't have tried to simplify the original
question because probably there were missing informations in it, sorry
for this...

So we're back to the drawing board, here's my actual configuration
(before your suggestions), as-is (only domain names changed) :

Server1's transport :
--- CUT ---
# Not migrated yet :
sub1.example.comrelay:[backend1.example.com]
sub2.example.comrelay:[backend1.example.com]
sub3.example.comrelay:[backend1.example.com]
example.com relay:[backend1.example.com]
# Migrated mailboxes :
newus...@sub1.example.com   relay:[backend2.example.com]
newus...@sub2.example.com   relay:[backend2.example.com]
newus...@sub3.example.com   relay:[backend2.example.com]
newu...@example.com relay:[backend2.example.com]
--- CUT ---

Server1's virtual has not been modified at all.

Backend2's virtual
--- CUT ---
... empty ...
--- CUT ---

Backend2's transport
--- CUT ---
... empty ...
--- CUT ---

Backend2's virtual-ldap.cf
--- CUT ---
server_host = ldaps://ldap.example.com:636/
server_port = 636
search_base = ou=people,dc=example,dc=com
start_tls = no
tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt
tls_require_cert = yes
query_filter = (&(objectClass=posixAccount)(mail=%s))
domain = sub1.example.com, sub2.example.com, sub3.example.com, example.com
result_attribute = uid
--- CUT ---

Backend2's virtual-mailbox-maps-ldap.cf
--- CUT ---
server_host = ldaps://ldap.example.com:636/
server_port = 636
search_base = ou=people,dc=example,dc=com
start_tls = no
tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt
tls_require_cert = yes
query_filter = (&(objectClass=posixAccount)(mail=%s))
domain = sub1.example.com, sub2.example.com, sub3.example.com, example.com
result_attribute = homeDirectory
--- CUT ---

Backend2's sender-canonical-maps-ldap.cf
--- CUT ---
server_host = ldaps://ldap.example.com:636/
server_port = 636
start_tls = no
tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt
tls_require_cert = yes
search_base = ou=people,dc=example,dc=com
query_filter = (&(objectClass=posixAccount)(uid=%u))
result_attribute = mail
--- CUT ---

Backend2's main.cf :
--- CUT ---
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
readme_directory = /usr/share/doc/postfix

smtpd_tls_cert_file=/etc/ssl/certs/backend2.example.com.pem
smtpd_tls_key_file=/etc/ssl/private/backend2.example.com.key
smtpd_tls_CAfile=/etc/ssl/certs/chain-backend2.example.com.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_note_starttls_offer = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_received_header = yes
smtpd_tls_auth_only = yes
smtpd_tls_security_level = may

myhostname = backend2.example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/virtua

Re: Question wrt partial migration from old postfix to newer one on two servers

[Viktor Dukhovni]

On Wed, Apr 29, 2015 at 03:23:20PM +1100, J?r?me Alet wrote:

> I've tried several combinations of your suggestions, but now
> unfortunately delivery doesn't work anymore (it used to, as explained
> previously) : newu...@backend2.example.com is always rejected as unknown
> in local recipient table.

You've not explained how you intend to manage mailboxes, or shown any
details of your configuration.  My advice was correspondingly sketchy.

If you want to use local(8) delivery, you need to list users in
local_recipient_maps and/or arrange for mailbox_transport or similar
if users don't have system accounts.

> This is because the real email address is newu...@example.com and not
> newu...@backend2.example.com

There's no such thing as a "real" email address.  There are only
routing rules that deliver mail to the right mail store.

> In my original message, to simplify my question I didn't mention that
> Backend2 also hosts 3 subdomains of example.com, and that the
> virtual_mailbox_maps is computed with an LDAP query, so of course
> newu...@backend2.example.com is not found in our LDAP directory...

You can adapt the LDAP query.  You made no mention of LDAP before.

The basic idea is to associate with each user a mailbox address in
addition to their primary email address.  Then match either.  You
may need to provision additional addresses in LDAP as you migrate
users.

> Now I understand I shouldn't have tried to simplify the original
> question because probably there were missing informations in it, sorry
> for this...

Indeed.

> So we're back to the drawing board, here's my actual configuration
> (before your suggestions), as-is (only domain names changed) :
> 
> Server1's transport :
> --- CUT ---
> # Not migrated yet :
> sub1.example.comrelay:[backend1.example.com]
> sub2.example.comrelay:[backend1.example.com]
> sub3.example.comrelay:[backend1.example.com]
> example.com relay:[backend1.example.com]
> # Migrated mailboxes :
> newus...@sub1.example.com   relay:[backend2.example.com]
> newus...@sub2.example.com   relay:[backend2.example.com]
> newus...@sub3.example.com   relay:[backend2.example.com]
> newu...@example.com relay:[backend2.example.com]
> --- CUT ---

Well you're going out of your way to create a loop, in which mail for
us...@example.com is sent by the centrall mailhub to the mailstore
host, but you want that host to send such mail back to the mailhub.

The solution is to distinguish between mail to the virtual primary
domain, and mail to the underlying mailboxes.

This needs to be worked out in detailed, and tested with care.  Changes
in supporting tables may be required.

-- 
Viktor.

Re: Question wrt partial migration from old postfix to newer one on two servers

[Jérôme Alet]

On Wed, Apr 29, 2015 at 04:32:22AM +, Viktor Dukhovni wrote:
> On Wed, Apr 29, 2015 at 03:23:20PM +1100, J?r?me Alet wrote:
>
> You've not explained how you intend to manage mailboxes, or shown any
> details of your configuration.  My advice was correspondingly sketchy.

My bad, sorry.

> If you want to use local(8) delivery, you need to list users in
> local_recipient_maps and/or arrange for mailbox_transport or similar
> if users don't have system accounts.

I forgot in my previous message : all users have system accounts,
delivery is to be done (it works fine already) to their home directory's
Maildir/ subdirectory, in the Maildir format. The location of their home
directory is retrieved from LDAP using the configuration sent previously.

> > This is because the real email address is newu...@example.com and not
> > newu...@backend2.example.com
>
> There's no such thing as a "real" email address.  There are only
> routing rules that deliver mail to the right mail store.

OK so with my actual configuration routing and delivery are correct in
these directions :

Not migrated yet users :
  Internet => MX => Server1 => Backend1
  Backend1 => Server1 => Internet

Migrated users :
  Internet => MX => Server1 => Backend2

Now I want to have this :

  Backend2 => Server1 => Internet

For each migrated user, i.e. who utilises Backend2 as his MUA's SMTP
server, even if destination email address is in the already migrated
group.

> The basic idea is to associate with each user a mailbox address in
> addition to their primary email address.  Then match either.  You
> may need to provision additional addresses in LDAP as you migrate
> users.

Not sure how to do this because in the future (that's why I didn't talk
about this) the Server1 => Backend2 connection will be done through a
load balancer (there will be several servers to host the 'Backend2'
role). So I don't want fixed associations between a migrated user and a
particular "Backend2" server.

> > Server1's transport :
> > --- CUT ---
> > # Not migrated yet :
> > sub1.example.comrelay:[backend1.example.com]
> > sub2.example.comrelay:[backend1.example.com]
> > sub3.example.comrelay:[backend1.example.com]
> > example.com relay:[backend1.example.com]
> > # Migrated mailboxes :
> > newus...@sub1.example.com   relay:[backend2.example.com]
> > newus...@sub2.example.com   relay:[backend2.example.com]
> > newus...@sub3.example.com   relay:[backend2.example.com]
> > newu...@example.com relay:[backend2.example.com]
> > --- CUT ---
>
> Well you're going out of your way to create a loop, in which mail for
> us...@example.com is sent by the centrall mailhub to the mailstore
> host, but you want that host to send such mail back to the mailhub.

Not always : not when receiving messages from Server1 using its
transport map.

This only has to be done (message forwarded to Server1 for routing) when
sending messages from Backend2 when Backend2 is used as the outgoing
SMTP server in a migrated user MUA's preferences.

But I don't know how to differentiate between these two situations in
Postfix configuration :-(

Thanks in advance for any help

--
Jérôme Alet -  - Direction du Système d'Information
  Université de la Nouvelle-Calédonie - BPR4 - 98851 NOUMEA CEDEX
   Tél : +687 290081  Fax : +687 254829

Re: Stan Hoeppner's fqrdns.pcre file?

[DTNX Postmaster]

On 28 Apr 2015, at 23:23, Steve Jenkins  wrote:

> On Tue, Apr 28, 2015 at 2:13 PM, Terry Barnum  > wrote:
> github URL for curl:
> 
> $ curl 
> https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre
>  
> 
> 
> Thanks, Terry. The same URL will also work for a wget, and I recommend using 
> the -N option for timestamping (will only download if remote file is newer):
> 
> $ /usr/bin/wget -q -N -P /etc/postfix 
> https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre
>  
> 
> 
> I've also noticed that on my older systems I have have to bypass the 
> certificate check to avoid a "certificate common name" error:
> 
> $ /usr/bin/wget --no-check-certificate -q -N -P /etc/postfix 
> https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre
>  
> 

Don't bypass the certificate, update your certificate store on those 
systems :-)

I would also suggest downloading to a temporary directory first, and 
doing some basic checks on the file's contents before slotting it into 
a running Postfix configuration. Whether there's a significant change 
in the number of lines, for example, a few tests via 'postmap', and so 
on.

Mvg,
Joni

Re: Question wrt partial migration from old postfix to newer one on two servers

[Viktor Dukhovni]

On Wed, Apr 29, 2015 at 03:53:09PM +1100, J?r?me Alet wrote:

> On Wed, Apr 29, 2015 at 04:32:22AM +, Viktor Dukhovni wrote:
> > On Wed, Apr 29, 2015 at 03:23:20PM +1100, J?r?me Alet wrote:
> >
> > You've not explained how you intend to manage mailboxes, or shown any
> > details of your configuration.  My advice was correspondingly sketchy.
> 
> My bad, sorry.

And yet you still have not provided a complete set of requirements
and configuration details, while at the same time asking for
implementation guidance that is highly dependent on how the moving
parts fit together in your system.

You'll have to flesh out a design based on rewriting at the mail
hub, and configure the target mailstores to accept and deliver the
"mailbox" address of each user, while forwaring the primary address
to the mailhub.

This is not rocket science, but the details vary by site, (we just
found out you're using home Maildirs, but still not how that's
configured, ...).  You really won't get much more help here.

Buy Ralf and Patrick's book, read, understand, apply to meet your
needs.

-- 
Viktor.

Re: Question wrt partial migration from old postfix to newer one on two servers

[jerome alet]

> 
> From: Viktor Dukhovni 
> Sent: Wed Apr 29 16:49:01 NCT 2015
> To: 
> Subject: Re: Question wrt partial migration from old postfix to newer one on 
> two servers
> 
> And yet you still have not provided a complete set of requirements
> and configuration details, while at the same time asking for
> implementation guidance that is highly dependent on how the moving
> parts fit together in your system.

Sorry but I think it will be difficult to add more to my previous message. I 
don't understand what is missing in it.

> You'll have to flesh out a design based on rewriting at the mail
> hub, and configure the target mailstores to accept and deliver the
> "mailbox" address of each user, while forwaring the primary address
> to the mailhub.
> 
> This is not rocket science, but the details vary by site, (we just
> found out you're using home Maildirs, but still not how that's
> configured, ...)

Unless I've still forgotten something (but I don't know what) I think how it's 
configured is explained in my previous message : each migrated user has a 
system account (and of couse a home directory), and there are some LDAP filters 
(included in my previous message) to match the email address with the uid then 
the uid with the user's home directory.

> You really won't get much more help here.

You were very helpful already, especially if all my requests so far are 
incomplete...

Thanks for your time.

bye

-- 
Jerome Alet