Hello,
I have a question regarding DKIM signing on Postfix bounce back messages.
I was tuning my Dovecot installation around quotas. I sent a test message from
Hotmail to a test account on my server to test generation of a bounce back when
a user exceeds their quota. The message was successfu
Stefan Bauer:
> Our quick and dirty approach is to parse output of mailq, delete mail and
> construct a bounce message, but that is far away from a clean solution ;/
> No other way available?
Yes, see http://www.postfix.org/postconf.5.html#default_delivery_status_filter
The primary use case was a
Viktor Dukhovni:
>
>
> > On Sep 10, 2018, at 12:06 PM, Wietse Venema wrote:
> >
> > What about this?
> >
> > Example 1: convert specific soft TLS errors into hard errors, by over-
> > riding the first number in the enhanced status code.
> >
> > /etc/postfix/main.cf:
> >smtp
> On Sep 10, 2018, at 12:06 PM, Wietse Venema wrote:
>
> What about this?
>
> Example 1: convert specific soft TLS errors into hard errors, by over-
> riding the first number in the enhanced status code.
>
> /etc/postfix/main.cf:
> smtp_delivery_status_filter = pcre:/etc/
Viktor Dukhovni:
>
>
> > On Sep 10, 2018, at 7:50 AM, Stefan Bauer wrote:
> >
> > Our quick and dirty approach is to parse output of mailq, delete mail and
> > construct a bounce message, but that is far away from a clean solution ;/
> > No other way available?
>
> Not presently.
What about
> On Sep 10, 2018, at 2:25 AM, A. Schulze wrote:
>
> you may route messages from sender1 to a second postfix instance
> and configure that instance to enforce tls to $destination for _any_ sender
So far, it looks like a single instance with per-sender-class
transports will suffice.
--
> On Sep 10, 2018, at 1:58 AM, Stefan Bauer wrote:
>
> So each sender's instance is an own smtp-line in master.cf ?
Yes, one for each sender "class".
> If so - does it work like this?
>
> src_domain1 unix - - n - - smtp
>-o smtp_tls_policy_maps = hash:/etc
> On Sep 10, 2018, at 7:50 AM, Stefan Bauer wrote:
>
> Our quick and dirty approach is to parse output of mailq, delete mail and
> construct a bounce message, but that is far away from a clean solution ;/
> No other way available?
Not presently.
--
Viktor.
Our quick and dirty approach is to parse output of mailq, delete mail and
construct a bounce message, but that is far away from a clean solution ;/
No other way available?
Am So., 9. Sep. 2018 um 19:27 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>
>
> > On Sep 9, 2018, at 1:01 PM,
