Mailing List Archive

s/qmail 4.2 (with DKIM support) released
Dear Qmail users,

after a long development and testing period, I'm glad to announce the
public availability of s/qmail 4.2 coming with full featured DKIM
support.

s/qmail is now mostly 'feature-complete' at least concering the current
situation for (E)SMTP and incorporates all main features an up-to-date
MTA shall have.

I've refactored and incorporated ALT-N's libdkim C++ library functions
natively for s/qmail, removed obsolete pieces and included Ed25519 DKIM
signature support. This adds about 4000 lines of code to s/qmail, which
is a considerable enhancement. In particular, the queue is now entitled
to include a subdirectory structure queue/dkim/<n>.

My changes to libdkim are such, that those can be picked up for
upstream integration. Though I introduced significant code changes, it
should be easy to get a reasonable working diff of if. However, with
exception for the DNS lookup (now based on fehQlibs).

The bad part of DKIM is its significant system impact: The mail has to
be rewritten several times, which however can not be avoided, since
DKIM calculates the hash over the message requiring CRLF line feeds.

The good point of my implementation is: In case you don't need DKIM, no
DKIM modules are called. Apart from a trivial change to qmail-rspawn,
no changes where done to the core. However, the stub-routines qmail-
dksign and qmail-dkverify are deeply integrated into s/qmail.

DKIM support helps to deliver mails in particular to the big
providers like gmail and Microsoft. Early adoptors really need to read
the documentation about my DKIM solution available at:

        https://www.fehcom.de/sqmail/sqmaildoc_05.html##qmail-DKIM

and the man pages!

DKIM key generation is a snap with the script mkdkimkey for both RSA
and Ed25519 keys and a subsequent DNS TXT record is available for easy
usage. I should mention, that my djbdnscurve6 already supports DKIM
records out-of-the-box.

s/qmail+DKIM works with both OpenSSL and LibreSSL in their advanced
versions. DKIM is no fastfood. It requires a lot of attention to setup
keys and signing strategies. I've tried to keep it in the spirit of
qmail. For signing, a new control file is available as 'dkimdomains'.

The stand-alone module 'qmail-dkim' can be used independently of
s/qmail and is simply a replacement for libdkim.

Special thanks to John Levine for his guidance on Ed25519 signatures.

The code is documented via doxygen:

https://www.fehcom.de/sqmail/doxygen/index.html


Regards.
--eh.
 


--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
On Mon, 23 Jan 2023 at 01:43, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> Dear Qmail users,
>
> after a long development and testing period, I'm glad to announce the
> public availability of s/qmail 4.2 coming with full featured DKIM
> support.

Congratulations on the 4.2 release.

> My changes to libdkim are such, that those can be picked up for
> upstream integration. Though I introduced significant code changes, it
> should be easy to get a reasonable working diff of if. However, with
> exception for the DNS lookup (now based on fehQlibs).
>
> The bad part of DKIM is its significant system impact: The mail has to
> be rewritten several times, which however can not be avoided, since
> DKIM calculates the hash over the message requiring CRLF line feeds.
>
> The good point of my implementation is: In case you don't need DKIM, no
> DKIM modules are called. Apart from a trivial change to qmail-rspawn,
> no changes where done to the core. However, the stub-routines qmail-
> dksign and qmail-dkverify are deeply integrated into s/qmail.

I have had a similar experience. qmail-rspawn, qmail-lspawn
modification, dkimdomains control file. The first thing that I had to
do was to replace the dns text function. The original code used to
truncate long text records. Two other things that come to my mind that
I had to change were the following

1. in dkimverify.cpp - On 32 bit systems my users were getting
signature expired errors. This was due to time_t being just 4 bytes. I
had to use long long variable on 32 bit systems for the variable
SignedTime.

2. dkimsign.cpp used to fail spectacularly for email addresses
generated by cron which used round braces to enclose email address
instead of angular braces. Cron no longer does that, so one should be
safe for now. But something was wrong with parsing of the sender email
address

I too am using the ALT-N library, but the thing I don't like is that
it is C++ and not in djb style. In future I may look at the opendkim
project.

> DKIM key generation is a snap with the script mkdkimkey for both RSA
> and Ed25519 keys and a subsequent DNS TXT record is available for easy
> usage. I should mention, that my djbdnscurve6 already supports DKIM
> records out-of-the-box.
>

Kudos for doing that.

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
Hi Manvandra,

I'am ashamed; I did not look into your code.

