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/ On 06.06.19 17:40, Viktor Dukhovni wrote: 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. On 07.06.19 09:22, Matus UHLAR - fantomas wrote: I guess it's because the "-x" command to spamass-milter. spamass-milter uses it to find the real mail recipient, because original sendmail docs say: -bvVerify names only - do not try to collect or deliver a message. Verify mode is normally used for validating users or mailing lists. however, postfix behaves differently: -bvDo not collect or deliver a message. Instead, send an email report after verifying each recipient address. This is useful for testing address rewriting and routing configurations. so possibly the "-x" option for spamass-milter is not a good idea with postfix. IIRC in the past I have recommended trying this option, if it helps finding real recipient of messages and using their personal spamassassin configs. It seems that with postfix this is not an option. ... which seems to be unfortunate. sendmail -bv helps with direct mapping from mail address to user account, through virtusertable and aliases: # sendmail -bv uh...@fantomas.sk uh...@fantomas.sk... deliverable: mailer local, user uhlar this helps me catch much of spam that would apparently be uncatched without it (using default user). Any idea how to safely map e-mail address to final destinations within postfix? (I believe that including files and running pipes is not necessary here) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer.
Re: Mail Delivery Status report
On Jun 7, 2019, at 4:41 AM, @lbutlr wrote: > On Jun 7, 2019, at 1:22 AM, Matus UHLAR - fantomas wrote: >> so possibly the "-x" option for spamass-milter is not a good idea with >> postfix. > > Ok, now that is something too check. Took out the -x and restarted and we’ll > see how that goes. I owe you a beer. Or a case of beer. I would never have found that. There bccs to backup and no DSNs. 🤞🏼
Re: Mail Delivery Status report
On Jun 7, 2019, at 1:22 AM, Matus UHLAR - fantomas wrote: > so possibly the "-x" option for spamass-milter is not a good idea with > postfix. Ok, now that is something too check. Took out the -x and restarted and we’ll see how that goes.
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/ On 06.06.19 17:40, Viktor Dukhovni wrote: 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. I guess it's because the "-x" command to spamass-milter. spamass-milter uses it to find the real mail recipient, because original sendmail docs say: -bvVerify names only - do not try to collect or deliver a message. Verify mode is normally used for validating users or mailing lists. however, postfix behaves differently: -bvDo not collect or deliver a message. Instead, send an email report after verifying each recipient address. This is useful for testing address rewriting and routing configurations. so possibly the "-x" option for spamass-milter is not a good idea with postfix. IIRC in the past I have recommended trying this option, if it helps finding real recipient of messages and using their personal spamassassin configs. It seems that with postfix this is not an option. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #98652: Operation completed successfully.
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.
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
@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: 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
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
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: 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
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 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. 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. Regards, Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4
Re: Mail Delivery Status report
> On 31 May 2019, at 00:33, Bastian Blank > wrote: > > On Fri, May 31, 2019 at 12:03:37AM -0600, @lbutlr wrote: >> I am getting mail delivery status reports for every bcc email (that is, >> every email, since I use a bcc map to create a backup of all the mail). > > Then you missconfigured something. Sure, but what could it be? > Mails duplicated by bcc maps are sent with NOTIFY=NONE, so don't create any > DSN. Yes, that is how it worked a couple of weeks ago. And the pm;y was O see to change that is to set sundial -v which is not set anywhere and isn't in postconf . > See http://www.postfix.org/postconf.5.html#recipient_bcc_maps And I posted the contents of the file referred to in recipient_bcc_maps >> Still, I am not sure why these messages are bing generate or how to turn >> them off. > > Show logs, read http://www.postfix.org/DEBUG_README.html#mail There's nothing interesting in the logs, sadly. It shows the bcc message being created and sent to the bcc address and the the delivery status notification ebbing generated as well, but not why. 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. -- Q is for QUENTIN who sank in the mire R is for RHODA consumed by a fire
Re: Mail Delivery Status report
On Fri, May 31, 2019 at 12:03:37AM -0600, @lbutlr wrote: > I am getting mail delivery status reports for every bcc email (that is, every > email, since I use a bcc map to create a backup of all the mail). Then you missconfigured something. Mails duplicated by bcc maps are sent with NOTIFY=NONE, so don't create any DSN. See http://www.postfix.org/postconf.5.html#recipient_bcc_maps > Still, I am not sure why these messages are bing generate or how to turn them > off. Show logs, read http://www.postfix.org/DEBUG_README.html#mail Bastian -- Ahead warp factor one, Mr. Sulu.
