PMG DKIM Signing....

[proxnoci]

Currently when quarantined mail is released (whitelist or accept it) then the mail is sent from postmaster@pmg.example.com
and if domain pmg.example.com SHOULD be signed, those forwarded mails are NOT DKIM signed.
Even as they are not anonymous...
Some mail providers are turning on the thumb screws on DKIM/DMARC....

 

[Mirco]

try this: copy main.cf.in from /var/lib/pmg/templates to /etc/pmg/templates and insert this line on the copied file: myorigin = $mydomain
restart services with pmgconfig sync --restart 1
with this modification, email is sent from postmaster@example.com
still without dkim, but in this mode at least spf record is satisfied.

 

[Stoiko Ivanov]

ry this: copy main.cf.in from /var/lib/pmg/templates to /etc/pmg/templates and insert this line on the copied file: myorigin = $mydomain
restart services with pmgconfig sync --restart 1
with this modification, email is sent from postmaster@example.com
still without dkim, but in this mode at least spf record is satisfied.

I would really not recommend this in general - rather add a SPF-record for your PMG's hostname (use the same as for your domain)
(SPF records are not checked from parent domains, but only for the name itself)

 

[Stoiko Ivanov]

Some mail providers are turning on the thumb screws on DKIM/DMARC....

Which providers - do you have any example logs?

and if domain pmg.example.com SHOULD be signed, those forwarded mails are NOT DKIM signed.

yes local mail from PMG are not signed - but with the changes from:
https://lists.proxmox.com/pipermail/pmg-devel/2024-February/002834.html
we're getting a bit closer to this.

However in general - I think specifically for quarantine mails and report - having an SPF record for your PMG-hostname should be enough to get the mails accepted by most well-known mail-providers.

 

[proxnoci]

This setting.... to the external used hostname.. (which matched DNS & reverse DNS lookup.
like in myhostname = XXXX.YYYY.ZZZZ
There is an spf record for XXXX.YYYY.ZZZZ as well as an DMARK & DKIM.

gmail is blocking a mail that was quarantined, but after verification is OK.

 

[w4rl0xX]

Hi there, we also had the same problem about Gmail.

However in general - I think specifically for quarantine mails and report - having an SPF record for your PMG-hostname should be enough to get the mails accepted by most well-known mail-providers.

Technically yes, but sadly no (in case of at least Google AND if you deliver >5k mails to them per day)...

because Google (and I think Yahoo also) updated their incoming mail policies... If you send more than 5000 mails per day to gmail, then SPF only does not meet the requirements anymore (see here: https://support.google.com/a/answer/81126?hl=en&sjid=8161776057917687779-EU#requirements-5k). We only figured it out the hard way because of logs

Therefore we implemented the DKIM sign feature of PMG, but for the spam quarantine mails or "get quarantine link" mails (basically any mails from the PMG system itself) will still fail, because of invalid SPF + DKIM:

Feb 29 18:04:49 XXSUPPRESSEDXX postfix/smtp[2391569]: A9ACE4CFE5: to=<XXSUPPRESSEDXX@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.184.26]:25, delay=0.57, delays=0.05/0/0.13/0.4, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[64.233.184.26] said: 550-5.7.26 This mail has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication results: 550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [] with ip: [X.X.X.X] = did not pass 550-5.7.26  550-5.7.26  For instructions on setting up authentication, go to 550 5.7.26  https://support.google.com/mail/answer/81126#authentication s8-20020a05600c45c800b004127939d145si1166680wmo.84 - gsmtp (in reply to end of DATA command))

Currently we have no solution for that really either because it seems that they don't use the Address of the From: header.

Best regards
~s.

 

[proxnoci]

SPF & DKIM already do exist for the server under it's own name as domain. I need to check DMARC..., that maybe is to restrictive for this domain.

I think i am way below 5000 / day for gmail, they still require DKIM.
Although i have fairly restrictive spam checking enabled, some stil get through so the reputation may work against me.

(on a side note: i guess spamassissin is not restrictive enough...., i used to use a home brew mail street based on rspamd, exim, dcc, greylisting etc.
and the spamassin was trained on a 20 years of spam learning..., that last part is lost now.)

About sending local originating mail... why not sending it through port 26...., then it matters a lot less.
SPF & DKIM already do exist for the server under it's own name as domain

 

[Stoiko Ivanov]

SPF [] with ip: [X.X.X.X] = did not pass 550-5.7.26

it seems SPF is not setup correctly

anyways - getting the mails from the PMG itself optionally signed is on our roadmap - https://bugzilla.proxmox.com/show_bug.cgi?id=4658
No promises when/if it will be available as usual.

 

[proxnoci]

(@Stoiko Ivanov : the SPF failure above was not from my systems...., i got those from NDR, those are from another member).
Nice to know it is on the roadmap...., in my experience if gmail and a few others start using something others will follow after they have to invest time to jump the extra hoops, they take the implementation for them selves also.

 

[sebix]

Is there a timeline for solving this issue?

Two related bug reports on that matter already exist:

1. https://bugzilla.proxmox.com/show_bug.cgi?id=4658 (DKIM sign NDRs)
2. https://bugzilla.proxmox.com/show_bug.cgi?id=2971 (DKIM signing d= tag should use the From domain (not the EnvelopFrom))

Various mail providers raised the bar for delivering e-mails to them, requiring DKIM. Not only gmail and yahoo, but also 1&1, including gmx). With PMG unable to sign all outgoing e-mails, we'd need to add another mail gateway just for DKIM, which we really would like to avoid.

 