Am Montag, dem 23.01.2023 um 17:40 +0530 schrieb Manvendra Bhangui:
> On Mon, 23 Jan 2023 at 01:43, Erwin Hoffmann <feh@fehcom.de> wrote:
> >
> > Dear Qmail users,
> >
> > after a long development and testing period, I'm glad to announce
> > the
> > public availability of s/qmail 4.2 coming with full featured DKIM
> > support.
>
> Congratulations on the 4.2 release.
>
> > My changes to libdkim are such, that those can be picked up for
> > upstream integration. Though I introduced significant code changes,
> > it
> > should be easy to get a reasonable working diff of if. However,
> > with
> > exception for the DNS lookup (now based on fehQlibs).
> >
> > The bad part of DKIM is its significant system impact: The mail has
> > to
> > be rewritten several times, which however can not be avoided, since
> > DKIM calculates the hash over the message requiring CRLF line
> > feeds.
> >
> > The good point of my implementation is: In case you don't need
> > DKIM, no
> > DKIM modules are called. Apart from a trivial change to qmail-
> > rspawn,
> > no changes where done to the core. However, the stub-routines
> > qmail-
> > dksign and qmail-dkverify are deeply integrated into s/qmail.
>


> I have had a similar experience. qmail-rspawn, qmail-lspawn
> modification, dkimdomains control file. The first thing that I had to
> do was to replace the dns text function. The original code used to
> truncate long text records. 

Replacing libdkim's DNS function with fehQlibs one (for dkimverify.cpp)
was easy. But of course: This only worked out after fixing djb's dns
code for TXT records taken the label structure into consideration :-)


> Two other things that come to my mind that
> I had to change were the following
>
> 1. in dkimverify.cpp - On 32 bit systems my users were getting
> signature expired errors. This was due to time_t being just 4 bytes.
> I
> had to use long long variable on 32 bit systems for the variable
> SignedTime.
>
> 2. dkimsign.cpp used to fail spectacularly for email addresses
> generated by cron which used round braces to enclose email address
> instead of angular braces. Cron no longer does that, so one should be
> safe for now. But something was wrong with parsing of the sender
> email
> address

Thanks for the hints; I shall consider those for the forthcoming
releases. But this didn't happen to me.

>
> I too am using the ALT-N library, but the thing I don't like is that
> it is C++ and not in djb style. In future I may look at the opendkim
> project.

Uff. Did that too. 'dkim.c' includes > 9000 LoC; not my game. The
libdkim code is well written; but vastly overengineered.

It would be great, if someone picks up the idea of libdkim and tailors
a minimal C implementation out of it. This should not be too difficult.
However, my intention was not only to use that code but to enhance it
and to give it back to the public for further usage.

>
> > DKIM key generation is a snap with the script mkdkimkey for both
> > RSA
> > and Ed25519 keys and a subsequent DNS TXT record is available for
> > easy
> > usage. I should mention, that my djbdnscurve6 already supports DKIM
> > records out-of-the-box.
> >
>
> Kudos for doing that.

Still some things to do: RSA and Ed25519 signatures shall be used in
parallel. This required changes to dkimsign.cpp and the way private
keys are used here.


Regards.
--eh.



--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
Hi Hiro,

Am Montag, dem 23.01.2023 um 17:59 +0100 schrieb hiro:
> > DKIM support helps to deliver mails in particular to the big
> > providers like gmail and Microsoft.
>
> I have mostly seen the opposite.

any evidence for this statement?

The problem I saw only, was re-signing Gmail mails while forwarding
them, since they use a strict policy.

Im my solution, this problem can be avoided entirely without headaches.

Please, explain your observation in more detail.

Regards.
--eh.


--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
On Mon, 23 Jan 2023 at 01:43, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> 've refactored and incorporated ALT-N's libdkim C++ library functions
> natively for s/qmail, removed obsolete pieces and included Ed25519 DKIM
> signature support.


Hi Erwin,
I took a look at your code and John's RFC 8463. I have been able to
add the Ed25519-SHA256 algorithm thanks to the work done by you.
However implementation of ed25519 proves to be a challenge. I'm not
sure how many of the big players have implemented RFC8463. This means
that we will have to sign emails with a minimum two signatures.
Quoting two relevant points from the RFC

1. "Signers SHOULD implement and verifiers MUST implement the
Ed25519-SHA256 algorithm."
2. "For backward compatibility, signers can add multiple signatures
that use old and new signing algorithms"

Since there can only be a single key record in the DNS for each
selector, the signatures have to use different selectors. This point
alone creates a challenge. Most solutions will have to call the dkim
signer twice to generate a signature once for RSA-SHA256 and once for
Ed25519 and the bh calculation will happen twice. To avoid that I'm
thinking of modifying my qmail-dkim to allow one to pass multiple
selectors/private key files.

