How to pass "no_milters" option to pickup daemon?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

How to pass "no_milters" option to pickup daemon?

Jaroslaw Rafa
Hello All,
I am using spamassassin with my postfix setup in form of "simple
content filter", as described here:
http://www.postfix.org/FILTER_README.html#simple_filter . That means, smtp
server has the option "-o content_filter=spamassassin" defined in master.cf
file, and also a service named "spamassassin", which calls the filter
script, is defined in master.cf file.

This works fine except for one thing. I also use OpenDKIM to DKIM sign
outgoing mail, and therefore have milters connecting to OpenDKIM server
defined in main.cf file:

smtpd_milters = inet:localhost:10025
non_smtpd_milters = inet:localhost:10025

I must define both smtpd_milters and non_smtpd_milters, as most mail is sent
from mutt running directly on server, so they are sent by directly calling
/usr/lib/sendmail.

And here is where the trouble comes. When a mail arrives to my server with
my own address as the sender (for example, my emails coming back from a
mailing list), the content filter script also calls /usr/lib/sendmail to put
the message back in the queue, and hence the message is again signed by
DKIM. I want to avoid this.

I tried to run /usr/lib/sendmail which gets called by filter script with
another main.cf file (specified by "-C" parameter), that doesn't include the
above milter lines, but, on the other hand, does include
"receive_override_options = no_milters". However, this doesn't help - the
second signature still appears. Looks like the "no_milters" parametr is not
passed to pickup daemon this way.

How to configure this so that after the content filter no milters are used
again?
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"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."
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Viktor Dukhovni
> On Sep 26, 2019, at 1:00 PM, Jaroslaw Rafa <[hidden email]> wrote:
>
> And here is where the trouble comes. When a mail arrives to my server with
> my own address as the sender (for example, my emails coming back from a
> mailing list), the content filter script also calls /usr/lib/sendmail to put
> the message back in the queue, and hence the message is again signed by
> DKIM. I want to avoid this.
>
> I tried to run /usr/lib/sendmail which gets called by filter script with
> another main.cf file (specified by "-C" parameter), that doesn't include the
> above milter lines, but, on the other hand, does include
> "receive_override_options = no_milters". However, this doesn't help - the
> second signature still appears. Looks like the "no_milters" parametr is not
> passed to pickup daemon this way.

The most robust approach that comes to mind is a multi-instance configuration:

   http://www.postfix.org/MULTI_INSTANCE_README.html#quick

in which local submission is handled by a null-client Postfix that forwards
to an outbound Postfix instance that signs with DKIM, while inbound SMTP is
handled by a separate Postfix instance that verifies DKIM, and where the
pickup service is statically defined to not use any milters, or use only
the appropriate milters.

Alternatively, use SMTP content filters, where multiple parallel channels
are possible.  There is only one pickup(8) and maildrop queue directory
in each Postfix instance.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Wietse Venema
In reply to this post by Jaroslaw Rafa
Jaroslaw Rafa:

> Hello All,
> I am using spamassassin with my postfix setup in form of "simple
> content filter", as described here:
> http://www.postfix.org/FILTER_README.html#simple_filter . That means, smtp
> server has the option "-o content_filter=spamassassin" defined in master.cf
> file, and also a service named "spamassassin", which calls the filter
> script, is defined in master.cf file.
>
> This works fine except for one thing. I also use OpenDKIM to DKIM sign
> outgoing mail, and therefore have milters connecting to OpenDKIM server
> defined in main.cf file:
>
> smtpd_milters = inet:localhost:10025
> non_smtpd_milters = inet:localhost:10025
>
> I must define both smtpd_milters and non_smtpd_milters, as most mail is sent
> from mutt running directly on server, so they are sent by directly calling
> /usr/lib/sendmail.
>
> And here is where the trouble comes. When a mail arrives to my server with
> my own address as the sender (for example, my emails coming back from a
> mailing list), the content filter script also calls /usr/lib/sendmail to put
> the message back in the queue, and hence the message is again signed by
> DKIM. I want to avoid this.
>
> I tried to run /usr/lib/sendmail which gets called by filter script with
> another main.cf file (specified by "-C" parameter), that doesn't include the
> above milter lines, but, on the other hand, does include
> "receive_override_options = no_milters". However, this doesn't help - the
> second signature still appears. Looks like the "no_milters" parametr is not
> passed to pickup daemon this way.

Would not "sendmail -G" suppress local modification?

   -G     Gateway (relay) submission, as opposed to initial  user  submis-
          sion.   Either do not rewrite addresses at all, or update incom-
          plete addresses  with  the  domain  information  specified  with
          remote_header_rewrite_domain.

This is the recommended setting for post-filter re-injection. With
this, Postfix pretends that the mail is from a remote origin.

        Wietse

> How to configure this so that after the content filter no milters are used
> again?
> --
> Regards,
>    Jaroslaw Rafa
>    [hidden email]
> --
> "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."
>
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Jaroslaw Rafa
Dnia 26.09.2019 o godz. 13:31:53 Wietse Venema pisze:

>
> Would not "sendmail -G" suppress local modification?
>
>    -G     Gateway (relay) submission, as opposed to initial  user  submis-
>           sion.   Either do not rewrite addresses at all, or update incom-
>           plete addresses  with  the  domain  information  specified  with
>           remote_header_rewrite_domain.
>
> This is the recommended setting for post-filter re-injection. With
> this, Postfix pretends that the mail is from a remote origin.

Of course the filter script is running with "-G" parameter, however, I guess
this doesn't disable the use of milters (because why should it?). And
according to Postfix documentation, "When new mail arrives via the
sendmail(1) command line, the Postfix cleanup(8) server pretends that the
mail arrives with ESMTP from "localhost" with IP address "127.0.0.1"." So,
OpenDKIM milter sees that the mail comes from "127.0.0.1" and the sender in
"From:" line is from my domain, and signs it.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"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."
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:
> Would not "sendmail -G" suppress local modification?
>
>    -G     Gateway (relay) submission, as opposed to initial  user  submis-
>           sion.   Either do not rewrite addresses at all, or update incom-
>           plete addresses  with  the  domain  information  specified  with
>           remote_header_rewrite_domain.
>
> This is the recommended setting for post-filter re-injection. With
> this, Postfix pretends that the mail is from a remote origin.

This text pre-dates Milter support, and not every feature or
documentation has been updated when Milter support was added.

On second consideration, Postfix does run remote mail through
Milters, so the -G flag probably does not affect Milters.

So this would be a gap in coverage, in the sense that not all
receive_override_options have a Postfix sendmail command-line
equivalent.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Jaroslaw Rafa
In reply to this post by Viktor Dukhovni
Dnia 26.09.2019 o godz. 13:08:02 Viktor Dukhovni pisze:
> The most robust approach that comes to mind is a multi-instance configuration:
>
>    http://www.postfix.org/MULTI_INSTANCE_README.html#quick

I think that running such a big and complicated setup is definitely a kind
of overkill for so small server like mine :)

> Alternatively, use SMTP content filters, where multiple parallel channels
> are possible.  There is only one pickup(8) and maildrop queue directory
> in each Postfix instance.

Wouldn't it be possible to run a second pickup(8) instance with a different
configuration file, without milters and configured for a different queue
directory?  And then run the after-filter sendmail(1) also configured for
that queue directory?
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"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."
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Viktor Dukhovni


> On Sep 26, 2019, at 1:43 PM, Jaroslaw Rafa <[hidden email]> wrote:
>
>> The most robust approach that comes to mind is a multi-instance configuration:
>>
>>   http://www.postfix.org/MULTI_INSTANCE_README.html#quick
>
> I think that running such a big and complicated setup is definitely a kind
> of overkill for so small server like mine :)

I find multiple instances simple, ... divide and conquer.  Each instance is
a single-purpose construction, with no tension between potentially conflicting
requirements.  Perhaps unfamiliar at first, but not significantly complicated.
Then again, I instigated multi-instance support and wrote a non-trivial chunk
of the code, so not exactly a neutral reporter...

>> Alternatively, use SMTP content filters, where multiple parallel channels
>> are possible.  There is only one pickup(8) and maildrop queue directory
>> in each Postfix instance.
>
> Wouldn't it be possible to run a second pickup(8) instance with a different
> configuration file, without milters and configured for a different queue
> directory?  And then run the after-filter sendmail(1) also configured for
> that queue directory?

This is likely "not possible".  Even if some gross hack could make this go,
by the time you have multiple config files, just go with multiple instances,
which are supported.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Wietse Venema
Viktor Dukhovni:
> > Wouldn't it be possible to run a second pickup(8) instance with a different
> > configuration file, without milters and configured for a different queue
> > directory?  And then run the after-filter sendmail(1) also configured for
> > that queue directory?
>
> This is likely "not possible".  Even if some gross hack could make this go,
> by the time you have multiple config files, just go with multiple instances,
> which are supported.

The simplest is to avoid "content filter -> /usr/sbin/sendmail" and
instead use SMTP-based or Milter-based content inspection.

Then, you don't have to squeeze unfiltered and filtered email through
the same /usr/sbin/sendmail hole.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: How to pass "no_milters" option to pickup daemon?

Jaroslaw Rafa
Dnia 26.09.2019 o godz. 14:48:56 Wietse Venema pisze:
>
> The simplest is to avoid "content filter -> /usr/sbin/sendmail" and
> instead use SMTP-based or Milter-based content inspection.

Yes, it looks that the easiest option was to move from running spamassassin
as after-queue content filter to running it as a milter. Thus there is no
need to invoke sendmail for the second time, and the issue disappears.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"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."