Mailing List Archive: opendkim et al.

opendkim et al.

Aug 20, 2021, 3:47 AM

Post #1 of 7 (1158 views)

Hi Manvendra,

just had a brief look about opendkim (as you suggested).

Opendkim is a beast. Just opendkim.c is about 350 KByte / 16 k lines size
(in comparison: all s/qmail is about 650 KByte size of C code). Opendkim is
very much sendmail'ish.

I also check the Milter web site. Sigh again. Is gone; API not well defined
(though some sources exist still). Requires Unix sockets; commands are give
by sendmail macros ...

I will have a look a Kai Peter's solution first.

Interesting to read Postfix' comments on Milter:

"The reason for adding Milter support to Postfix is that there exists a
large collection of applications, not only to block unwanted mail, but also
to verify authenticity (examples: OpenDKIM and DMARC ) or to digitally sign
mail (example: OpenDKIM). Having yet another Postfix-specific version of all
that software is a poor use of human and system resources."

http://www.postfix.org/MILTER_README.html

Given that statement, we all should migrate to Exchange!

Regards.
--eh.

On Fri, 13 Aug 2021 13:20:42 +0530, Manvendra Bhangui <mbhangui@gmail.com>
wrote :

> On Fri, 13 Aug 2021 at 12:32, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> > Regarding your libdkim, I will have a look. I was already shocked about
the
> > bad quality of libsrs and I assumed that libdkim is not much better.
Thats
> > why I has hesitating to go for it without a good alternative. Sigh.
> >
>
> you could check the opendkim project. http://www.opendkim.org/. I'm
> going to take a look at it some day and if possible replace libdkim
> with that.
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Re: milter API [ In reply to ]

qmail at esmtp

Aug 20, 2021, 4:02 AM

Post #2 of 7 (1158 views)

Permalink

On Fri, Aug 20, 2021, Erwin Hoffmann wrote:

> I also check the Milter web site. Sigh again. Is gone; API not well defined

The milter API definition is part of the sendmail distribution.
If something is "not well defined" you can contribute your enhancements
or report bugs via the sendmail support addresses.

> (though some sources exist still). Requires Unix sockets; commands are give

TCP sockets work fine too.

--
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.

Re: milter API [ In reply to ]

feh at fehcom

Aug 20, 2021, 5:43 AM

Post #3 of 7 (1158 views)

Permalink

Hi Clause,

On Fri, 20 Aug 2021 13:02:32 +0200, Claus Assmann <qmail@esmtp.org> wrote :

> On Fri, Aug 20, 2021, Erwin Hoffmann wrote:
>
> > I also check the Milter web site. Sigh again. Is gone; API not well
defined
>
> The milter API definition is part of the sendmail distribution.
> If something is "not well defined" you can contribute your enhancements
> or report bugs via the sendmail support addresses.

sure. I used sendmail back in the 1990's, tried a look at smail, and ended
up with qmail++.

Allman's sendmail is now hosted by 'proofpoint' and documentation is
embedded. 'www.milter.org' is archived and relevant documents not accessible
any more (same with qmail.org).

>
> > (though some sources exist still). Requires Unix sockets; commands are
give
>
> TCP sockets work fine too.

Having a look at milter (and Opendkim): Seems to be to exaggerated for the
particular case. Rather stay with the Unix principle: Keep things small and
single purpose (mostly).

For DKIM, Manvendra's implementation seems to be a good choice. Let's see,
how to port it to DJB's standards and my fehQlibs.

Thanks for the hint.
Regards.
--eh.

>
> --
> Address is valid for this mailing list only, please do not reply
> to it direcly, but to the list.
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Re: opendkim et al. [ In reply to ]

mbhangui at gmail

Aug 20, 2021, 7:21 AM

Post #4 of 7 (1158 views)

Permalink

On Fri, 20 Aug 2021 at 16:17, Erwin Hoffmann <feh@fehcom.de> wrote:

> just had a brief look about opendkim (as you suggested).
>
> Opendkim is a beast. Just opendkim.c is about 350 KByte / 16 k lines size
> (in comparison: all s/qmail is about 650 KByte size of C code). Opendkim is
> very much sendmail'ish.
>

So we are back to libdkim. Since you are good with sockets and dns, If
you are going to use libdkim, then replace dns.cpp with your own.
dns.cpp was the one that gave me a lot of problems. The original code
from ALT-N didn't handle long TXT records. Ultimately I replaced it
with code from qmail's dns.c. No new issues have been reported by
users of my qmail-dkim. Once you make your modifications for dns, etc,
I too will use your code.

Re: opendkim et al. [ In reply to ]

johnl at iecc

Aug 20, 2021, 8:01 PM

Post #5 of 7 (1157 views)

Permalink

It appears that Erwin Hoffmann <feh@fehcom.de> said:
>Hi Manvendra,
>
>just had a brief look about opendkim (as you suggested).
>
>Opendkim is a beast. Just opendkim.c is about 350 KByte / 16 k lines size
>(in comparison: all s/qmail is about 650 KByte size of C code). Opendkim is
>very much sendmail'ish. ...

This is one of the reasons I dumped qmail-smtpd in favor of mailfront. It has
a nice plugin architecture and it is easy to write the plugins. I wrote one that
checks SPF, DKIM, and DMARC on an incoming message, adds an Authentication-Results
header, stores the results in a database for later analysis (not written yet) and
has some options to do things to the mail if the checks fail.

The shared libraries it calls may be large, but the interfaces are clean and the performance
is good.

R's,
John

Re: opendkim et al. [ In reply to ]

feh at fehcom

Aug 21, 2021, 12:51 AM

Post #6 of 7 (1157 views)

Permalink

Good Morning John,

On 20 Aug 2021 23:01:20 -0400, "John Levine" <johnl@iecc.com> wrote :

> It appears that Erwin Hoffmann <feh@fehcom.de> said:
> >Hi Manvendra,
> >
> >just had a brief look about opendkim (as you suggested).
> >
> >Opendkim is a beast. Just opendkim.c is about 350 KByte / 16 k lines size
> >(in comparison: all s/qmail is about 650 KByte size of C code). Opendkim
is
> >very much sendmail'ish. ...

qmail-smtpd -> mailfront (I don't have experience with).

>
> This is one of the reasons I dumped qmail-smtpd in favor of mailfront. It
has
> a nice plugin architecture and it is easy to write the plugins. I wrote
one that
> checks SPF, DKIM, and DMARC on an incoming message, adds an
Authentication-Results
> header, stores the results in a database for later analysis (not written
yet) and
> has some options to do things to the mail if the checks fail.
>
> The shared libraries it calls may be large, but the interfaces are clean
and the performance
> is good.

Verification of a DKIM signature is one side of the coin. Actually, given
qmail-queue EXTRA it is pretty easy to integrate that into qmail-smtpd. For
the 'production' pipeline of s/qmail's external mail receipt, you may want
to look at the picture given here:

https://www.fehcom.de/sqmail/sqmaildoc_07.html

Apart from DKIM, it lacks almost nothing (at least from my point of view).

However, there are two main things to consider:

1. Cryptographic routines. Ok, OpenSSL/LibreSSL may be used here.
2. Signing of outgoing messages. Here s/qmail's qmail-remote works 'multi-
tenant' and I would certainly like to keep it that way.

In short: Defining a qualified, performing, and easy-to-use DKIM plugin (on
both sides) is certainly not a snap. To provide an API for qmail-remote a
bit challenging.

Let me come back to the discussion here when the work is done.

Regards.
--eh.

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Re: opendkim et al. [ In reply to ]

johnl at iecc

Aug 21, 2021, 7:47 AM

Post #7 of 7 (1157 views)

Permalink

It appears that Erwin Hoffmann <feh@fehcom.de> said:
>Verification of a DKIM signature is one side of the coin. Actually, given
>qmail-queue EXTRA it is pretty easy to integrate that into qmail-smtpd. For
>the 'production' pipeline of s/qmail's external mail receipt, you may want
>to look at the picture given here:
>
> https://www.fehcom.de/sqmail/sqmaildoc_07.html
>
>Apart from DKIM, it lacks almost nothing (at least from my point of view).

Mailfront can do a lot more than that. It has its own STARTTLS support and
rules that let you set per sender rejection messages, EAI support I added just
to see how hard it was (not very, but not useful without matching support in
qmail-send and qmail-remote) and a lot of other stuff. I have a plugin to
do greylisting similar to postgrey, experimental ARC support and so forth.

>2. Signing of outgoing messages. Here s/qmail's qmail-remote works 'multi-
>tenant' and I would certainly like to keep it that way.

I sign the messages when they're injected and I know more about what is sending
the mail, e.g., local inject, mailing list, authenticated submission. I have
shims in front of qmail-queue using the QMAILQUEUE environment variable.

R's,
John