Just putting these thoughts here so that in case there is a better way
to handle this we could discuss that.
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
It appears that Manvendra Bhangui <mbhangui@gmail.com> said:
>I took a look at your code and John's RFC 8463. I have been able to
>add the Ed25519-SHA256 algorithm thanks to the work done by you.
>However implementation of ed25519 proves to be a challenge. I'm not
>sure how many of the big players have implemented RFC8463.

As far as I know, none. The only other implementation I know is in
the python DKIM library.

RSA signatures with 2K bit keys are likely to be adquate for a long time,
particularly since DKIM signatures are intended to be secure for weeks
or months, not years. So ed25519 is likely to remain the just-in-case
backup.

Also keep in mind that if there are breakthroughs in quantum computing,
they will break ed25519 just as badly as RSA so we'll likely add one
of NIST's post-quantum methods once they decide what those methods are.

R's,
John
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
Hi John,

Am Mittwoch, dem 25.01.2023 um 14:04 -0500 schrieb John Levine:
> It appears that Manvendra Bhangui  <mbhangui@gmail.com> said:
> > I took a look at your code and John's RFC 8463. I have been able to
> > add the Ed25519-SHA256 algorithm thanks to the work done by you.
> > However implementation of ed25519 proves to be a challenge. I'm not
> > sure how many of the big players have implemented RFC8463.
>
> As far as I know, none.  The only other implementation I know is in
> the python DKIM library.

which means, your RFC is based on this implementation only, and neither
OpenDKIM nor libdkim (of course not) provides Ed25519 signatures?

>
> RSA signatures with 2K bit keys are likely to be adquate for a long
> time,
> particularly since DKIM signatures are intended to be secure for
> weeks
> or months, not years. 

Well, the wording 'secure' is a bit misleading. We are talking about
signatures here. 'Secure' in this context means: It is unlikely that
somebody is able to forge a public/private key-pair whithin the given
validity period of the signature to fake it.

This DKIM signature is worthless after its expiration, though email
clients like Thunderbird have plugins try to do this ....

> So ed25519 is likely to remain the just-in-case
> backup.

Which saves, however, some computer cycles and by the very same token:
energy. Having included DKIM for (s/)qmail on an elementary level, I
need to say it is a very inefficient implementation given the goals:
integrity and authenticity.

> Also keep in mind that if there are breakthroughs in quantum
> computing,
> they will break ed25519 just as badly as RSA so we'll likely add one
> of NIST's post-quantum methods once they decide what those methods
> are.

Is this really relevant here? The same problem occurs with DNSSec too,
where signatures last as long as the ZSK.

Recently, I did a survey of TLSA deployment, since s/qmail also
supports this (and not DANE natively without a validating server). It
seems, admins don't like to do a key-rollover often. This is actually
the basic threat in spite of quantum computers, IMHO.

Regards.
--eh.

PS: And thanks again for your help.

PPS: qmail-dkim supports RSA key sizes up to 4k.



> R's,
> John

--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
It appears that Erwin Hoffmann <feh@fehcom.de> said:
>-=-=-=-=-=-
>
>Hi John,
>
>Am Mittwoch, dem 25.01.2023 um 14:04 -0500 schrieb John Levine:
>> It appears that Manvendra Bhangui  <mbhangui@gmail.com> said:
>> > I took a look at your code and John's RFC 8463. I have been able to
>> > add the Ed25519-SHA256 algorithm thanks to the work done by you.
>> > However implementation of ed25519 proves to be a challenge. I'm not
>> > sure how many of the big players have implemented RFC8463.
>>
>> As far as I know, none.  The only other implementation I know is in
>> the python DKIM library.
>
>which means, your RFC is based on this implementation only, and neither
>OpenDKIM nor libdkim (of course not) provides Ed25519 signatures?

No, Scott wrote the code and I wrote the RFC at roughly the same time.
The code was largely to check that there weren't mistakes in the spec,
which was just as well since we found and fixed a few.

R's,
John
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
Hi Hiro,

Am Donnerstag, dem 26.01.2023 um 22:06 +0100 schrieb hiro:
> > any evidence for this statement?
>
> no
>
> > The problem I saw only, was re-signing Gmail mails while forwarding
> > them, since they use a strict policy.
>
> huh, the gmail dmarc policy is p=none, i must be misunderstanding
> you?

since I use Gmail only occasionally (for some testing) I am not in a
position to really give a comprehensive statement on this. What I said,
reflects what my users told me.

>
> > Im my solution, this problem can be avoided entirely without
> > headaches.
>
> I beleive the sender wasn't in a position to profit from your
> implementation, yet.