[w4rl0xX]

Is there a timeline for solving this issue?

Two related bug reports on that matter already exist:

1. https://bugzilla.proxmox.com/show_bug.cgi?id=4658 (DKIM sign NDRs)
2. https://bugzilla.proxmox.com/show_bug.cgi?id=2971 (DKIM signing d= tag should use the From domain (not the EnvelopFrom))

Various mail providers raised the bar for delivering e-mails to them, requiring DKIM. Not only gmail and yahoo, but also 1&1, including gmx). With PMG unable to sign all outgoing e-mails, we'd need to add another mail gateway just for DKIM, which we really would like to avoid.

At least for the 2nd case, I guess. With update 8.1.2 I saw the feature that you now can choose* DKIM signing between "Envelope From" and "Header From":
Found under https://<pmghost>:8006/#pmgMailProxyConfiguration:dkim after updating

 

[sebix]

I already tried that option and there is no change.

 

[Stoiko Ivanov]

I already tried that option and there is no change.

then please share the logs - or describe what kind of mail is rejected by which provider for which reason.

Is there a timeline for solving this issue?

In general we cannot guarantee a ETA for a particular feature/change - getting mails sent by PMG directly signed is on our roadmap though

 

[sebix]

Dear Stoiko,

Thank you for your response.

then please share the logs or describe what kind of mail is rejected by which provider for which reason.

In which logs can I find information about DKIM signing? I wasn't able to find anything in /var/log.
These are the log lines for a normal outgoing mail delivery, not quarantined, with DKIM singing:

