Hi all.

Can someone point me in the direction of a [simple!] 'how to' to run
mailman3 alongside sendmail please? I'm using MM2, now deprecated, and
MM3 is significantly different.

It seems even the mailman people are asking for it, and they only offer
a guide for mailman2. Something about using LMTP rather than pipes, but
no details. https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.html


Thanks.


--
Mike Scott
Harlow, England

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/10/21 2:37 AM, Mike Scott wrote:

Hi all.

Hi,

Can someone point me in the direction of a [simple!] 'how to' to run
mailman3 alongside sendmail please?

Sorry, I don't have an answer to that.

I'm also not convinced that "MM3" and "simple" can go in the same
statement. My very limited exposure to MM3 documentation makes me think
that it is at least one order of magnitude more complicated than MM2.
And that it's likely too complicated for sites that want little more
than an expansion list.

I'm using MM2, now deprecated, and MM3 is significantly different.

Yep.

I've not made the transition from MM2 to MM3 yet. I'm more likely to go
from MM2 to something other than MM3 if / when it becomes a problem.

It seems even the mailman people are asking for it, and they only offer
a guide for mailman2. Something about using LMTP rather than pipes, but
no details.

Sendmail does have some form of LMTP support. cf/README maeks reference
tot he cyrusv2 mailer supporting LMTP. I suspect that there is a way to
co-opt this LMTP support into delivering to MM3.

I'd start by looking at the cyrusv2 mailer, copying it's definition (cf/mailer/cyrusv2.m4) to a new mm3 mailer and modifying it as necessary.

I would naively expect that it's possible to create the new MM3 (LMTP)
mailer and to configure Sendmail to route messages to MM. -- My
preference is to put all MM email in a sub-domain and ""relay through
Sendmail to MM via the mailer a la. mailertable.

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.html

I'm not sure exactly what the content of the /etc/mail/mailman.aliases
file would be. But I suspect that it's calling some program that reads
from STDIN and passes the message into MM3. I don't see anything else
plumbing between Sendmail and MM3, only something to deal with defining
aliases (mailing list addresses as recipients).



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/06/2021 18:09, Grant Taylor wrote:

On 6/10/21 2:37 AM, Mike Scott wrote:

Hi all.

Hi,

Can someone point me in the direction of a [simple!] 'how to' to run
mailman3 alongside sendmail please?

Sorry, I don't have an answer to that.

I'm also not convinced that "MM3" and "simple" can go in the same statement.  My very limited exposure to MM3 documentation makes me think that it is at least one order of magnitude more complicated than MM2.
And that it's likely too complicated for sites that want little more
than an expansion list.

I'm using MM2, now deprecated, and MM3 is significantly different.

Yep.

I've not made the transition from MM2 to MM3 yet.  I'm more likely to go from MM2 to something other than MM3 if / when it becomes a problem.

(snip)....

Thanks for the comments.

I'd settled on MM2 a couple of years back, after trying other mail list software. dkim totally screwed up my original 'just let sendmail handle
it' scheme.

MM2 has been adequate; but with python2 now being deprecated, its days
are numbered.

MM3 looks a nightmare; is there anything else you (or anyone) would
suggest that won't fall foul of dkim and friends?




--
Mike Scott
Harlow, England

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/10/21 1:34 PM, Mike Scott wrote:

Thanks for the comments.

You're welcome.

MM2 has been adequate; but with python2 now being deprecated, its days
are numbered.

Agreed.

MM3 looks a nightmare;

I completely agree.

is there anything else you (or anyone) would suggest that won't fall
foul of dkim and friends?

I don't have any plan at this time. I actually have minimal use for
mailing lists now (my needs have changed) and I'd like something that's
more integrated with the SMTP process. E.g. I want to be able to reject messages at SMTP time instead of accepting and then bouncing based on
who's allowed to post to a list or not. I don't know what that will be.

Once upon a time I had considered a milter to augment the interface
between Sendmail and Mailman. But, I don't think I want to go there
with MM because of aforementioned MM3 woes.

I may actually contemplate falling back to Sendmail expansion with
modification or create my own for the minimal remaining use case I may
still have when I do tilt at this windmill. I would also take as much
of a look at SnertSoft's current mailing list solution, EZMLM,
majordomo, and maybe a couple of others (LISTSERV?) to see if any of
them would be acceptable to me.

N.B. my definition of acceptable is quite different than most people.
So don't take my acceptable to be a good thing. Seeing as how I think
gluing together some Perl might be acceptable, my acceptable may
actually be a bad thing.

My wish list for a mailing list manager:
- Ability to do SMTP time filtering and rejection
- Full DSN support; MAIL FROM: ... RETURN, RCPT TO: ... ORCPT
- Fully compatible with contemporary email hygiene; SPF, DKIM, DMARC.
- This is actually easy to do by validating what comes in and
removing conflicts before going into the MLM and then add them anew as
messages leave the MLM.
- S/MIME and / or PGP support
- Reasonable UI / UX, CLI required, web desired.

I don't currently have anything that meets all of those requirements.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-06-10, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

Hi Mike.

[...]
MM3 looks a nightmare; is there anything else you (or anyone) would
suggest that won't fall foul of dkim and friends?

honestly I don't understand this suggested connection between a
mailinglist software and DKIM/DMARC. There's no functional dependency
between these two.
As there is no real problem to specify an LMTP mailer to push mails into
the MailMan system. You may either fiddle around with existing m4 mailer defintion files and build one with the LMTP flag ("z") instead of the
SMTP flags or you explicitly specify a mailer defintions in the
"LOCAL_CONFIG" area of your sendmail.mc. I already did this and its not
that complicated.
And you certainly need to tweak things like you mailer table or similar
tables depending on how your mailingslist is run (TM); Things like whether
you use a sperate mailinglist domain or run it with a "special" user
within your "default" domain.

What becomes indeed more interesting is whether you run the MailMan installation on a different machine than the mailserver(s). Then it should
be a good idea to take queue groups into account to not lose mailinglist
mails if the MailMan machine is down for some time.

Best regards,
Hnenning
--
Forecast, n:
A prediction of the future, based on the past, for
which the forecaster demands payment in the present.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/10/21 11:59 PM, Henning Hucke wrote:

honestly I don't understand this suggested connection between a
mailinglist software and DKIM/DMARC. There's no functional dependency
between these two.

There isn't on one level and there is on another level.

Mailing list software will quite happily handle email that is protected
by SPF / DKIM / DMARC. However, how they do it becomes extremely
important. SPF has implications on what envelope sender the mailing
list uses. DKIM / DMARC has implications on what the mailing list can
do with the message.

So, the connection comes from the fact that the mailing list effectively
needs to completely originate new messages without any of the protection
that the incoming message had so that the messages that are sent out
don't violate said protection. It's also a really good idea if the
mailing list adds comparable protection to the messages that it sends.

What becomes indeed more interesting is whether you run the MailMan installation on a different machine than the mailserver(s). Then it
should be a good idea to take queue groups into account to not lose mailinglist mails if the MailMan machine is down for some time.

I'm not aware of Mailman supporting direct incoming SMTP connections. I believe it /requires/ an MTA (external to Mailman) on the system to
receive inbound email and hand it to Mailman.

That being said, you can likely run Mailman and it's supporting MTA on a separate machine from the main email server. Do so with an SMTP
connection between the primary MTA and the MTA on the Mailman server.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-06-11, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

Hi Grant,

On 6/10/21 11:59 PM, Henning Hucke wrote:

honestly I don't understand this suggested connection between a
mailinglist software and DKIM/DMARC. There's no functional dependency
between these two.

There isn't on one level and there is on another level.

there is /no/ /functional/ _dependency_ between DKIM/DMARC and
mailinglists. There's nothing which needs the mailinglist to know of DKIM/DMARC. There's trust in mails sent from a system where DKIM/DMARC
and SPF play a role and certainly you've got to set DNS informations
depending on envelope senders you use to send the mailinglist mails.

[...]

What becomes indeed more interesting is whether you run the MailMan
installation on a different machine than the mailserver(s). Then it
should be a good idea to take queue groups into account to not lose
mailinglist mails if the MailMan machine is down for some time.

I'm not aware of Mailman supporting direct incoming SMTP connections. I believe it /requires/ an MTA (external to Mailman) on the system to
receive inbound email and hand it to Mailman.

That being said, you can likely run Mailman and it's supporting MTA on a separate machine from the main email server. Do so with an SMTP
connection between the primary MTA and the MTA on the Mailman server.

What I mean is: if you run MailMan on a separate machine you certainly
can deliver the mails to the LMTP delivery agent (of MailMan). But one
of the purposes of LTMP is exactly this situation - no additional MTA,
just the LMTP local delivery agent. But if you run it on a seperate
system which could by down you need to queue the mails on the (MTA)
systems side in a queue which keeps mails long enough to deliver them
later to the LMTP delivery agent.

Regards,
Henning
--
Employees must wash hands before returning to work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/11/21 12:54 PM, Henning Hucke wrote:

Hi Grant,

Hi Henning,

there is /no/ /functional/ _dependency_ between DKIM/DMARC and
mailinglists.

I will concede that a mailing list can function in complete ignorance of
DKIM / DMARC, as in it can receive email and send it out to subscribers.

There's nothing which needs the mailinglist to know of
DKIM/DMARC.

However, I maintain that the mailing list /should/ be DKIM / DMARC aware
and alter it's behavior. This is *ESPECIALLY* true if the mailing list
is going to alter the contents of the message in any way. Lest the
email that comes out of the mailing list run afoul of contemporary email hygiene practices.

There's trust in mails sent from a system where DKIM/DMARC and SPF
play a role and certainly you've got to set DNS informations depending
on envelope senders you use to send the mailinglist mails.

DKIM signed messages passing through a mailing list is almost certainly predicated on the mailing list *NOT* modifying the message in any way.

I say almost certainly because it's possible that the DKIM signature can
be tuned to not include things that mailing lists commonly modify; from
and / or subject and / or body. Any and all modifications will
invalidate -- what I consider to be -- any worthwhile DKIM signature.

What I mean is: if you run MailMan on a separate machine you certainly
can deliver the mails to the LMTP delivery agent (of MailMan). But one
of the purposes of LTMP is exactly this situation - no additional MTA,
just the LMTP local delivery agent.

I think we have different understandings of the components involved.

[Sender]---(Internet)---[MTA]---[LDA]---[Mailman]

The sender (ultimately) uses SMTP to send the message across the
Internet to the inbound MTA. The MTA uses an LDA to deliver the message
to Mailman. The LDA can use STDIN/STDOUT as is traditional -or- the LDA
can use LMTP. But the overall process remains the same.

Even if you run Mailman on a different system than the main MTA, you
still need an MTA on the system running Mailman for it to receive
messages from the main MTA. If not, how are you going to get messages
between the two systems? Some sort of common queue directory (NFS or
clustered / replicated file system)?

But if you run it on a seperate system which could by down you need
to queue the mails on the (MTA) systems side in a queue which keeps
mails long enough to deliver them later to the LMTP delivery agent.

Yes, that's one of the fundamental functions of an MTA.

Please elaborate on how you're proposing to use LMTP to transfer
messages between systems? As far as I know, that's completely outside
of the scope of what LMTP does.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-06-11, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

Hi Grant,

[...]

I'm sorry to obviously haven't made myself enough toughts! Ashes on my
head.

I missed (overlooked) the obvious! :-(

At lease the "From:"-Header should get modified (Certain content enforced)
by a mailinglist software and this is indeed very likely a header which /should/ generally be included in the DKIM signed headers list.

But mailinglist software always should have filtered diverse headers out
of received mails before sending them out again to the mailinglist members.
And nowadays the DKIM headers of received mails should be part of the
set of these headers.
In this sense a mailinglist software should be kind of aware of DKIM
headers and similar things.
From this point on they don't need to be anymore.

... And - by the way - I'm not shure out of the box that all and every
DKIM header present in a mail gets checked/verified/processed - mind
envelope sender addresses in contrast to mail "From:" headers and thelike...

What I mean is: if you run MailMan on a separate machine you certainly
can deliver the mails to the LMTP delivery agent (of MailMan). But one
of the purposes of LTMP is exactly this situation - no additional MTA,
just the LMTP local delivery agent.

I think we have different understandings of the components involved.

[Sender]---(Internet)---[MTA]---[LDA]---[Mailman]

The sender (ultimately) uses SMTP to send the message across the
Internet to the inbound MTA. The MTA uses an LDA to deliver the message
to Mailman. The LDA can use STDIN/STDOUT as is traditional -or- the LDA
can use LMTP. But the overall process remains the same.

And here I'm still quite shure that your understanding is not complete (enough). Read at least the abstract of the RFC 2033. LMTP is not at all limited to get fed locally. A hint already is that you can bind LMTP DAs
to network addresses (See at least MailMan3 documentation).
Btw: You can speak LMTP to a DA even via STDIN/STDOUT.

Even if you run Mailman on a different system than the main MTA, you
still need an MTA on the system running Mailman for it to receive
messages from the main MTA. [...]

Wrong! See above.

[...]

Regards
Henning
--
Honesty is for the most part less profitable than dishonesty.
-- Plato

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/12/21 1:50 AM, Henning Hucke wrote:

Hi Grant,

Hi Henning,

At lease the "From:"-Header should get modified (Certain content
enforced) by a mailinglist software and this is indeed very likely
a header which /should/ generally be included in the DKIM signed
headers list.

Making a point to include (one or more) DKIM related headers in that
list falls under the broad category of "DKIM aware" to me. As in it
needs to know /something/ about DKIM and that it needs to do /something/ special / specifically for something DKIM related.

But mailinglist software always should have filtered diverse headers
out of received mails before sending them out again to the mailinglist members.

I agree.

But most mailing list managers that I've seen as an end user and the few
that I've administered have been mostly ignorant about DKIM (and other
things). The one exception that comes to mind is Mailman2 which has
some options specifically for DKIM (and DMARC), thus is "DKIM aware".

And nowadays the DKIM headers of received mails should be part of
the set of these headers.

Agreed. A la "DKIM aware".

In this sense a mailinglist software should be kind of aware of DKIM
headers and similar things.

;-)

From this point on they don't need to be anymore.

Being "DKIM aware" means knowing more than zero about DKIM. I'm not
saying how extensively aware something is about DKIM, just that it has /
does something specifically for DKIM. Even if that's just filtering an
DKIM related headers out of incoming message a la fgrep -v type thing.

... And - by the way - I'm not shure out of the box that all and
every DKIM header present in a mail gets checked/verified/processed -
mind envelope sender addresses in contrast to mail "From:" headers
and thelike...

My understanding is that one of the original DKIM headers indicates what headers are (over) signed and thus need to be validated. This is a
per-sender / sending domain supplied value.

And here I'm still quite shure that your understanding is not complete (enough). Read at least the abstract of the RFC 2033. LMTP is not at
all limited to get fed locally. A hint already is that you can bind
LMTP DAs to network addresses (See at least MailMan3 documentation).

Okay.... That's new information to me. At least RFC 2033 does not make
any implications about where LMTP can be used; local vs network. In
fact the only assertion that it makes is that it "MUST NOT be used on
TCP port 25".

Can ~> will you please point to any real world examples using LMTP on
the network? (As in I can download and start using.) -- I'm not aware
of any. However my ignorance does not preclude them from existing. --
I don't count something like (x)inetd / net cat et al. translating
between local processes and network sockets.

Btw: You can speak LMTP to a DA even via STDIN/STDOUT.

I've only ever seen LMTP used on a single machine, via STDIN / STDOUT or
maybe via unix: sockets.

Wrong! See above.

#TIL



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/21 12:18 PM, Unto Sten wrote:

The lmtpd that ships with Cyrus IMAP

Thank you for sharing an example Unto.

#TIL....



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> wrote:

Can ~> will you please point to any real world examples using LMTP on
the network? (As in I can download and start using.) -- I'm not aware
of any.

The lmtpd that ships with Cyrus IMAP is, in our case, bound to
TCP/1024 and has been accepting messages for over 14 years. This
originally happened in an organization that had over 50000 mailboxes
in Cyrus, but now those mailboxes have been migrated to MS Exchange
cloud and our Cyrus has only a few hundred bulletin boards left.

We have never had a single problem running lmtpd in this way.

best regards,
Unto Sten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-06-17, Unto Sten <sten.unto@gmail.com> wrote:

Hi Unto,

[...]
The lmtpd that ships with Cyrus IMAP is, in our case, bound to
TCP/1024 and has been accepting messages for over 14 years. This
originally happened in an organization that had over 50000 mailboxes
in Cyrus, but now those mailboxes have been migrated to MS Exchange
cloud and our Cyrus has only a few hundred bulletin boards left.

I suppose that it's a setup with a few - loadbalanced? - frontend MTA
machines delivering via lmtp to backend maildrop servers to which the
customers connect via - loadbalanced - IMAP servers which redirect to
the maildrop server on which the current user lives where necessary.

Compared to what microsoft exchange does in such a situation this is
still lightweight but genius.

We have never had a single problem running lmtpd in this way.

Yeah!

Best regards
Henning
--
Forecast, n:
A prediction of the future, based on the past, for
which the forecaster demands payment in the present.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)