secondary MX Server
Hello, postfix 3.4.5 i mean i have a correct running postfix server. ;-) Now I like to create a secondary postfix for my system. What are the best to realize, have this two servers in sync? I have enable postscreen, all I found on Internet, is to have installed memcache is this correct? But what can / must I sync? Thanks for a answer, -- mit freundliche Grüßen / best regards, Günther J. Niederwimmer
[OT] If you also have systems running Exim, patch your Exim systems.
[ Largely off-topic here, but perhaps some readers will benefit. ] If, in addition to any Postfix systems you may have, you also have some Exim systems, please make sure to upgrade them to 4.92 promptly: Qualys Security Advisory The Return of the WIZard: RCE in Exim (CVE-2019-10149) https://www.openwall.com/lists/oss-security/2019/06/05/4 [ For those not old enough to remember, "WIZard" is an allusion to the Morris Worm of 1988. ] And now back to your regular programme... -- Viktor.
Re: Mail Delivery Status report
On May 31, 2019, at 1:52 AM, Bastian Blank
wrote:
> On Fri, May 31, 2019 at 01:29:11AM -0600, @lbutlr wrote:
>> mail postfix/pipe[78386]: 45FZmb6nfgzdrvL:
>> to=>, relay=dovecot, delay=0.03,
>> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command:
>> /usr/local/libexec/dovecot/dovecot-lda)
>> mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from=
>> mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL:
>> message-id=<45fzmb6nfgzd...@mail.covisp.net>
>> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=, size=271,
>> nrcpt=2 (queue active)
>> mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=,
>> orig_to=, relay=local, delay=0.03,
>> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command:
>> /usr/local/bin/procmail -t -a $EXTENSION)
>> mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status
>> notification: 45FZmb6xXXzdrvd
>> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed
>>
>> But nothin there says why the delivery status notification is generated.
>
> This is no real mail. A real delivery would have "status=sent" in it.
It is a real mail. As I said in the original post, I get the DSN for ever *BCC*
mail. When mail Is delivered to u...@domain.tld it is also BCCed to
backup+(day_of_year).user.domain@domain2.tld
> The "status=deliverable" part describes this as a delivery check. As
> this delivery check produces a DSN, you are most likely using "sendmail
> -bv" (as root on the local system!), where this is the expected and
> _documented_ result.
As I detailed in the first post, I am *not* using sendmail -bv.
I wrote:
> /usr/local/etc/postfix
> # grep "sendmail -v" *
> bounce.cf.default:# address...) or for verbose mail delivery (sendmail -v
> address...).
>
> main.cf:
> recipient_bcc_maps = pcre:$config_directory/rbcc.pcre
>
> rbcc.pcre:
> if !/backup.*@/
> /^([^+_]*).*@(.*)/ backup+151.${1}.${2}@
> endif
And
> "sendmail" doesn't appears uncommented in main,.cf nor master.cf, though
> sendmail_path = /usr/local/sbin/sendmail is a default setting.
Still getting a DSN for every BCC mail. Still nothing in the logs that tells me
why this might be.
--
The Steve is seen, rightly or wrongly, as the visionary, the leader,
the savant. Bill is the Boswell to The Steve's Johnson, but lacking
Boswell's wit, charm, and dynamic personality.
Re: Mail Delivery Status report
> On Jun 6, 2019, at 2:15 PM, @lbutlr wrote: > >> On Fri, May 31, 2019 at 01:29:11AM -0600, @lbutlr wrote: >>> mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: >>> to=>, relay=dovecot, delay=0.03, >>> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to >>> command: /usr/local/libexec/dovecot/dovecot-lda) >>> mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from= >>> >>> But nothin there says why the delivery status notification is generated. >> >> This is no real mail. A real delivery would have "status=sent" in it. > > It is a real mail. As I said in the original post, I get the DSN for ever > *BCC* mail. When mail Is delivered to user@domain.tldit is also BCCed to > backup+(day_of_year).user.domain@domain2.tld The logs demonstrably show a delivery probe. Delivery probes are created either via "sendmail -bv" or via recipient verification. http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient but the latter do not cause a DSN to be sent, and don't inject mail probes via the pickup(8) service (maildrop queue). Your logs showed: mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: to=>, relay=dovecot, delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: /usr/local/libexec/dovecot/dovecot-lda) mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from= mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL: message-id=<[hidden email]> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=<[hidden email]>, size=271, nrcpt=2 (queue active) mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=<[hidden email]>, orig_to=<[hidden email]>, relay=local, delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: /usr/local/bin/procmail -t -a $EXTENSION) mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status notification: 45FZmb6xXXzdrvd mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed This is unequivocal evidence of use of "sendmail -bv". You're reporting non-use of "sendmail -v", but "-bv" != "-v". Perhaps you have a content filter that is misconfigured to use "sendmail -bv". -- Viktor.
Re: Mail Delivery Status report
Hi nameless
On Thu, Jun 06, 2019 at 12:15:10PM -0600, @lbutlr wrote:
> On May 31, 2019, at 1:52 AM, Bastian Blank
> wrote:
> > On Fri, May 31, 2019 at 01:29:11AM -0600, @lbutlr wrote:
> >> mail postfix/pipe[78386]: 45FZmb6nfgzdrvL:
> >> to=>, relay=dovecot, delay=0.03,
> >> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to
> >> command: /usr/local/libexec/dovecot/dovecot-lda)
> >> mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from=
> >> mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL:
> >> message-id=<45fzmb6nfgzd...@mail.covisp.net>
> >> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=,
> >> size=271, nrcpt=2 (queue active)
> >> mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=,
> >> orig_to=, relay=local, delay=0.03,
> >> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to
> >> command: /usr/local/bin/procmail -t -a $EXTENSION)
> >> mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status
> >> notification: 45FZmb6xXXzdrvd
> >> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed
> >>
> >> But nothin there says why the delivery status notification is generated.
> >
> > This is no real mail. A real delivery would have "status=sent" in it.
>
> It is a real mail. As I said in the original post, I get the DSN for ever
> *BCC* mail. When mail Is delivered to u...@domain.tld it is also BCCed to
> backup+(day_of_year).user.domain@domain2.tld
No, "status=deliverable" shows this is _no_ real mail.
> > The "status=deliverable" part describes this as a delivery check. As
> > this delivery check produces a DSN, you are most likely using "sendmail
> > -bv" (as root on the local system!), where this is the expected and
> > _documented_ result.
> As I detailed in the first post, I am *not* using sendmail -bv.
"root" (uid=0) on this system requested a delivery report. Please ask
root about it.
> I wrote:
> > /usr/local/etc/postfix
> > # grep "sendmail -v" *
> > bounce.cf.default:# address...) or for verbose mail delivery (sendmail -v
> > address...).
> >
> > main.cf:
> > recipient_bcc_maps = pcre:$config_directory/rbcc.pcre
> >
> > rbcc.pcre:
> > if !/backup.*@/
> > /^([^+_]*).*@(.*)/ backup+151.${1}.${2}@
> > endif
>
> And
>
> > "sendmail" doesn't appears uncommented in main,.cf nor master.cf, though
> > sendmail_path = /usr/local/sbin/sendmail is a default setting.
>
> Still getting a DSN for every BCC mail. Still nothing in the logs that tells
> me why this might be.
"sendmail -v" != "sendmail -bv". Please read carefully. Also your grep
is inadequate to find possible call sites.
So, again: Please show _full_ and _unmodified_ config and logging
showing the behaviour you want to report.
Otherwise, please go away.
Regards,
Bastian
--
War is never imperative.
-- McCoy, "Balance of Terror", stardate 1709.2
Re: [OT] If you also have systems running Exim, patch your Exim systems.
Thanks for the heads-up, I for one found it useful by virtue of Exim4 being the default MTA in Debian installations. On 06/06/2019 20:05, Viktor Dukhovni wrote: [ Largely off-topic here, but perhaps some readers will benefit. ] If, in addition to any Postfix systems you may have, you also have some Exim systems, please make sure to upgrade them to 4.92 promptly: Qualys Security Advisory The Return of the WIZard: RCE in Exim (CVE-2019-10149) https://www.openwall.com/lists/oss-security/2019/06/05/4 [ For those not old enough to remember, "WIZard" is an allusion to the Morris Worm of 1988. ] And now back to your regular programme...
Re: Mail Delivery Status report
On Jun 6, 2019, at 12:40 PM, Viktor Dukhovni wrote: > This is unequivocal evidence of use of "sendmail -bv". You're reporting > non-use of "sendmail -v", but "-bv" != "-v". Perhaps you have a content > filter that is misconfigured to use "sendmail -bv". As I have said twice now, there is no instance of an uncommented sendmail in /etc/postfix/ > "sendmail" doesn't appears uncommented in main,.cf nor master.cf, though > sendmail_path = /usr/local/sbin/sendmail is a default setting. # grep -i sendmail /usr/local/etc/postfix/* | grep -Ev '(:#|default:|sample:|makedefs)' main.cf.proto:sendmail_path = postfix-files:$sendmail_path:f:root:-:755 postfix-files:$newaliases_path:l:$sendmail_path postfix-files:$mailq_path:l:$sendmail_path postfix-files:$manpage_directory/man1/sendmail.1:f:root:-:644 postfix-files:$html_directory/sendmail.1.html:h:$html_directory/mailq.1.html:-:644 # postconf -n | grep sendmail # postconf -d | grep sendmail sendmail_fix_line_endings = always sendmail_path = /usr/local/sbin/sendmail smtputf8_autodetect_classes = sendmail, verify # So no, there is not sendmail -v nor sendmail -bv nor sendmail at all anywhere in the postfix config. -- Hard work pays off in the future. Laziness pays off now.
Re: Mail Delivery Status report
> On Jun 6, 2019, at 5:07 PM, @lbutlr wrote: > >> This is unequivocal evidence of use of "sendmail -bv". You're reporting >> non-use of "sendmail -v", but "-bv" != "-v". Perhaps you have a content >> filter that is misconfigured to use "sendmail -bv". > > As I have said twice now, there is no instance of an uncommented sendmail in > /etc/postfix/ You can keep saying it till the cows come home, but the fact remains that you're running "sendmail -bv", perhaps via a content_filter script, or a procmail config. These need not be in main.cf or master.cf (which you've not posted). You've exhausted all the help this list can provide, good luck. -- Viktor.
Re: Mail Delivery Status report
@lbutlr: > mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: > to=>, relay=dovecot, > delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable > (delivers to command: /usr/local/libexec/dovecot/dovecot-lda) That is logged after invoking 'sendmail -bv, or after requesting address verification. The difference is that 'sendmail -bv' produces email with "Mail Delivery Status Report", while address verification reports the result to the verify daemon. Wietse
Re: secondary MX Server
> On Jun 6, 2019, at 6:48 AM, Günther J. Niederwimmer wrote: > > Now I like to create a secondary postfix for my system. > > What are the best to realize, have this two servers in sync? > > I have enable postscreen, all I found on Internet, is to have installed > memcache is this correct? > > But what can / must I sync? On relay servers that don't store mailboxes, you don't really need to sync anything. Just let them work in parallel. Postfix is not a mailstore, and synchronizing mailstores is the job of Dovecot and the like... -- Viktor.
Re: secondary MX Server
On Fri, Jun 7, 2019, 08:05 Viktor Dukhovni wrote: > > > On Jun 6, 2019, at 6:48 AM, Günther J. Niederwimmer > wrote: > > > > Now I like to create a secondary postfix for my system. > > > > What are the best to realize, have this two servers in sync? > > > > I have enable postscreen, all I found on Internet, is to have installed > > memcache is this correct? > > > > But what can / must I sync? > > On relay servers that don't store mailboxes, you don't really > need to sync anything. Just let them work in parallel. Postfix > is not a mailstore, and synchronizing mailstores is the job of > Dovecot and the like... > -- > Viktor > Pls see this https://groups.google.com/forum/m/#!topic/mailing.postfix.users/hUlPvJaRJI4
Re: Mail Delivery Status report
On Jun 6, 2019, at 3:40 PM, Viktor Dukhovni wrote:
>> On Jun 6, 2019, at 5:07 PM, @lbutlr wrote:
>>
>>> This is unequivocal evidence of use of "sendmail -bv". You're reporting
>>> non-use of "sendmail -v", but "-bv" != "-v". Perhaps you have a content
>>> filter that is misconfigured to use "sendmail -bv".
>>
>> As I have said twice now, there is no instance of an uncommented sendmail in
>> /etc/postfix/
>
> You can keep saying it till the cows come home, but the fact
> remains that you're running "sendmail -bv", perhaps via a
> content_filter script, or a procmail config. These need
> not be in main.cf or master.cf (which you've not posted).
Believe me, I’d love nothing more than “You idiot, you missed ", but
I’ve checked for invocations of sendmail -bv everywhere on my system that I can
think of, it’s simply not there or it’s hidden in some way like
$sm=/path/tp/sendmail and then $sm -bv which I will never find.
Is there a way to log in more detail where this might be coming from? The
actual DSN is generated by bounce, but I doubt that is where I would find what
is causing the DSN. qmgr? pipe? Anything else I can do?
I have posted the output of greps showing there is no sendmail invocation in
postfix. The root user does not have a procmailrc and I am not running a filter
like amavis and I grepped all of /etc/ and /usr/local/etc (which would account
for anything like a global procmailrc). I have now also grepped all of
/usr/home and have found instances only in mail messages. Heck, I even checked
all of /usr/local and /bin and /sbin and /tmp and /var/tmp. If there is an
instance of sendmail -bv somewhere it is *very* well hidden.
Mail comes in. If it passes postscreen then when it is delivered to the user a
BCC is generated by rbcc.pcre which delivers to the backup account and for
inexplicable reasons, a DSN is generated for that BCC to root (which is aliased
to one of my accounts with a +root extension).
rbcc.pcre:
if !/backup.*@/
/^([^+_]*).*@([^.]*)/ backup+157.${1}-${2}@southgaylord.com
endif
postconf -n
alias_database = hash:$config_directory/aliases
alias_maps = hash:$config_directory/aliases
allow_percent_hack = no
broken_sasl_auth_clients = yes
compatibility_level = 2
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
enable_long_queue_ids = yes
header_checks = pcre:/etc/postfix/header_checks.pcre
home_mailbox = Maildir/
inet_interfaces = 127.0.0.1, 65.121.55.42
inet_protocols = ipv4
mailbox_command = /usr/local/bin/procmail -t -a $EXTENSION
maps_rbl_reject_code = 521
message_size_limit = 26214400
milter_connect_macros = j {daemon_name} v {if_name} _
milter_default_action = accept
mime_header_checks = pcre:$config_directory/mime_headers.pcre
mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost,
ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www.$mydomain,
webmail.$mydomain
mynetworks_style = subnet
myorigin = $mydomain
policyd-spf_time_limit = 3600
postscreen_access_list = cidr:$config_directory/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[4..11]*5
zen.spamhaus.org=127.0.0.[2..3]*1 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
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_ttl = 3d
postscreen_dnsbl_whitelist_threshold = -1
postscreen_greet_action = enforce
postscreen_greet_banner = mail.covisp.net ESTMP -- Please wait
postscreen_greet_ttl = 7d
recipient_bcc_maps = pcre:$config_directory/rbcc.pcre
recipient_delimiter = +_
show_user_unknown_table_name = no
smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP $mail_name $mail_version
smtpd_data_restrictions = reject_unauth_pipelining,
reject_multi_recipient_bounce, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, check_helo_access
pcre:/etc/postfix/helo_checks.pcre permit
smtpd_log_access_permit_actions = static:all
smtpd_milters = unix:/var/run/spamass-milter.sock,
smtpd_recipient_restrictions = reject_unauth_destination,
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_invalid_hostname,
reject_unlisted_recipient, reject_unlisted_sender,
reject_unknown_reverse_client_hostname, warn_if_reject
reject_unknown_client_hostname, check_recipient_access
hash:$config_directory/recipient_access, check_sender_access
pcre:$config_directory/sender_access.pcre, permit
smtpd_relay_restrictions = reject_unauth_destination
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_starttls_timeout = 20s
smtpd_tls_cert_file = /usr/local/etc/dehydrated/certs/covisp.net/fullchain.pem
smtpd_tls_key_file = /
Re: Mail Delivery Status report
> =On Jun 7, 2019, at 2:22 AM, @lbutlr wrote: > > Mail comes in. If it passes postscreen then when it is delivered to the user > a BCC is generated by rbcc.pcre which delivers to the backup account and for > inexplicable reasons, a DSN is generated for that BCC to root (which is > aliased to one of my accounts with a +root extension). The delivery status message clearly shows that mail to "backup" is handed off to procmail. The next place to look (as mentione upthread) is your procmail configuration. -- Viktor.