There is one important point: Forwarding. In case you 'stack' DKIM
headers while forwarding, thus signing an email with your MTA's key
while the orginiator is not yours, things are going to get difficult.

In s/qmail, I use a multi-tenant implementation for signing. Apart
from signing ALL outgoing mails, you can chose (given the originator's
address) HOW to sign mails - if ever.

>
> > Please, explain your observation in more detail.
>
> i have no big sample size, so i'm not sure it's a valid complaint.
> that's why i had only contacted you privately, my original mail did
> not go to the list.
>
> i saw that when mail from a certain sender was signed with DKIM, it
> got classified as spam. Without DKIM there was no problem. In both
> cases there was valid SPF, and no DMARC policy at all.

This might coincide with the problem I outlined.

>
> the mailinglist is not touching anything apart from the Subject:,
> also
> not (re-)signing anything.
>
> My conclusion was that DKIM is a net negative benefit. Google seems
> to
> agree because they always set p=none in DMARC, which seems to
> instruct
> the receiver to ignoore the DKIM.

DMARC is out-of-scope in my solution.

But regarding your comment: 'DKIM is a negative benefit'; I certainly
would not contradict to this position.

>
> but i have never read the specs. just trying to share my practical
> experiences with this as a mailing list receiver who is being
> punished
> by using gmail.

I hope my solution is smart enough to avoid this. Took me some
sleepless nights and in particular bad Mondays.

Regards.
--eh.


--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
Op 26/01/2023 om 22:29 schreef Erwin Hoffmann:
> Hi Hiro,
>
> Am Donnerstag, dem 26.01.2023 um 22:06 +0100 schrieb hiro:
>>> any evidence for this statement?
>>
>> no
>>
>>> The problem I saw only, was re-signing Gmail mails while forwarding
>>> them, since they use a strict policy.
>>
>> huh, the gmail dmarc policy is p=none, i must be misunderstanding
>> you?
>
> since I use Gmail only occasionally (for some testing) I am not in a
> position to really give a comprehensive statement on this. What I said,
> reflects what my users told me.
>

In case of forwarding emails: Always use SRS.

http://www.fehcom.de/sqmail/man/srsforward.html


It will solve the problem you may have with SPF and DKIM.


Best regards,
Pascal
Re: SRS [ In reply to ]
Pascal Nobus <pascal@nobus.be> wrote:
>
> In case of forwarding emails: Always use SRS.

Except that it's not fully compatible with DMARC; it causes the SPF alignment
check to fail.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: SRS [ In reply to ]
Charles,

I know in the past Google read the "From: " in the header of the mail
with ARC, but it seems they changed their mind, cause I don't see it anymore




I have srs.pi-group.net in my control/srsdomain, and an SPF-record:
srs.pi-group.net. IN TXT
"v=spf1 ip4:94.126.48.0/24 a:smtp2.pi-group.net -all"


Forwarding to google by setting this in dot-qmail;
|srsforward <privacy_cut@gmail.com


Gives the following header in Gmail;

ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of <privacy_cut>@srs.pi-group.net
designates 94.126.48.8 as permitted sender)
smtp.mailfrom="<privacy_cut>@srs.pi-group.net"

Received-SPF: pass (google.com: domain of <privacy_cut>@srs.pi-group.net
designates 94.126.48.8 as permitted




P.S.

P.P.S. I only looked at SPF cause no DMARC was setup, but I don't expect
any problems there.





Op 27/01/2023 om 14:44 schreef Charles Cazabon:
> Pascal Nobus <pascal@nobus.be> wrote:
>>
>> In case of forwarding emails: Always use SRS.
>
> Except that it's not fully compatible with DMARC; it causes the SPF alignment
> check to fail.
>
> Charles
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
It appears that Pascal Nobus <pascal@nobus.be> said:
>>
>
>In case of forwarding emails: Always use SRS.

I wouldn't bother. It doesn't help.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
John,

Can you explain this?

When using SRS the mail is forwarded with the domain you control.
So SPF/DKIM works.

--
Pascal



Op 27/01/2023 om 18:40 schreef John Levine:
> It appears that Pascal Nobus <pascal@nobus.be> said:
>>>
>>
>> In case of forwarding emails: Always use SRS.
>
> I wouldn't bother. It doesn't help.
>
> R's,
> John
Re: s/qmail 4.2 (with DKIM support) released [ In reply to ]
> Can you explain this?
>
> When using SRS the mail is forwarded with the domain you control.
> So SPF/DKIM works.

SPF works, but it makes no difference to DKIM and doesn't help with DMARC
since the envelope and From: don't match.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly