Re: Problems emailing bell.net or sympatico.ca addresses
Dnia 18.09.2021 o godz. 09:27:47 raf pisze: > > This forum might help, it contains complaints about this, > but it's only for Bell customers: > > https://www.dslreports.com/forum/sympatdirect~days=365~start=30 > > Hmm, maybe not. You can see the topic titles, but it doesn't let > you see anyone else's content. Wierdly unhelpful. I vaguely remember that this topic has been discussed several times on mai...@mailop.org mailing list. I highly recommend this mailing list for dealing with deliverability issues. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Rewriting the MAILER-DAEMON address and header formats
Dnia 18.09.2021 o godz. 08:39:41 Vladimir Mishonov pisze: > 2. While the above is mostly for aesthetical reasons, there is one > other thing: the templates for mailer-daemon messages have obsolete > "From" and "To" header formats, e.g.: > > >From: mailer-dae...@mydomain.com (Mail Delivery System) > >To: postmas...@mydomain.com (Postmaster) > > This appears to be the legacy RFC5322 header format (see > https://github.com/roundcube/roundcubemail/issues/5402). I'm not > very well versed in the RFC stuff, but what I can say for sure is > that so far I've ONLY seen this format in these templates, and > nowhere else. It looks like some email clients (like Roundcube, see > the link above) do not handle this format very well, probably for > the reason that it's barely used nowadays, if at all. >From the very link you quoted, you can know that this format is still used and can be still seen in the regular emails you get, because (quote from your link): "at least two current programs use this syntax: The MUA called ELM, and the unix tool to send email from the command line (often used by cron jobs): mailx." Wouldn't it be better to patch Roundcube? Also from the link you quoted, the developers say they'll accept a patch. Someone even tried to submit a patch, but failed. It shouldn't be too hard to patch however. If I were you, I would rather try to patch Roundcube and not Postfix. > Postfix. I understand that I can make changes to the source code and > recompile the program, but even if I am able to accomplish this, it > would only be half of the job done, if not even less than that. I'd > also have to arrange a process to create packages in the appropriate > format for my OS distribution and keep them updated. You don't have to. You can get rid of packaged Postfix and use the one installed from source. Of course everytime new Postfix version is released, if you want to upgrade, you need to download the new source version, apply your patch and recompile. You can try to automate that :). But again, if I were you, I would rather go towards modifying Roundcube. It would be probably easier, and that's actually the place where the error is, so it should be fixed there, not worked around in Postfix, because you can get emails with headers in this forma from other sources too, as noted above. > The postconf(5) manual says > that postmaster notifications generated by smtp and smtpd _can_ be > inspected by adding "notify" to "internal_mail_filter_classes". > Unfortunately, while it does seem to enable DKIM signing for them > (via the milter application that I've configured), it still does not > apply any header checks to them. If you are able to apply a milter to them, you can write a milter that rewrites those headers. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Rewriting the MAILER-DAEMON address and header formats
On 18/09/2021 11:32, Jaroslaw Rafa wrote: Dnia 18.09.2021 o godz. 08:39:41 Vladimir Mishonov pisze: 2. While the above is mostly for aesthetical reasons, there is one other thing: the templates for mailer-daemon messages have obsolete "From" and "To" header formats, e.g.: From: mailer-dae...@mydomain.com (Mail Delivery System) To: postmas...@mydomain.com (Postmaster) This appears to be the legacy RFC5322 header format (see https://github.com/roundcube/roundcubemail/issues/5402). I'm not very well versed in the RFC stuff, but what I can say for sure is that so far I've ONLY seen this format in these templates, and nowhere else. It looks like some email clients (like Roundcube, see the link above) do not handle this format very well, probably for the reason that it's barely used nowadays, if at all. From the very link you quoted, you can know that this format is still used and can be still seen in the regular emails you get, because (quote from your link): "at least two current programs use this syntax: The MUA called ELM, and the unix tool to send email from the command line (often used by cron jobs): mailx." Wouldn't it be better to patch Roundcube? Also from the link you quoted, the developers say they'll accept a patch. Someone even tried to submit a patch, but failed. It shouldn't be too hard to patch however. If I were you, I would rather try to patch Roundcube and not Postfix. Postfix. I understand that I can make changes to the source code and recompile the program, but even if I am able to accomplish this, it would only be half of the job done, if not even less than that. I'd also have to arrange a process to create packages in the appropriate format for my OS distribution and keep them updated. You don't have to. You can get rid of packaged Postfix and use the one installed from source. Of course everytime new Postfix version is released, if you want to upgrade, you need to download the new source version, apply your patch and recompile. You can try to automate that :). But again, if I were you, I would rather go towards modifying Roundcube. It would be probably easier, and that's actually the place where the error is, so it should be fixed there, not worked around in Postfix, because you can get emails with headers in this forma from other sources too, as noted above. The postconf(5) manual says that postmaster notifications generated by smtp and smtpd _can_ be inspected by adding "notify" to "internal_mail_filter_classes". Unfortunately, while it does seem to enable DKIM signing for them (via the milter application that I've configured), it still does not apply any header checks to them. If you are able to apply a milter to them, you can write a milter that rewrites those headers. I've not been paying particular attention to the thread, but can header_checks be used to rewrite MAILER-DAEMON to mailer-daemon? Nick
Re: Rewriting the MAILER-DAEMON address and header formats
On September 18, 2021 1:37:19 PM GMT+03:00, Nick Howitt wrote: > > >On 18/09/2021 11:32, Jaroslaw Rafa wrote: >> >> Dnia 18.09.2021 o godz. 08:39:41 Vladimir Mishonov pisze: >>> 2. While the above is mostly for aesthetical reasons, there is one >>> other thing: the templates for mailer-daemon messages have obsolete >>> "From" and "To" header formats, e.g.: >>> From: mailer-dae...@mydomain.com (Mail Delivery System) To: postmas...@mydomain.com (Postmaster) >>> >>> This appears to be the legacy RFC5322 header format (see >>> https://github.com/roundcube/roundcubemail/issues/5402). I'm not >>> very well versed in the RFC stuff, but what I can say for sure is >>> that so far I've ONLY seen this format in these templates, and >>> nowhere else. It looks like some email clients (like Roundcube, see >>> the link above) do not handle this format very well, probably for >>> the reason that it's barely used nowadays, if at all. >> >> From the very link you quoted, you can know that this format is still used >> and can be still seen in the regular emails you get, because (quote from >> your link): >> >> "at least two current programs use this syntax: >> The MUA called ELM, and the unix tool to send email from the command line >> (often used by cron jobs): mailx." >> >> Wouldn't it be better to patch Roundcube? Also from the link you quoted, the >> developers say they'll accept a patch. Someone even tried to submit a patch, >> but failed. It shouldn't be too hard to patch however. If I were you, I >> would rather try to patch Roundcube and not Postfix. >> >>> Postfix. I understand that I can make changes to the source code and >>> recompile the program, but even if I am able to accomplish this, it >>> would only be half of the job done, if not even less than that. I'd >>> also have to arrange a process to create packages in the appropriate >>> format for my OS distribution and keep them updated. >> >> You don't have to. You can get rid of packaged Postfix and use the >> one installed from source. Of course everytime new Postfix version is >> released, if you want to upgrade, you need to download the new source >> version, apply your patch and recompile. You can try to automate that :). >> >> But again, if I were you, I would rather go towards modifying Roundcube. It >> would be probably easier, and that's actually the place where the error is, >> so it should be fixed there, not worked around in Postfix, because you can >> get emails with headers in this forma from other sources too, as noted >> above. >> >>> The postconf(5) manual says >>> that postmaster notifications generated by smtp and smtpd _can_ be >>> inspected by adding "notify" to "internal_mail_filter_classes". >>> Unfortunately, while it does seem to enable DKIM signing for them >>> (via the milter application that I've configured), it still does not >>> apply any header checks to them. >> >> If you are able to apply a milter to them, you can write a milter that >> rewrites those headers. >> >I've not been paying particular attention to the thread, but can >header_checks be used to rewrite MAILER-DAEMON to mailer-daemon? > >Nick Hey, nice to see that there is actually some activity going on here. Like I said before, header checks can be used to change the address and the header format, but it does not apply to certain kinds of notifications, e.g. SMTP protocol violation reports with session transcripts. The same effect is achievable with bounce_template_file, which does not affect these types of notifications either and generally feels a bit less hacky to me. In regard to what Jaroslaw has suggested, it still seems to me that most of it deals with the symptoms instead of the actual cause of the problem, in addition to being quite difficult to implement for an average user like me. Also, the Roundcube issue that I linked to is somewhat old, and I am pretty certain that the problematic header format is mostly non-existent in the wild as of today - especially considering that it was the only mention of it that I could find at all. It looks as if its usage in Postfix mailer daemon notifications is a remnant of a very distant past that has never been paid much (if at all) attention to since it was first implemented. -- Kind regards, Vladimir
Re: Rewriting the MAILER-DAEMON address and header formats
Vladimir Mishonov: > 2. While the above is mostly for aesthetical reasons, there is one other > thing: the templates for mailer-daemon messages have obsolete "From" and > "To" header formats, e.g.: > > > From: mailer-dae...@mydomain.com (Mail Delivery System) > > To: postmas...@mydomain.com (Postmaster) I'll be happy to update those templates, built-in defaults, as well as postmaster notifications. They must have been overlooked when the header_from_format parameter (using standard format by default) was introduced four years ago in Postfix 3.3. Wietse
AW: Spam pass the filter
Hi, pcre header checks we use. Not all the time, depends on spam volume from these valuable enterprises. #/sjmedia.us/ REJECT A mass mail service abused by criminals #/bmsend.com/ REJECT A mass mail service abused by criminals #/mailgun.net/ REJECT A mass mail service abused by criminals #/rsgsv.net/REJECT A mass mail service abused by criminals #/mcsv.net/ REJECT A mass mail service abused by criminals #/sendgrid.net/ REJECT A mass mail service abused by criminals #/crsend.com/ REJECT A mass mail service abused by criminals #/zcsend.net/ REJECT A mass mail service abused by criminals I forgot if all those can be catched by limiting it to the Received-Line. Greets, Ludi -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von Christian Schmitz Gesendet: Freitag, 17. September 2021 14:41 An: postfix-users@postfix.org Betreff: Spam pass the filter Hi everyone: Normally when i identify a host spammer i block entire server. Today i receive one spam email. The origin is "mailgun.net", i already have a rule to block him, but the email pass with no problem. I want stop the email, what is wrong? The header, config and rules are the following. Best Regards and thanks in advance Christian
Re: Rewriting the MAILER-DAEMON address and header formats
On Sat, Sep 18, 2021 at 08:39:41AM +0300, Vladimir Mishonov wrote: > 1. You probably don't like when people shout at you, right? Well, > all-caps looks a lot like someone's shouting at you. It'd look better if > it were all-lowercase. The "MAILER-DAEMON" form is a long-standing heritage from Sendmail, appears in "countless" aliases files, and may even in some environments be subject to case-sensitive matching. As much as you may feel it is "SHOUTING", on balance I think we should not change the default address. You can of course customise your bounce templates as you see fit. > 2. While the above is mostly for aesthetical reasons, there is one other > thing: the templates for mailer-daemon messages have obsolete "From" and > "To" header formats, e.g.: > > > From: mailer-dae...@mydomain.com (Mail Delivery System) > > To: postmas...@mydomain.com (Postmaster) Wietse has already promised to update the syntax. -- Viktor.
Re: Rewriting the MAILER-DAEMON address and header formats
On 2021-09-18 20:37, Viktor Dukhovni wrote: The "MAILER-DAEMON" form is a long-standing heritage from Sendmail, appears in "countless" aliases files, and may even in some environments be subject to case-sensitive matching. As much as you may feel it is "SHOUTING", on balance I think we should not change the default address. You can of course customise your bounce templates as you see fit. I see. Would it be too much to ask to add a template for postmaster notifications as well then (notify_classes = protocol etc.)? Like I said before, it appears that MAILER-DAEMON is hardcoded in those, and it looks like there is currently no way to change it even with header checks. Wietse has already promised to update the syntax. Yeah, I've seen that. Thank you both very much! --- Kind regards, Vladimir
Re: Rewriting the MAILER-DAEMON address and header formats
On Sat, Sep 18, 2021 at 08:46:15PM +0300, Vladimir Mishonov wrote: > I see. Would it be too much to ask to add a template for postmaster > notifications as well then (notify_classes = protocol etc.)? Like I said > before, it appears that MAILER-DAEMON is hardcoded in those, and it > looks like there is currently no way to change it even with header > checks. The issue is entirely cosmetic, and the only audience for these notices is the postmaster, not naïve users. So unless Wietse is feeling exceedingly generous with his time, I don't expect to see this change any time soon. If someone wants to contribute new documentation and a patch that matches Postfix code quality and style and implements postmaster notice templates, that might speed things up, but even reviewing good code and documentation still takes time, and the priority of this issue looks especially low to me... You can probably find a different yak to shave. https://en.wiktionary.org/wiki/yak_shaving -- Viktor.
Re: Rewriting the MAILER-DAEMON address and header formats
I am having problems replying to the list as it keeps bouncing. This
time I am trying removing the preceding messages,
Is this an uphill battle? Excluding docs, on my system I get:
[root@server ~]# grep MAILER-DAEMON /usr/* -r
Binary file /usr/bin/fetchmail matches
Binary file /usr/bin/procmail matches
Binary file /usr/lib/cyrus-imapd/arbitron matches
Binary file /usr/lib/cyrus-imapd/chk_cyrus matches
Binary file /usr/lib/cyrus-imapd/compile_sieve matches
Binary file /usr/lib/cyrus-imapd/ctl_cyrusdb matches
Binary file /usr/lib/cyrus-imapd/ctl_deliver matches
Binary file /usr/lib/cyrus-imapd/ctl_mboxlist matches
Binary file /usr/lib/cyrus-imapd/cvt_cyrusdb matches
Binary file /usr/lib/cyrus-imapd/cyr_dbtool matches
Binary file /usr/lib/cyrus-imapd/cyr_df matches
Binary file /usr/lib/cyrus-imapd/cyr_expire matches
Binary file /usr/lib/cyrus-imapd/cyr_sequence matches
Binary file /usr/lib/cyrus-imapd/cyr_synclog matches
Binary file /usr/lib/cyrus-imapd/cyr_userseen matches
Binary file /usr/lib/cyrus-imapd/cyrdump matches
Binary file /usr/lib/cyrus-imapd/cyrfetchnews matches
Binary file /usr/lib/cyrus-imapd/deliver matches
Binary file /usr/lib/cyrus-imapd/fud matches
Binary file /usr/lib/cyrus-imapd/idled matches
Binary file /usr/lib/cyrus-imapd/ipurge matches
Binary file /usr/lib/cyrus-imapd/mbexamine matches
Binary file /usr/lib/cyrus-imapd/mbpath matches
Binary file /usr/lib/cyrus-imapd/mupdate matches
Binary file /usr/lib/cyrus-imapd/nntpd matches
Binary file /usr/lib/cyrus-imapd/notifyd matches
Binary file /usr/lib/cyrus-imapd/pop3d matches
Binary file /usr/lib/cyrus-imapd/ptdump matches
Binary file /usr/lib/cyrus-imapd/ptexpire matches
Binary file /usr/lib/cyrus-imapd/ptloader matches
Binary file /usr/lib/cyrus-imapd/quota matches
Binary file /usr/lib/cyrus-imapd/reconstruct matches
Binary file /usr/lib/cyrus-imapd/sievec matches
Binary file /usr/lib/cyrus-imapd/sieved matches
Binary file /usr/lib/cyrus-imapd/smmapd matches
Binary file /usr/lib/cyrus-imapd/squatter matches
Binary file /usr/lib/cyrus-imapd/sync_client matches
Binary file /usr/lib/cyrus-imapd/sync_reset matches
Binary file /usr/lib/cyrus-imapd/sync_server matches
Binary file /usr/lib/cyrus-imapd/timsieved matches
Binary file /usr/lib/cyrus-imapd/tls_prune matches
Binary file /usr/lib/cyrus-imapd/unexpunge matches
Binary file /usr/lib/cyrus-imapd/imapd matches
Binary file /usr/lib/cyrus-imapd/proxyd matches
Binary file /usr/lib/cyrus-imapd/lmtpd matches
Binary file /usr/lib/cyrus-imapd/lmtpproxyd matches
/usr/lib64/python2.7/mailbox.py: from_line = 'From
MAILER-DAEMON %s' % time.asctime(time.gmtime())
/usr/lib64/python2.7/mailbox.py: message.set_from('MAILER-DAEMON',
time.gmtime(self.get_date()))
/usr/lib64/python2.7/mailbox.py: self.set_from('MAILER-DAEMON', True)
Binary file /usr/lib64/python2.7/mailbox.pyc matches
Binary file /usr/lib64/python2.7/mailbox.pyo matches
Binary file /usr/lib64/python3.4/__pycache__/mailbox.cpython-34.pyc matches
Binary file /usr/lib64/python3.4/__pycache__/mailbox.cpython-34.pyo matches
/usr/lib64/python3.4/mailbox.py: from_line = b'From
MAILER-DAEMON ' + time.asctime(time.gmtime()).encode()
/usr/lib64/python3.4/mailbox.py: message.set_from('MAILER-DAEMON',
time.gmtime(self.get_date()))
/usr/lib64/python3.4/mailbox.py: self.set_from('MAILER-DAEMON', True)
Binary file
/usr/lib64/python3.6/__pycache__/mailbox.cpython-36.opt-1.pyc matches
Binary file
/usr/lib64/python3.6/__pycache__/mailbox.cpython-36.opt-2.pyc matches
Binary file /usr/lib64/python3.6/__pycache__/mailbox.cpython-36.pyc matches
/usr/lib64/python3.6/mailbox.py: from_line = b'From
MAILER-DAEMON ' + time.asctime(time.gmtime()).encode()
/usr/lib64/python3.6/mailbox.py: message.set_from('MAILER-DAEMON',
time.gmtime(self.get_date()))
/usr/lib64/python3.6/mailbox.py: self.set_from('MAILER-DAEMON', True)
Binary file /usr/libexec/postfix/bounce matches
Binary file /usr/libexec/postfix/cleanup matches
Binary file /usr/libexec/postfix/local matches
Binary file /usr/libexec/postfix/oqmgr matches
Binary file /usr/libexec/postfix/pipe matches
Binary file /usr/libexec/postfix/showq matches
Binary file /usr/libexec/postfix/smtpd matches
Binary file /usr/libexec/postfix/trivial-rewrite matches
Binary file /usr/libexec/postfix/virtual matches
Binary file /usr/libexec/postfix/lmtp matches
Binary file /usr/libexec/postfix/smtp matches
Binary file /usr/libexec/postfix/nqmgr matches
Binary file /usr/libexec/postfix/qmgr matches
Binary file /usr/sbin/postconf matches
/usr/sbin/amavisd: ( $rfc2822_from[0] =~
/^MAILER-DAEMON(?:\@|\z)/si ||
/usr/sbin/amavisd: $rfc2822_from[0] =~
/^(?:MAILER-DAEMON|postmaster)(?:\@|\z)/si
/usr/sbin/amavisd: my $snd = $sender eq '' ? 'MAILER-DAEMON' #
as in sendmail & Postfix
/usr/sbin/qshape: $a = "MAILER-DAEMON" if ($a eq "");
/usr/share/roundcubemail/plugins/zipdownload/zipdownload.php: $from ?:
'MAILER-DAEMON',
/usr/share/roundcubemail/program/
Re: Rewriting the MAILER-DAEMON address and header formats
On 2021-09-18 21:22, Viktor Dukhovni wrote: The issue is entirely cosmetic, and the only audience for these notices is the postmaster, not naïve users. So unless Wietse is feeling exceedingly generous with his time, I don't expect to see this change any time soon. If someone wants to contribute new documentation and a patch that matches Postfix code quality and style and implements postmaster notice templates, that might speed things up, but even reviewing good code and documentation still takes time, and the priority of this issue looks especially low to me... Fair enough. Yes, I agree this is a non-essential issue, it's just that I'm _that_ kind of person when it comes to non-essential issues, that's why I decided to write about it in the first place. Thank you again for your time. --- Kind regards, Vladimir
Re: AW: Spam pass the filter
On Saturday 18 September 2021 10:13:41 ludic...@gmail.com wrote: > Hi, > > pcre header checks we use. Not all the time, depends on spam volume from > these valuable enterprises. > > #/sjmedia.us/ REJECT A mass mail service abused by criminals > #/bmsend.com/ REJECT A mass mail service abused by criminals > #/mailgun.net/REJECT A mass mail service abused by criminals > #/rsgsv.net/ REJECT A mass mail service abused by criminals > #/mcsv.net/ REJECT A mass mail service abused by criminals > #/sendgrid.net/ REJECT A mass mail service abused by criminals > #/crsend.com/ REJECT A mass mail service abused by criminals > #/zcsend.net/ REJECT A mass mail service abused by criminals > > I forgot if all those can be catched by limiting it to the Received-Line. > > Greets, > Ludi > > > -Ursprüngliche Nachricht- > Von: owner-postfix-us...@postfix.org Im > Auftrag von Christian Schmitz > Gesendet: Freitag, 17. September 2021 14:41 > An: postfix-users@postfix.org > Betreff: Spam pass the filter > > Hi everyone: > Normally when i identify a host spammer i block entire server. Today > i receive one spam email. The origin is "mailgun.net", i already have a > rule to block him, but the email pass with no problem. I want stop the > email, what is wrong? > > The header, config and rules are the following. > > Best Regards and thanks in advance > Christian Thanks to all. I do not use spamassasin since the spam and mail level is too low in my server ( 2~5 emails at day). I take the policy of block entire spammer mail server. I will read and adapt my rules. Thanks to everyone. Christian -- Be Free, Be Linux
Re: Rewriting the MAILER-DAEMON address and header formats
On Sat, Sep 18, 2021 at 08:39:41AM +0300, Vladimir Mishonov
wrote:
> What's most problematic is that while both issues #1 and #2 can be worked
> around for SOME templates, there appear to be a number of hard-coded
> templates that cannot be changed without recompiling Postfix. I understand
> that I can make changes to the source code and recompile the program, but
> even if I am able to accomplish this, it would only be half of the job done,
> if not even less than that. I'd also have to arrange a process to create
> packages in the appropriate format for my OS distribution and keep them
> updated. I'm afraid this would be very difficult and extremely
> time-consuming for me, since like I said before, I have only basic
> experience in Linux administration.
This is really just a bad joke, but instead of compiling Postfix from
source, and possibly trying to include any patches that your operating
system developers might have applied to every new version, you could
patch the relevant binaries to change MAILER-DAEMON to mailer-daemon.
Here's an example for Debian. :-)
#!/bin/sh
# Change MAILER-DAEMON to mailer-daemon for Postfix on Debian.
# There is no warranty; not even for merchantability or fitness
# for a particular purpose.
for bin in `dpkg-query -L postfix | grep bin`
do
[ -f "$bin" -a -x "$bin" ] || continue
strings "$bin" | grep -q MAILER-DAEMON || continue
echo $bin
perl -pi -e 's/MAILER-DAEMON/mailer-daemon/smg' "$bin"
done
If run, it would modify the following files:
/usr/lib/postfix/sbin/bounce
/usr/lib/postfix/sbin/cleanup
/usr/lib/postfix/sbin/local
/usr/lib/postfix/sbin/pipe
/usr/lib/postfix/sbin/showq
/usr/lib/postfix/sbin/smtpd
/usr/lib/postfix/sbin/trivial-rewrite
/usr/sbin/postconf
/usr/sbin/qshape
So any file system integrity checking would need to be informed.
And it wouldn't work on systems with cryptographically signed
binaries, but it seems fine on Debian (dpkg --audit is silent).
And bear in mind that there are other programs that hard-code
MAILER-DAEMON (e.g. dovecot, fetchmail, popclient, procmail,
amavisd-new), and as Viktor said, the case might be significant
somewhere (but hopefully not).
On a more serious note...
Have you tried using canonical_maps? I don't know if they are
applied to outgoing bounce messages, but they might be:
/etc/postfix/main.cf:
canonical_maps = hash:/etc/postfix/canonical_map
/etc/postfix/canonical_map:
mailer-dae...@mydomain.com mailer-dae...@mydomain.com
The "@mydomain.com" might not be needed.
Actually, http://www.postfix.org/ADDRESS_REWRITING_README.html
says that canonical address mapping applies to "all mail", and
it's performed by cleanup(8) which bounces pass through, so it
looks promising.
The smtp_generic_maps setting might also work, but it's only
for outgoing mail. With canonical_maps, you might even be able
to use regexp/pcre to map incoming bounce messages from other
people's mail servers to stop them shouting at you as well:
/etc/postfix/main.cf:
canonical_maps = pcre:/etc/postfix/canonical_map
/etc/postfix/canonical_map:
/^MAILER-DAEMON(@.+)?$/i mailer-daemon${1}
Note that the "i" is to make the regexp/pcre pattern case-sensitive
(because it's case-insensitive by default and the "i" toggles that).
Using hash: for canonical_maps is always case-insensitive,
so it might be better to use regexp/pcre because it enables
you to make the lookup case-sensitive. Maybe it wouldn't matter.
cheers,
raf
Re: Rewriting the MAILER-DAEMON address and header formats
On Sat, Sep 18, 2021 at 07:23:26PM +0100, Nick Howitt wrote: > I am having problems replying to the list as it keeps bouncing. This time I > am trying removing the preceding messages, > Is this an uphill battle? Excluding docs, on my system I get: > > [root@server ~]# grep MAILER-DAEMON /usr/* -r > Binary file /usr/bin/fetchmail matches > [...] > > Could changing it break other things? > > Nick I think it's safe to say that, in general, yes, changing things can break other things, especially if there is a computer involved, and what's worse is that changing them back again doesn't always unbreak the other things, especially if they were already broken but nobody had noticed yet. :-( cheers, raf