2024-03-22T21:46:55.767341+01:00 guardian postfix/smtpd[639093]: connect from internal.example.com[192.168.95.136]
2024-03-22T21:46:55.773170+01:00 guardian postfix/smtpd[639093]: Anonymous TLS connection established from internal.example.com[192.168.95.136]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
2024-03-22T21:46:55.774398+01:00 guardian postfix/smtpd[639093]: NOQUEUE: client=internal.example.com[192.168.95.136]
2024-03-22T21:46:55.775824+01:00 guardian pmg-smtp-filter[638472]: 2024/03/22-21:46:55 CONNECT TCP Peer: "[127.0.0.1]:46586" Local: "[127.0.0.1]:10023"
2024-03-22T21:46:55.823528+01:00 guardian pmg-smtp-filter[638472]: 12CD065FDEE3FC78B8: new mail message-id=<d86a59bd-e3d0-46f9-a312-f33f4c79091e@htu.at>#012
2024-03-22T21:46:56.476436+01:00 guardian pmg-smtp-filter[638472]: 12CD065FDEE3FC78B8: SA score=0/5 time=0.612 bayes=0.00 autolearn=ham autolearn_force=no hits=BAYES_00(-1.9),[custom rules]
2024-03-22T21:46:56.484398+01:00 guardian postfix/smtpd[639090]: connect from localhost[127.0.0.1]
2024-03-22T21:46:56.486233+01:00 guardian postfix/smtpd[639090]: 76AAE12D99: client=localhost[127.0.0.1], orig_client=internal.example.com[192.168.95.136]
2024-03-22T21:46:56.529097+01:00 guardian postfix/cleanup[639091]: 76AAE12D99: message-id=<d86a59bd-e3d0-46f9-a312-f33f4c79091e@htu.at>
2024-03-22T21:46:56.716468+01:00 guardian postfix/qmgr[638707]: 76AAE12D99: from=<swagner@htu.at>, size=2033, nrcpt=1 (queue active)
2024-03-22T21:46:56.716667+01:00 guardian postfix/smtpd[639090]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5
2024-03-22T21:46:56.716782+01:00 guardian pmg-smtp-filter[638472]: 12CD065FDEE3FC78B8: accept mail to <sebix@sebix.at> (76AAE12D99) (rule: default-accept)
2024-03-22T21:46:56.739582+01:00 guardian postfix/smtp[639092]: Trusted TLS connection established to mail.fizeau.net[93.189.28.12]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)
2024-03-22T21:46:57.096947+01:00 guardian pmg-smtp-filter[638472]: 12CD065FDEE3FC78B8: processing time: 0.9 seconds (0.612, 0.039, 0)
2024-03-22T21:46:57.097308+01:00 guardian postfix/smtpd[639093]: proxy-accept: END-OF-MESSAGE: 250 2.5.0 OK (12CD065FDEE3FC78B8); from=<swagner@htu.at> to=<sebix@sebix.at> proto=ESMTP helo=<htu.at>
2024-03-22T21:46:57.097387+01:00 guardian postfix/smtpd[639093]: disconnect from internal.example.com[192.168.95.136] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

And this is the delivery of an outoing email released from the quarantine:

2024-03-22T21:46:06.382107+01:00 guardian postfix/smtpd[639090]: connect from localhost[127.0.0.1]
2024-03-22T21:46:06.384624+01:00 guardian postfix/smtpd[639090]: 5DDA712CCF: client=localhost[127.0.0.1]
2024-03-22T21:46:06.429093+01:00 guardian postfix/cleanup[639091]: 5DDA712CCF: message-id=<923e77ef-3f7a-4a32-b665-e4f64ae8dad6@htu.at>
2024-03-22T21:46:06.442017+01:00 guardian postfix/qmgr[638707]: 5DDA712CCF: from=<postmaster@guardian.htu.tuwien.ac.at>, size=1401, nrcpt=1 (queue active)
2024-03-22T21:46:06.442800+01:00 guardian postfix/smtpd[639090]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 commands=4
2024-03-22T21:46:06.462794+01:00 guardian pmgdaemon[588872]: delivered quarantined mail 'C0R3177T99049164' (/var/spool/pmg/spam/7E/12CCC65FDEDFF5F97E)
::ffff:192.168.95.129 - swagner@pmg [22/03/2024:21:46:06 +0100] "POST /api2/extjs/quarantine/content/ HTTP/1.1" 200 25
::ffff:192.168.95.129 - swagner@pmg [22/03/2024:21:46:06 +0100] "GET /api2/htmlmail/quarantine/content?id=C0R3176T198685147 HTTP/1.1" 200 5355
::ffff:192.168.95.129 - swagner@pmg [22/03/2024:21:46:06 +0100] "GET /api2/json/quarantine/content?id=C0R3176T198685147 HTTP/1.1" 200 4653
::ffff:192.168.95.129 - swagner@pmg [22/03/2024:21:46:06 +0100] "GET /api2/json/quarantine/listattachments?id=C0R3176T198685147 HTTP/1.1" 200 99
2024-03-22T21:46:06.800461+01:00 guardian postfix/smtp[639092]: Trusted TLS connection established to mail.fizeau.net[93.189.28.12]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

