Getting DKIM to work with Mailman and Postfix

[James B. Byrne]

I am wrestling with the issues arising from Yahoo.com, and now AOL.com,
enforcing dkim for their addresses. Specifically we run a small number of
mailing lists using Mailman which have a large number of subscribers from both
these domains. As Mailman is configured to forward mail without altering the
FROM: header this trips the DKIM reject.

We have installed and configured OpenDKIM on our smtp relay, generated the
private keys, configured the KeyTable and SigningTable files and published the
necessary _domainkey.domain DNS records.

Our desired solution is to have mail forwared by Mailman resigned using the
Sender, where present, instead of the From header. As Mailman does set the
Sender properly, according to reports from auth-r...@verifier.port25.com we
altered the configuration of opendkim.conf to this: SenderHeaders Sender,From.

Dkim is configured in main.cf thus:

# set up opendkim - also see: /etc/opendkim.conf and /etc/opendkim/TrustedHosts
# make sure opendkim service is running
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 2


Mailman is interfaced to Postfix using this entry in master.cf

# Local delivery of mailing list traffic
mailman unix - n n - - pipe
flags=FR user=mailman:mailman
argv=/usr/lib/mailman/postfix/postfix-to-mailman.py ${nexthop} ${user}

The problem that we have is that mail being forwarded from Mailman is not
being signed at all. And I suspect that it relates to the fact that the
Mailman MLM and the Postfix MTA reside on the same server. When I look at a
test message sent through the MLM to the auth-resultes address I see this:


header.Sender=logistics...@mailman.halisp.net

Received: from localhost (localhost [127.0.0.1])
by inet08.hamilton.harte-lyne.ca (Postfix) with ESMTP id 36876609A5
for <check...@verifier.port25.com>; Mon, 5 May 2014 12:30:20 -0400
(EDT)

X-Virus-Scanned: amavisd-new at harte-lyne.ca

Received: from inet08.hamilton.harte-lyne.ca ([127.0.0.1])
by localhost (inet08.hamilton.harte-lyne.ca [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id JUcMvst-FkzK for <check...@verifier.port25.com>;
Mon, 5 May 2014 12:30:19 -0400 (EDT)

Received: from inet08.hamilton.harte-lyne.ca (localhost [IPv6:::1])
by inet08.hamilton.harte-lyne.ca (Postfix) with ESMTP
for <check...@verifier.port25.com>; Mon, 5 May 2014 12:30:19 -0400
(EDT)


Received: from localhost (localhost [127.0.0.1])
by inet08.hamilton.harte-lyne.ca (Postfix) with ESMTP id F2EDF609C8
for <logis...@mailman.harte-lyne.ca>;
Mon, 5 May 2014 12:30:17 -0400 (EDT)

X-Virus-Scanned: amavisd-new at harte-lyne.ca

Received: from inet08.hamilton.harte-lyne.ca ([127.0.0.1])
by localhost (inet08.hamilton.harte-lyne.ca [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id AuPvOnGIir-m for <logis...@mailman.harte-lyne.ca>;
Mon, 5 May 2014 12:30:16 -0400 (EDT)

Received: from webmail.harte-lyne.ca (inet04.hamilton.harte-lyne.ca
[216.185.71.24])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by inet08.hamilton.harte-lyne.ca (Postfix) with ESMTPSA id A9475609A5
for <logis...@mailman.harte-lyne.ca>;
Mon, 5 May 2014 12:30:16 -0400 (EDT)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=harte-lyne.ca;
s=dkim_hll; t=1399307416;
bh=z0DQjPUP3iSnJocIWpmAvVX8Alr4K8XVzrxjZOaSExM=;
h=Date:Subject:From:To;
b=IzhcNAwvf+zYpkcZNewyIGKhI7KTx0QviTFyWvhDUjzHJHODKVnq555p3QWyLMnWk
E0CFEVQov6ehMHDW/OsDJ3MSAAz7ijAU4xe8jl7/j2Tb0msjU0sBJ1nWdupKcl1Bxh
A+09YBd/IhBgUZsseUr8gJm8eV566jYmOwitoOpMuCCoDhbarW1YBGfBu3Gvs7hd5w
PO4mp3KFK/ym7iFgRg8dVGCR0w+21BcJhqpMrdHs29pEzd2+tpOzCPGVg/fxe/JtsQ
JI/cClyHLTGq82wwLHF5xdY+fjCa31xb74sm+0mDNPA6+g1iB9Spn4o2gR0CADRTEr
4PsC8BCP3f8nQ==
Received: from 216.185.71.44 (SquirrelMail authenticated user byrnejb)
by webmail.harte-lyne.ca with HTTP; Mon, 5 May 2014 12:30:16 -0400

Message-ID: <607174e03d92b090d756...@webmail.harte-lyne.ca>

Date: Mon, 5 May 2014 12:30:16 -0400
From: "James B. Byrne" <byr...@harte-lyne.ca>
To: logis...@mailman.harte-lyne.ca
User-Agent: SquirrelMail/1.4.22-4.el6
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Subject: [Logistics-l] dkim test
X-BeenThere: logis...@mailman.halisp.net
X-Mailman-Version: 2.1.12

So, If I read this aright then the test email from me via the webmail
interface is send to our MTA at ineto8. Inet08 signs the original mail and
sends it to the Amavisd mail scanner. The mail returns to postfix who then
submits it to Mailman? from the local address (127.0.0.1) and therein lies the
problem I think. The mail then is forwarded on directly to the addresses and
does not pass through Postfix again to be re-signed.

Is there any way to accomplish this and have the reinjected mail from mailman
pass through the dkim milter a second time?

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

[James B. Byrne]

I should have provided this in my original post:

CentOS-6.5 (x86_64)
Postfix-2.6.6
Mailman-2.1.12
OpenDKIM-2.9.0

# postconf -n
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 32
debug_peer_list = 216.185.71.25
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
html_directory = no
inet_interfaces = localhost, inet08.hamilton.harte-lyne.ca
inet_protocols = all
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 20480000

milter_default_action = accept
milter_protocol = 2

mydestination =
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
queue_minfree = 40960000
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_use_tls = yes
smtpd_client_restrictions = permit
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce,
reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname, permit

smtpd_milters = inet:127.0.0.1:8891

smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_invalid_hostname,
reject_unauth_destination, reject_unauth_pipelining, check_policy_service
unix:private/policyd-spf, sleep 1, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access
hash:/etc/postfix/sender_access, permit
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual

[Marius Gologan]

I've noticed you are using amavisd-new. It can easily sign your messages.

I'm showing what I use:

cat /etc/amavis/conf.d/22-dkim
use strict;

$enable_dkim_signing = 1;

dkim_key('domain1.com', 'dkim', '/path/to/domain1.com-dkim.key.pem');
@dkim_signature_options_bysender_maps = (
{ '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
@mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12
192.168.0.0/16 ); # list your internal networks

1; # ensure a defined return


Generate certificate:
amavisd-new genrsa /path/to/domain1.com-dkim.key.pem 2048


Show the formatted value for DNS TXT record:
amavisd-new showkeys domain1.com


Marius.

smtpd_milters = inet:127.0.0.1:8891

non_smtpd_milters = $smtpd_milters

milter_default_action = accept
milter_protocol = 2

[Wietse Venema]

James B. Byrne:

> I am wrestling with the issues arising from Yahoo.com, and now AOL.com,
> enforcing dkim for their addresses. Specifically we run a small number of
> mailing lists using Mailman which have a large number of subscribers from both
> these domains. As Mailman is configured to forward mail without altering the
> FROM: header this trips the DKIM reject.

The DMARC FAQ, specifically http://dmarc.org/faq.html#s_3, shows
that there are different solutions with different pros and cons.

The examples at the end of that section show how a few organizations
implemented the DKIM / SPF requirement from Yahoo and AOL.

Short answer: this is not built into Postfix (if I could look 16
years into the future then I would be very rich). I do not have
time to come up with a solution in the coming months. Postfix is
free but my time is not.

Wietse

[James B. Byrne]

On Mon, May 5, 2014 14:29, Marius Gologan wrote:
> I've noticed you are using amavisd-new. It can easily sign your messages.
>
> I'm showing what I use:
>
> cat /etc/amavis/conf.d/22-dkim
> use strict;
>
> $enable_dkim_signing = 1;
>
> dkim_key('domain1.com', 'dkim', '/path/to/domain1.com-dkim.key.pem');
> @dkim_signature_options_bysender_maps = (
> { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
> @mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12
> 192.168.0.0/16 ); # list your internal networks
>
> 1; # ensure a defined return
>
>
> Generate certificate:
> amavisd-new genrsa /path/to/domain1.com-dkim.key.pem 2048
>
>
> Show the formatted value for DNS TXT record:
> amavisd-new showkeys domain1.com
>
>
> Marius.

Forgive me if I do not understand what you are trying to convey. We already
have Postfix DKIM correctly signing emails originating in our domains and
passing through our outgoing smtp gateway. The problem is that mail that
comes to that host destined for a Mailman mailing list is not being signed
when it is forwarded out again. That is what I want to have fixed.

I am not sure of anything but at the moment my belief is that the Mailman
forwarded mail is not being processed by OpenDKIM because of this entry in
master.cf:

# Before-queue Amavis after-filter processing
# Receive amavis re-injection and do no other checks
#
127.0.0.1:10025
inet n - n - - smtpd
-o content_filter=
. . .
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,
-->> no_milters, <<-- no_address_mappings

Just a guess mind you. However, I am not yet desperate enough to play around
with this without some informed guidance on the matter.

[li...@rhsoft.net]

Am 05.05.2014 20:45, schrieb James B. Byrne:
> Forgive me if I do not understand what you are trying to convey. We already
> have Postfix DKIM correctly signing emails originating in our domains and
> passing through our outgoing smtp gateway. The problem is that mail that
> comes to that host destined for a Mailman mailing list is not being signed
> when it is forwarded out again. That is what I want to have fixed.

that is *not* a postfix problem, you need a recent mailman version

there are millions of google hits
https://www.google.com/#q=mailman+dmarc

[James B. Byrne]

On Mon, May 5, 2014 14:42, Wietse Venema wrote:
>
> The DMARC FAQ, specifically http://dmarc.org/faq.html#s_3, shows
> that there are different solutions with different pros and cons.

Yes, I am aware of that resource. In fact what I am trying to accomplish is a
variant of

B. Replace From: address, set Reply-To: to message author

Change the RFC5322.From address to an address within the mailing
list's domain
us...@example.com => add...@mailinglistdomain.com
Set or change the RFC5322.ReplyTo address to the message author
-->> Add DKIM signature using the mailing list's domain <<--

>
> The examples at the end of that section show how a few organizations
> implemented the DKIM / SPF requirement from Yahoo and AOL.
>
> Short answer: this is not built into Postfix (if I could look 16
> years into the future then I would be very rich). I do not have
> time to come up with a solution in the coming months. Postfix is
> free but my time is not.
>
> Wietse
>

I was not expecting any alteration to the existing software since I presumed
that my problem was in essence simply a configuration issue beyond my current
ability to diagnose. It seems to me though that if the Postfix handoff to
Mailman could be configured to resubmit the forwarded mail from Mailman back
to Postfix for delivery as if it were a new message instead of injecting it
back into the Postfix queue after the submission stage (if that indeed is what
happens) then the opendkim signing of the forwarded message would take place.
Is this configuration not possible?

I tried modifying mm_cfg.py to resubmit to port 587 but that had no effect on
observed behaviour

[James B. Byrne]

On Mon, May 5, 2014 14:58, li...@rhsoft.net wrote:
>
>
> Am 05.05.2014 20:45, schrieb James B. Byrne:
>> Forgive me if I do not understand what you are trying to convey. We already
>> have Postfix DKIM correctly signing emails originating in our domains and
>> passing through our outgoing smtp gateway. The problem is that mail that
>> comes to that host destined for a Mailman mailing list is not being signed
>> when it is forwarded out again. That is what I want to have fixed.
>
> that is *not* a postfix problem, you need a recent mailman version
>

And although I have not the life expectancy to read them all I have found and
read many. And I never said that it was a Postfix PROBLEM. I thought that
asked if it were not possible to configure Mailman with Postfix so that
Mailman's forwarded messages are reprocessed through the milters and signed
thereby opendkim rather then sent on directly. On the face of it the question
seems reasonable enough. Is there in fact no way to do this?

[li...@rhsoft.net]

Am 05.05.2014 21:17, schrieb James B. Byrne:
> On Mon, May 5, 2014 14:58, li...@rhsoft.net wrote:
>>
>> Am 05.05.2014 20:45, schrieb James B. Byrne:
>>> Forgive me if I do not understand what you are trying to convey. We already
>>> have Postfix DKIM correctly signing emails originating in our domains and
>>> passing through our outgoing smtp gateway. The problem is that mail that
>>> comes to that host destined for a Mailman mailing list is not being signed
>>> when it is forwarded out again. That is what I want to have fixed.
>>
>> that is *not* a postfix problem, you need a recent mailman version
>>
>
> And although I have not the life expectancy to read them all I have found and
> read many. And I never said that it was a Postfix PROBLEM. I thought that
> asked if it were not possible to configure Mailman with Postfix so that
> Mailman's forwarded messages are reprocessed through the milters and signed
> thereby opendkim rather then sent on directly. On the face of it the question
> seems reasonable enough. Is there in fact no way to do this?

as said: you need a recent mailman version

http://marc.info/?l=centos&m=139886198321420&w=2

[Wietse Venema]

James B. Byrne:

> I was not expecting any alteration to the existing software since I presumed
> that my problem was in essence simply a configuration issue beyond my current
> ability to diagnose. It seems to me though that if the Postfix handoff to
> Mailman could be configured to resubmit the forwarded mail from Mailman back
> to Postfix for delivery as if it were a new message instead of injecting it
> back into the Postfix queue after the submission stage (if that indeed is what
> happens) then the opendkim signing of the forwarded message would take place.
> Is this configuration not possible?

What program is being used to sign the mail?

For this program to sign mailman submissions, those submissions
must follow a path that runs through that same program. What evidence
do you have that mail is actually following that path?

Wietse

[James B. Byrne]

On Mon, May 5, 2014 15:21, li...@rhsoft.net wrote:
>
> as said: you need a recent mailman version
>
> http://marc.info/?l=centos&m=139886198321420&w=2
>

I see no useful purpose to referring me to one of my own posts looking for
said, and non-existent for the moment, "recent" mailman edition. I did not
come here as a first reaction. I did seek alternative solutions. I still do
not understand why mail forwarded from Mailman cannot be fed into the front
end of Postfix and passed though the opendkim milter for signing. That should
be possible regardless of the Mailman version I should think.

[li...@rhsoft.net]

Am 05.05.2014 21:28, schrieb James B. Byrne:
>
> On Mon, May 5, 2014 15:21, li...@rhsoft.net wrote:
>>
>> as said: you need a recent mailman version
>>
>> http://marc.info/?l=centos&m=139886198321420&w=2
>>
>
> I see no useful purpose to referring me to one of my own posts looking for
> said, and non-existent for the moment, "recent" mailman edition. I did not
> come here as a first reaction. I did seek alternative solutions. I still do
> not understand why mail forwarded from Mailman cannot be fed into the front
> end of Postfix and passed though the opendkim milter for signing. That should
> be possible regardless of the Mailman version I should think

because you *can not and must not* sign a message with @aol.com or
whatever provider - you have to get rid of that sender address and
use the list ones to satisfy DMARC

[Larry Stone]

On Mon, 5 May 2014, James B. Byrne wrote:

> And although I have not the life expectancy to read them all I have found and
> read many. And I never said that it was a Postfix PROBLEM. I thought that
> asked if it were not possible to configure Mailman with Postfix so that
> Mailman's forwarded messages are reprocessed through the milters and signed
> thereby opendkim rather then sent on directly. On the face of it the question
> seems reasonable enough. Is there in fact no way to do this?

Of course it's possible. But the how is really a Mailman question, not a
Postfix question, so your question is probably best asked on the Mailman
list. I do it with my Mailman/Postfix server.

But merely adding a DKIM signature at your system will not solve the DMARC
issue. The list you quoted from DMARC FAQ ealier is not a "do one of
these", it's a "do all of these".

Mailman 2.1.18 (released just this past weekend) has workarounds for the
From and Reply-To piece of this. And despite your claim that you told
Mailman to send to port 587 instead (no proof provided), you must not have
done what you thought you did. But the Mailman list is the place for what
you need.

-- Larry Stone
lsto...@stonejongleux.com

[Marius Gologan]

I prefer amavis instead of opendkim as a personal choice. You could run a
simpler test machine and see all applicable cases. Some are not.

What I've sent is applicable when amavisd-new is used after-queue, not
before-queue.

Incoming messages from Internet cannot be signed, since you cannot publish
your public key on someone's domain. Only the owner can authorize your
machine to send emails for those domains.
Hence, @domain and IP are related.

If mailman has limited technicalities, send the message back to a reliable
machine, as Postfix and sign the outgoing message.
If the message appears as from @gmail.com @yahoo.com is no point in DKIM.

Marius.

-----Original Message-----
From: James B. Byrne [mailto:byr...@harte-lyne.ca]
Sent: Monday, May 5, 2014 9:46 PM
To: Postfix users
Cc: Marius Gologan
Subject: RE: Getting DKIM to work with Mailman and Postfix


On Mon, May 5, 2014 14:29, Marius Gologan wrote:
> I've noticed you are using amavisd-new. It can easily sign your messages.
>
> I'm showing what I use:
>
> cat /etc/amavis/conf.d/22-dkim
> use strict;
>
> $enable_dkim_signing = 1;
>
> dkim_key('domain1.com', 'dkim', '/path/to/domain1.com-dkim.key.pem');
> @dkim_signature_options_bysender_maps = (
> { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
> @mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12
> 192.168.0.0/16 ); # list your internal networks
>
> 1; # ensure a defined return
>
>
> Generate certificate:
> amavisd-new genrsa /path/to/domain1.com-dkim.key.pem 2048
>
>
> Show the formatted value for DNS TXT record:
> amavisd-new showkeys domain1.com
>
>
> Marius.

Forgive me if I do not understand what you are trying to convey. We already
have Postfix DKIM correctly signing emails originating in our domains and
passing through our outgoing smtp gateway. The problem is that mail that
comes to that host destined for a Mailman mailing list is not being signed
when it is forwarded out again. That is what I want to have fixed.

I am not sure of anything but at the moment my belief is that the Mailman
forwarded mail is not being processed by OpenDKIM because of this entry in
master.cf:

# Before-queue Amavis after-filter processing # Receive amavis re-injection
and do no other checks #
127.0.0.1:10025
inet n - n - - smtpd
-o content_filter=
. . .
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,
-->> no_milters, <<-- no_address_mappings

Just a guess mind you. However, I am not yet desperate enough to play
around with this without some informed guidance on the matter.

[James B. Byrne]

As the attempt failed there cannot be any proof other than showing that I set
this in mm_cfg.py

SMTPPORT = 587

However, I suspect that I tripped up over authentication on that port and the
mailman forwarded messages never got to Postfix in consequence. I will take
this up on the Mailman list. Thank you for your assistance.

I am aware that Mailman-2.1.18 has been released. Sadly I must await the
folks at epel to package it due to corporate constraints. So I had hoped that
there might be a work around I could find that made use of the software that I
already have.

[James B. Byrne]

On Mon, May 5, 2014 15:22, Wietse Venema wrote:

> What program is being used to sign the mail?

opendkim

>
> For this program to sign mailman submissions, those submissions
> must follow a path that runs through that same program. What evidence
> do you have that mail is actually following that path?
>
> Wietse
>

It is not happening and that is what I am trying get to happen. The messages
are being distributed by Mailman but they are not being signed. I now
understand from the information provided to me on this list that even if I get
this to happen and manage to have Mailman forwarded messages re-signed based
on the Sender header that the DKIM rejects will nonetheless continue as Yahoo
and AoL will only consider the From header for DKIM purposes.

And that is the expected and necessary behaviour I realize upon reflection.

[Wietse Venema]

James B. Byrne:

> On Mon, May 5, 2014 15:22, Wietse Venema wrote:
>
> > What program is being used to sign the mail?
>
> opendkim
>
> >
> > For this program to sign mailman submissions, those submissions
> > must follow a path that runs through that same program. What evidence
> > do you have that mail is actually following that path?
>

> It is not happening and that is what I am trying get to happen. The messages

Well nothing works without correct configuration. Is your SMTP
server correctly set up to sign local submissions on 127.0.0.1
and the TCP port that mailman is talking to?

You'd have to verify that first. Only then does it make sense
to try to make signing work with mailman submission on 127.0.0.1.

Wietse

[Viktor Dukhovni]

On Mon, May 05, 2014 at 04:55:42PM -0400, James B. Byrne wrote:


> And that is the expected and necessary behaviour I realize upon reflection.

The DMARC specifications should have allowed the Sender: header to
preempt From:, it did not. Expected yes, can't say I am willing
to call this mistake "necessary".

--
Viktor.

[Sahil Tandon]

On Mon, 2014-05-05 at 13:11:31 -0400, James B. Byrne wrote:

> I am wrestling with the issues arising from Yahoo.com, and now
> AOL.com, enforcing dkim for their addresses. Specifically we run a
> small number of mailing lists using Mailman which have a large number
> of subscribers from both these domains. As Mailman is configured to
> forward mail without altering the FROM: header this trips the DKIM
> reject.

FWIW, we were bitten by this DMARC issue on the freebsd.org mailing
lists and dealt with it as per:

http://wiki.list.org/x/ggARAQ
http://wiki.list.org/display/DEV/DMARC

i.e., set dmarc_moderation_action and dmarc_quarantine_moderation_action
in Mailman rather than changing Postfix.

--
Sahil Tandon

[James B. Byrne]

We run a RHEl6/CentOS6 shop. RH ships RHEL6 with Mailman-2.1.12, backporting
security fixes as necessary but without incrementing the version number. This
is what is available from CentOS in consequence. EPEL does not appear to have
a more recent version available either. Bottom line is that I do not have
access to an approved packaged version of a more recent Mailman so that i
cannot do a you suggest.

Presently I am attempting to build a 2.1.18 packaged version for our internal
deployment. Unhappily, RH puts things for Mailman-2.1.12 in many different
places from those given in the source. Thus getting the new version built
successfully and then installing correctly is proving a tad tedious.

Thanks for the suggestion though. If I ever get the replacement built
correctly or source a 2.1.18 package elsewhere then I will use your
suggestion.

Regards,

[James B. Byrne]

On Mon, May 5, 2014 17:50, Wietse Venema wrote:

>
> Well nothing works without correct configuration. Is your SMTP
> server correctly set up to sign local submissions on 127.0.0.1
> and the TCP port that mailman is talking to?
>
> You'd have to verify that first. Only then does it make sense
> to try to make signing work with mailman submission on 127.0.0.1.
>

This is my MSA configuration in Master.cf

submission inet n - n - - smtpd -v
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
# -o smtpd_client_restrictions=check_sender_access
hash:/etc/postfix/sender_access,permit_sasl_authenticated,reject
-o
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
# -o smtpd_sender_restrictions=check_sender_access
hash:/etc/postfix/sender_access,permit_sasl_authenticated,permit_tls_clientcerts,reject
-o
smtpd_sender_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject
-o milter_macro_daemon_name=ORIGINATING
-o syslog_name=postfix-p587


And in main.cf I have this:

smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit

smtpd_sender_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/sender_access,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit

# RBL lookups handled in spamassassin so need for them here
smtpd_client_restrictions = permit
. . .
# enable tls
#
smtp_use_tls=yes
smtpd_use_tls=yes
# log for testing only
#smtpd_tls_loglevel = 3

# but do not require tls for all connections
smtp_tls_security_level = may
smtpd_tls_security_level = may

# but do require it for authenticated connections
#
smtpd_tls_auth_only = yes



I have only cursory knowledge of Postfix but I suspect that the problem may
lie with encryption on the submission interface. I see this in master.cf

-o smtpd_tls_security_level=encrypt

and I do not understand how that matches with the directives in main.cf.
Should the encryption option in master.cf be removed entirely?

Thank you for your assistance.

[Wietse Venema]

James B. Byrne:

> > Well nothing works without correct configuration. Is your SMTP
> > server correctly set up to sign local submissions on 127.0.0.1
> > and the TCP port that mailman is talking to?
> >
> > You'd have to verify that first. Only then does it make sense
> > to try to make signing work with mailman submission on 127.0.0.1.
> >
>
> This is my MSA configuration in Master.cf
>
> submission inet n - n - - smtpd -v
> -o smtpd_tls_security_level=encrypt
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> # -o smtpd_client_restrictions=check_sender_access
> hash:/etc/postfix/sender_access,permit_sasl_authenticated,reject
> -o
> smtpd_recipient_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
> # -o smtpd_sender_restrictions=check_sender_access
> hash:/etc/postfix/sender_access,permit_sasl_authenticated,permit_tls_clientcerts,reject
> -o
> smtpd_sender_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject
> -o milter_macro_daemon_name=ORIGINATING
> -o syslog_name=postfix-p587

With this port 587 service, have you ever been able to send out any
Mailman email at all, regardless of whether it is DKIM signed?

Wietse

[James B. Byrne]

On Tue, May 6, 2014 10:20, Wietse Venema wrote:
> James B. Byrne:
>> > Well nothing works without correct configuration. Is your SMTP
>> > server correctly set up to sign local submissions on 127.0.0.1
>> > and the TCP port that mailman is talking to?
>> >
>> > You'd have to verify that first. Only then does it make sense
>> > to try to make signing work with mailman submission on 127.0.0.1.
>> >
>>
>> This is my MSA configuration in Master.cf
>>
>> submission inet n - n - - smtpd -v
>> -o smtpd_tls_security_level=encrypt
>> -o smtpd_sasl_auth_enable=yes
>> -o
>> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
>> # -o smtpd_client_restrictions=check_sender_access
>> hash:/etc/postfix/sender_access,permit_sasl_authenticated,reject
>> -o
>> smtpd_recipient_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
>> # -o smtpd_sender_restrictions=check_sender_access
>> hash:/etc/postfix/sender_access,permit_sasl_authenticated,permit_tls_clientcerts,reject
>> -o
>> smtpd_sender_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject
>> -o milter_macro_daemon_name=ORIGINATING
>> -o syslog_name=postfix-p587
>

I never tried before this incident and that attempt failed as I previously
reported. I am not attempting to sign mailman messages at the moment. I am
just trying to get the submission port to work.

[Wietse Venema]

James B. Byrne:

> >> This is my MSA configuration in Master.cf
> >>
> >> submission inet n - n - - smtpd -v

[...]

Wietse:
[have you ever used this with mailman before?]

James B. Byrne:

> I never tried before this incident and that attempt failed as I previously
> reported. I am not attempting to sign mailman messages at the moment. I am
> just trying to get the submission port to work.

Well maybe we should leave port 587 for MUA clients only, and set
up a mailman submission service that does not require TLS or SASL.

The following still sets the "ORIGINATING" bits so that the Milter
will (hopefully) do the right thing.

master.cf:
127.0.0.1:26 inet n - n - - smtpd
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=
-o milter_macro_daemon_name=ORIGINATING
-o syslog_name=postfix-p26

With this in place, do "postfix reload" and see if mailman can
send a test message to 127.0.0.1 port 26.

Wietse

[James B. Byrne]

On Tue, May 6, 2014 10:53, Wietse Venema wrote:
> James B. Byrne:
>> >> This is my MSA configuration in Master.cf
>> >>
>> >> submission inet n - n - - smtpd -v
> [...]
>
> Wietse:
> [have you ever used this with mailman before?]
>
> James B. Byrne:
>> I never tried before this incident and that attempt failed as I previously
>> reported. I am not attempting to sign mailman messages at the moment. I am
>> just trying to get the submission port to work.
>
> Well maybe we should leave port 587 for MUA clients only, and set
> up a mailman submission service that does not require TLS or SASL.
>

I should clarify my earlier remarks. I have successfully used the submission
service for external MUAs. I just have not been able to configure it properly
to accept internal mail from hosts. And I believe that was due to the
encryption requirement. Which requirement I was unwilling to disable given my
current state of knowledge.

I will set up the localhost service as you suggest and report back. At the
moment I am still trying to get mailman-2.1.18 to build under CentOS-6.

[James B. Byrne]

On Tue, May 6, 2014 10:53, Wietse Venema wrote:

>

> master.cf:
> 127.0.0.1:26 inet n - n - - smtpd
> -o smtpd_tls_security_level=none
> -o smtpd_sasl_auth_enable=no
> -o smtpd_client_restrictions=
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o smtpd_data_restrictions=
> -o milter_macro_daemon_name=ORIGINATING
> -o syslog_name=postfix-p26
>
> With this in place, do "postfix reload" and see if mailman can
> send a test message to 127.0.0.1 port 26.
>
> Wietse
>

This change, together with setting SMTPPORT=26 in mm_cfg.py solved the problem
of getting outgoing Mailman messages dkim signed. Unfortunately, as others
warned, this accomplishment solves nothing with respect to DMARC since the
Sender is not considered in the DKIM alignment wrt DMARC validity; only the
FROM header is.

I infer from my readings on the background to this that the salient point
respecting this curious choice appears to have been that the FROM header is
'seen' by the mail recipient but that the 'SENDER' is not. If so then I am
not sure that I see the merit in confining DKIM alignment to the FROM header
when there are many legitimate reasons why the sender should differ. In
addition to the ubiquitous and rather obvious mailing list issues that we are
confronted with the matter of public webmail services come to mind.

However that may be, it seems that we are constrained to wait on Redhat to
provide an updated mailman to deal with this. My attempts to repackage 2.1.18
as an rpm succeeded insofar as I can install a working version into RHEL6 via
yum. The difficulty being that the mailman project is not FHS aligned and in
consequence either SELinux has to be disabled or a massive amount of patching
and relocating of files made to the original source files. The resources that
the latter approach requires are beyond our slender capacity (me) to provide
and switching off SELinux on a host providing a public facing web portal is
not going to happen here.

Thank you for the help. It is greatly appreciated.

[Erik Brakkee]

Op dinsdag 6 mei 2014 om 16:53:31 UTC+2 schreef Wietse Venema:

> -o milter_macro_daemon_name=ORIGINATING
> Wietse

More than 8 years ago after this post it solved my problem. I ran into the same issue with mailman outgoing mails not getting a DKIM signature. Then I saw this, and digging a little deeper, the above milter setting is also defined for the submission protocol (587) by default in my installation (docker-mailserver). Then simply using the submission protocol from mailman 3 with an authenticated user solved the problem without requiring any other configuration changes.

[Ed Lok]

hey please i want use some thing like message-id in my source how i can ?

[David White]

And after almost *another* full year, this too has solved my problem of trying to make Postfix+amavisd-new+Mailman 2 play nicely together. Creating separate ports with separate configurations for amavisd-new (10025) and mailman (10027) to route their messages back to Postfix, plus adding "-o milter_macro_daemon_name=ORIGINATING" now allows my Mailman message to be DKIM signed. Thanks to James B. Byrne for working through the issue, Wietse with a solution, and Erik for highlighting the critical piece in this long thread that I needed.

[Jerry Lee Daniel]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7405 896213
Email: danielj...@mail.com