On the commit message, the convention is that all titles end with a
period, also all statements in the subtext also end with a period, and
that the subtext is wrapped to 80 columns (unless links). Look at other
commit messages for examples.

Should be fixed in the attached patch.
 
It seems in your latest patches applied on top of master, the
'sendmail' package does not build.

This too.
 
I noticed it builds as a static library:

/gnu/store/vdg98ynngj637sdn1xazgafb8af8fv2j-libmilter-
1.0.1/lib/libmilter.so.: ELF 64-bit LSB shared object, x86-64, version
1 (SYSV), statically linked, not stripped

Is there any build flag to disable that? If so, I think we probably
should, for security updates of it's dependencies, but it doesnt look
like it has any, not even the glibc? Maybe it's not so important here.

I thought the patch I pulled in from Debian made it into a shared library. It brought it from a .a that pymilter would not build against to a .so that it would build against. This is the first time I build C libraries for distribution so I have no idea what I'm doing.

I seem to have misplaced my package definition for pymilter when I rebased on master so I have to confirm again that this libmilter is actually usable. There was something about the pymilter tests not running IIRC.
 
I also noticed that there was a weird naming for the actual so file, it
ends with a dot '.':

I think something somewhere in the build system wants to add a number after that dot, but that there was no number available so it just added an empty string after the dot.

$ tree $(./pre-inst-env guix build libmilter)
/gnu/store/vdg98ynngj637sdn1xazgafb8af8fv2j-libmilter-1.0.1
├── include
│   └── libmilter
│       ├── mfapi.h
│       └── mfdef.h
├── lib
│   ├── libmilter.a
│   ├── libmilter.so -> libmilter.so. <<-- here
│   └── libmilter.so. <<-- also here
└── share
    └── doc
        └── libmilter-1.0.1
            └── LICENSE

6 directories, 6 files

Again it will work anyways I believe, not crucial.

> +(define-public libmilter
> +  (package
> +    (inherit sendmail)
> +    (name "libmilter")
> +    (version "1.0.1")

Where does this version come from?

I think I just took it from Debian for some reason: https://packages.debian.org/experimental/libmilter1.0.1
 
Are you sure about that?

Hard no on that.
 
Also do
note that changing the version field here in libmilter does not change
the version used in the origin of the inherited package So it's using
the same sources as sendmail exactly, that's what you want?

Yeah, that is what I intended. I intended to only change the metadata attached to the libmilter package in the Guix package repository.

 
> +    (arguments
> +     (substitute-keyword-arguments (package-arguments sendmail)
> +       ((#:phases phases)
> +        `(modify-phases ,phases
> +           (replace 'build
> +             (lambda* _
> +               (with-directory-excursion "libmilter"
> +                 (invoke "sh" "Build"))
> +               #t))
> +           (delete 'pre-install)
> +           (replace 'install
> +             (lambda* _
> +               (with-directory-excursion "libmilter"
> +                 (mkdir-p (string-append (assoc-ref %outputs "out")
> "/lib"))
> +                 (invoke "make" "install"))
> +               #t))))))
> +    (synopsis "Sendmail library for creating mail filters.")))
> +

I suggest adding a dedicated synopsis and description here, also
synopsises as I see it should not be sentences and not end with a
period, descriptions on the other hand should be full sentences, look
at the other packages for inspiration.

Added a description and removed the period from the synopsis.

I will keep the website as sendmail.org despite the redirect, the patch will not start with the filename for libmilter. I do not know what to do about there being no "updater" for sendmail, but then again the last release was in 2016.