In this example, the envelope from is postmaster@guardian.htu.tuwien.ac.at

The difference I see, is that the signed message passes pmg-smtp-filter. This is also mentioned in the bugzilla issues.

The PMG settings regarding DKIM:

/etc/pmg/pmg.conf:      dkim-use-domain header
/etc/pmg/pmg.conf:      dkim_selector guardian
/etc/pmg/pmg.conf:      dkim_sign 1
/etc/pmg/pmg.conf:      dkim_sign_all_mail 1

with htu.at as one of the DKIM signing domains.

This is an example reject message:

 <example@gmail.com>: host gmail-smtp-in.l.google.com[142.250.27.26] said:
550-5.7.26 This mail has been blocked because the sender is
unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with
either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [guardian.htu.tuwien.ac.at]
with ip: [128.131.95.58] = did not 550-5.7.26 pass 550-5.7.26 550-5.7.26
For instructions on setting up authentication, go to 550 5.7.26
https://support.google.com/mail/answer/81126#authentication
nb17-20020a1709071c9100b00a46ab990eb1si4210476ejc.609 - gsmtp (in reply to
end of DATA command)

In general we cannot guarantee a ETA for a particular feature/change - getting mails sent by PMG directly signed is on our roadmap though

It is good to here it is on the roadmap, I understand that there is no ETA.

 

[w4rl0xX]

From how I interpret your logs + settings you shared, here are my thoughts:

Besides the issue that NDRs or PMG system based mails (quarantine releases, spam reports, etc..) do not get signed, you should add an SPF record for the domain "guardian.htu.tuwien.ac.at" which includes the ip 128.131.95.58 as designated sender for this domain. Then at least the SPF check wouldn't fail, because Gmail is using Envelope-From address and therefore does a lookup for the SPF-TXT record for guardian.htu.tuwien.ac.at. But currently there seems to be none, so it fails. If you are lucky enough and your organization does not deliver >=5k e-mails/day to Gmail, then this could help to successfully deliver mails to Gmail again, due to SPF passing.

Greetings
~s.

 

[sebix]

you should add an SPF record for the domain "guardian.htu.tuwien.ac.at" which includes the ip 128.131.95.58 as designated sender for this domain. Then at least the SPF check wouldn't fail, because Gmail is using Envelope-From address and therefore does a lookup for the SPF-TXT record for guardian.htu.tuwien.ac.at.

We are aware of that and are working on it. However, it doesn't solve the missing DKIM signature.

 

[Stoiko Ivanov]

And this is the delivery of an outoing email released from the quarantine:

Ahh - I see - yes - quarantined mails that are released are not signed (I did not think about that, as those mails are delivered to the downstream server and in most deployments it makes sense to have the downstream server simply accept mails from PMG).

In which logs can I find information about DKIM signing? I wasn't able to find anything in /var/log.

In general logs can be found:
* in the journal (`journalctl`)
* in /var/log/syslog (and rotated variants) - this is where the tracking center takes it's information from
* other files written by syslog (e.g. mail.log)

DKIM signing itself only logs errors

I hope this helps!

 

[tkolb]

Dear All,
We face the same issue.

Ahh - I see - yes - quarantined mails that are released are not signed (I did not think about that, as those mails are delivered to the downstream server and in most deployments it makes sense to have the downstream server simply accept mails from PMG).

Downstream servers can also be external servers. I would be really great if these mails are also signed with a DKIM signature.

 

[admartinator]

Dear all,
i am just sitting in front of the same problem that PMG system based mails are not DKIM signed.
Does anyone has an update or has anyone found a solution?
Thanks and BR
Martin