DKIM Signing (postfix + amavis-new)

[John A @ KLaM]

1. This maybe off topic.
2. I am currently unable to get at the output of postconf -n etc.

In the past we have had occasional problems with DKIM signing not working. It would be one or two emails and we would not find out about the problem immediately.  Often the sender would put it down a transient blip in the system and not report the problem.

I recently had to come to NZ for family emergency and have been here for awhile and as a result have suffered the same problem on a much larger scale. It is fairly obvious that as I am sending email from an IP not in my networks and amavis-new is not signing my emails.

I found several solutions to the problem all of which were essentially the same, forward submitted (port 587) emails to amavis-new on port A, where a policy bank would be setup to sign them. All other mail would be forwarded on port B where it would be handle as per usual or normal.

My question is what is the best way of getting postfix to forward mail to the signing policy bank.
In one example the submission section of master.cf had the following lines added
smtpd_proxy_filter=[127.0.0.1]:10026
milter_macro_deamon_name=ORIGINATING
Added, I think l understand the first line but why the second, it does seem to appear anywhere else.

In another a single line was added to the submission section
Smtpd_content_filter=[127.0.0.1]:10026

John A
KlaM

[Noel Jones]

On 2/1/2016 12:30 AM, John A @ KLaM wrote:
>
> My question is what is the /best/ way of getting postfix to forward

> mail to the signing policy bank.
> In one example the submission section of master.cf had the following
> lines added
> smtpd_proxy_filter=[127.0.0.1]:10026
> milter_macro_deamon_name=ORIGINATING
> Added, I think l understand the first line but why the second, it
> does seem to appear anywhere else.

The first line assumes a before-queue proxy filter (amavisd-new)
configured to do DKIM etc. on port 10026. Your main.cf or regular
smtpd service would use a proxy filter on a different port.

The milter_macro_name parameter is used by some milters -- such as
opendkim -- to trigger DKIM signing. It's not used by amavisd-new,
but won't cause any problem to be there.

A brief discussion of before-queue filtering vs. after-queue
filtering can be found here:
http://www.postfix.org/SMTPD_PROXY_README.html#pros_cons

>
> In another a single line was added to the submission section
> Smtpd_content_filter=[127.0.0.1]:10026

This example uses an after-queue content filter.
Note: smtpd_content_filter is not a built-in postfix parameter, so
either this is a macro that must also be defined in main.cf or a typo.

This example omits the milter_macro_name, presumably because the
site does not use a milter, and has no plans to use a milter in the
future.

>
> John A
> KlaM
>

[John A @ KLaM]

Thanks for explaination.

>> Smtpd_content_filter=[127.0.0.1]:10026

Typo, or rather my cell phone auto completing things for me and me not
catching it.

If I might ask another peripheraly related and most probably very dumb
question - is it possible to the have the inverse of
"permit_authenticated_users"?
The rules for this outfit are - imap for picking up you mail, submission
(port 587) for sending. So if somebody who can authenticate themselves
turns up on port 25, they are in the wrong place.


John A
Sent from my S3

[Noel Jones]

On 2/2/2016 5:53 PM, John A @ KLaM wrote:
> If I might ask another peripheraly related and most probably very
> dumb question - is it possible to the have the inverse of
> "permit_authenticated_users"?
> The rules for this outfit are - imap for picking up you mail,
> submission (port 587) for sending. So if somebody who can
> authenticate themselves turns up on port 25, they are in the wrong
> place.

This is commonly handled by not offering AUTH on port 25. Users who
end up there find sending mail doesn't work, and usually recheck
their settings before calling.

Take all the sasl statements out of main.cf, and add them as -o
options to the "submission" service in master.cf.

Something like:
# main.cf
smtpd_sasl_auth_enable = no

# master.cf
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
... other stuff you like ...





-- Noel Jones

[John]

After some interesting experiences using a less than stellar communications (I didn't appreciate just how lucky I am to live in a big city until this trip) I have managed to get things setup and working.

Because of the poor communications I decided to use the families server as a guinea pig.
I reconfigured it to be fairly close to the eventual target system as possible.
I made the changes that Noel suggested and it appears to be working.
The original problem with DKIM ... seem to be resolved.

Before I attempt to modify the eventual target system can someone take a look at the attached main and master postconf outputs. My main concern is that I have left something important out, not that I will not appreciate suggestions for improvement.