Mailing List Archive

It appears that Ellenor Bjornsdottir <ellenor@umbrellix.net> said:
>Am I irretrievably out to lunch thinking that this is even a topic worth
>discussing?

I wouldn't say out to lunch, but I would say not worth the effort.

Technically, there is no reason you couldn't use SRV or more likeky
SVCB lookups to find a QMTP server. In practice, nobody uses QMTP
and nobody ever will because it doesn't do all the things that SMTP
does, and it's not enough faster to matter. In some ways it's
worse -- since it sends the message before the addresses, you
waste the message transmission if it rejects all the recipients.

If you do SMTP with pipelining, which everyone does, it is for
practical purposes as fast as QMTP even though it's a little more
verbose. SMTP has a fair number of optional services that people use,
most importantly SMTP AUTH but also SMTPUTF8 and to some degree DSN
and RRVS and BINARYMIME. You could retrofit those to QMTP, but it
still wouldn't be enough better than SMTP to matter.

You might also look at https://cr.yp.to/im2000.html
which was supposed to be next generation mail, replacing
the current push model by pull with notifications. It
could be interesting to speculate about why that never
went anywhere, but it never did.

R's,
John

Ellenor Bjornsdottir <ellenor@umbrellix.net> wrote:
>
> Three years to the month before I was born, a much sprightlier Professor
> Bernstein proposed a "mail exchanger protocol switch" which used very low
> priorities of MX to signify up to 16 relays that speak QMTP instead of, or
> in addition to, SMTP.

Use of MXPS never really took off. Some qmail admins enabled it, but I don't
it saw any kind of wide use.

> At the time, the SRV record existed in an early form. It strikes me as
> strange that use of the SRV record was not proposed, although IETF RFC 2052,
> written in 1996, contemplated exactly this with SMTP.

SRV at the time wasn't well supported. A lot of older DNS clients didn't deal
with it at all.

If MXPS were deployed today, SRV might make sense - but getting architectural
changes to internet email infrastructure deployed now is pretty much a
Sysiphean task.

> I plan on adding this to my own implementation of the -remote functionality
> in my currently-private fork of notqmail.

Note that you don't need to modify qmail-remote if you're only contemplating
QMTP delivery to a few hosts. I don't know if any of the big/public email
services support it at all.

The way it was normally done was to treat such a domain as a virtualdomain,
deliver all mail for that domain into a local maildir, and then periodically
run maildirqmtp to deliver everything that had accumulated over a single QMTP
session.

> I would like to hear arguments for, and against, this idea. I note that I
> know a party (won't say whether a person, a company, or other) who runs
> QMTPS on port 209 (the QMTP port).

I'm not arguing for or against; just saying that I don't think that QMTP
support is deployed widely enough to make handling it for arbitrary
destinations worthwhile.

> Am I irretrievably out to lunch thinking that this is even a topic worth
> discussing?

It's not a yes-or-no thing; almost anything is worth discussing in some
circumstances. I would say it's more like contemplating buying a forge and
anvil and making yourself a hunting knife. It's worthwhile if the goal is to
entertain yourself, spend time learning a skill, or just to prove to yourself
that you can do it.

For most people, it makes more sense to just go buy one / use what's
available. Sure, making a knife by hand probably (with experience and skill)
gets you a better knife, but is it *enough* better to justify the investment
of time and resources?

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
--------------------------------------------------------------------------

Hi Ellenor,


Am Montag, dem 26.09.2022 um 12:46 +0000 schrieb Ellenor Bjornsdottir:
>
> Nowadays, QMTP, QMTPS, and SMTP all have service names which would be
> suitable for use in an SRV record, like (using this mailing list
> host,
> in a fictional world where SRV was the norm, as an example):
> _smtp._tcp.list.cr.yp.to SRV 0 1 25 c.mx.cr.yp.to
>

could be; not no one does.


> I plan on adding this to my own implementation of the -remote
> functionality in my currently-private fork of notqmail. The code will
> be
> released in due time, and I've already broken ground (although it's
> not
> yet ready to test, it's just a mess of C header and boilerplate right
> now).
>
> I would like to hear arguments for, and against, this idea. I note
> that
> I know a party (won't say whether a person, a company, or other) who
> runs QMTPS on port 209 (the QMTP port).

Well, some years ago, I've asked the IETF to dedicate port 6209 for
QMTPS, which is supported in my s/qmail fork (providing X.509 client
cert authentication support):

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6209

For data centers working as an email hub, QMTP/QMPTS could still make
sense to provide peer services; but not on a large scale involving SRV
DNS records.

Unlike SMTP, QMTP is binary based protocol and respects CRLF, which
makes it inferior with todays DKIM.

@John Levine: Yeah, I've implemented RFC 8463 for s/qmail; coming soon.

Getting involved with notqmail is a good practicing place; but a lot of
the code originates back in the 90th of last century.

@Elleonor: To get some experiences with DNS handling, you may have some
looks at TLSA and DKIM together with SMTP services. My s/qmail may be a
good starting point:


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

BTW: I was also looking for SRV support in s/qmail (regarding TLSA),
but it seems not worth the effort.

One of the basic ideas in Software Engineering is: Reduce dependencies,
reduce the code base. The less, the better.


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

On 9/26/22 19:24, Erwin Hoffmann wrote:
> Hi Ellenor,
>
>
> Am Montag, dem 26.09.2022 um 12:46 +0000 schrieb Ellenor Bjornsdottir:
>> Nowadays, QMTP, QMTPS, and SMTP all have service names which would be
>> suitable for use in an SRV record, like (using this mailing list
>> host,
>> in a fictional world where SRV was the norm, as an example):
>> _smtp._tcp.list.cr.yp.to SRV 0 1 25 c.mx.cr.yp.to
>>
> could be; not no one does.

Not no-one? Eh?

If you mean you don't know anyone who does, well, you do now because on
my test rig, I do have SRV records set up for protocol tcp, services
smtp, qmtp and qmtps.

>
>
>> I plan on adding this to my own implementation of the -remote
>> functionality in my currently-private fork of notqmail. The code will
>> be
>> released in due time, and I've already broken ground (although it's
>> not
>> yet ready to test, it's just a mess of C header and boilerplate right
>> now).
>>
>> I would like to hear arguments for, and against, this idea. I note
>> that
>> I know a party (won't say whether a person, a company, or other) who
>> runs QMTPS on port 209 (the QMTP port).
> Well, some years ago, I've asked the IETF to dedicate port 6209 for
> QMTPS, which is supported in my s/qmail fork (providing X.509 client
> cert authentication support):
>
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6209
>
> For data centers working as an email hub, QMTP/QMPTS could still make
> sense to provide peer services; but not on a large scale involving SRV
> DNS records.
>
> Unlike SMTP, QMTP is binary based protocol and respects CRLF, which
> makes it inferior with todays DKIM.

It can still be done though, it's not like it's unachievable.

Of note is that the beginning byte of the message section of a QMTP
packet denotes the kind of linefeed used (\r is DOS; \n is UNIX)

>
> @John Levine: Yeah, I've implemented RFC 8463 for s/qmail; coming soon.
>
> Getting involved with notqmail is a good practicing place; but a lot of
> the code originates back in the 90th of last century.
Yeah, I've noticed a lot of straight Bernstein flow, not all of it good.
I noted on #qmail on Libera Chat that the NetStrings parser code in
qmail-qm[qt]pd.c did not balk if ch was out of the range of '0' to '9' -
it just subtracted '0', put it on len and moved right along. This would
not be a security problem but it would result in undesired behavior (a
packet of ;:12345678901, would be treated as 11:12345678901,) I broke
the code into a netstrings.c and netstrings.h file, corrected the
algorithm so it would balk in those pathological cases, added
netstrings.o to Makefile.legacy for both programs and rebuilt as
appropriate. (I may have introduced an integer footgun however by having
the output type of my function be unsigned long long)
>
> @Elleonor: To get some experiences with DNS handling, you may have some
> looks at TLSA and DKIM together with SMTP services. My s/qmail may be a
> good starting point:
>
>
> https://www.fehcom.de/sqmail/sqmail.html
>
> BTW: I was also looking for SRV support in s/qmail (regarding TLSA),
> but it seems not worth the effort.
>
> One of the basic ideas in Software Engineering is: Reduce dependencies,
> reduce the code base. The less, the better.
>
>
> Regards.
> --eh.
>
>
--
Ellenor Agnes Bjornsdottir (she)
sysadmin umbrellix.net
jabber: ellenor ~on~ umbrellix.net

Hi Ellenor,

Am Montag, dem 26.09.2022 um 20:11 +0000 schrieb Ellenor Bjornsdottir:
>
> On 9/26/22 19:24, Erwin Hoffmann wrote:
> > Hi Ellenor,
> >
> >
> > Am Montag, dem 26.09.2022 um 12:46 +0000 schrieb Ellenor
> > Bjornsdottir:
> > > Nowadays, QMTP, QMTPS, and SMTP all have service names which
> > > would be
> > > suitable for use in an SRV record, like (using this mailing list
> > > host,
> > > in a fictional world where SRV was the norm, as an example):
> > > _smtp._tcp.list.cr.yp.to SRV 0 1 25 c.mx.cr.yp.to
> > >
> > could be; not no one does.
>
> Not no-one? Eh?
>

seams, I missed your point completely. Sorry.

Feel free to do, whatever you like to do.

Greetings to the notqmail community.

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

It appears that Ellenor Bjornsdottir <ellenor@umbrellix.net> said:
>On 9/26/22 19:24, Erwin Hoffmann wrote:
>> Hi Ellenor,
>>
>> Am Montag, dem 26.09.2022 um 12:46 +0000 schrieb Ellenor Bjornsdottir:
>>> Nowadays, QMTP, QMTPS, and SMTP all have service names which would be
>>> suitable for use in an SRV record, like (using this mailing list
>>> host,
>>> in a fictional world where SRV was the norm, as an example):
>>> _smtp._tcp.list.cr.yp.to SRV 0 1 25 c.mx.cr.yp.to
>>>
>> could be; not no one does.
>
>Not no-one? Eh?

Not literally no-one; on the Internet, whatever you look for, you can
always find somebody who has done it once.

If you're exchanging mail, your mail system has to cooperate with
other mail systems. For reasons we have discussed, it is extremely
unlikely that other mail systems will adopt QMTP. SMTP is good enough,
QMTP is not better in any way that matters, and in a few ways it is worse.

You can do QMTP experiments if you want, and it won't hurt anything,
but don't be surprised when you don't find other people interested in
it.

R's,
John

Ellenor Bjornsdottir <ellenor@umbrellix.net> wrote:
>
> If you mean you don't know anyone who does, well, you do now because on my
> test rig, I do have SRV records set up for protocol tcp, services smtp, qmtp
> and qmtps.

That's great. It's technically elegant. And it absolutely won't matter one
whit for internet mail as no one will ever look them up, except clients that
you configure and deploy yourself.

I used to have QMTP deployed inside various networks, where I controlled both
ends of the send-message transaction. It may have been neat, it may have
saved a single-digit number of milliseconds on each mail sent. But it did not
make any significant difference in throughput or observable latency or any
other metric you'd care to name.

Bruce Guenter's `nullmailer` package, which is a smarter ssmtp-type client
with a basic queue so you can still "send" email when connectivity to your
smarthost is down, supports the closely-related QMQP to send messages. I've
used that, too. Makes no difference.

qmail was famous in its early days for its exceedingly sparing use of
resources; you could send millions of, say, mailing-list messages a day using
a 386 with 8MB of RAM and it was faster than any other mail solution out
there. My cubicle-mate at the time (Hi, Bruce!) ran a mailing-list expander
for the Linux kernel mailing list that served half a continent, and the
hardware of the time was pretty much that primitive.

In those conditions, perhaps QMTP would have made an observable difference in
mail throughput, if you could get it deployed universally. I wouldn't bet on
the difference being significant, but I have no doubt it might be observable.

The point being...

Implementing QMTP in whatever your network environment looks like could very
well be a fun project. On that basis alone, go for it!

But you will find it exceedingly difficult to get anyone excited by it, and
you have zero chance of making QMTP support widespread in internet mail
handling. If it was going to happen, it would have happened 20-plus years
ago.

If you want an internet email project that just might make a difference in
reality (*), go a step further than Erwin and others that are maintaining and
adding features to qmail forks, and borrow just qmail's design - process
separation, least privilege, no trust between processes, division of labour,
etc - then add modern features and flexibility that are difficult to patch
cleanly into qmail-derived codebases. And then start implementing it in a
fast, safe language, so you at least have a chance of being as secure as
qmail. Rust and Go are both good choices; there's no reason different
components of the system can't be implemented in different languages if you've
defined the communication between the processes.

djb's code was/is efficient, compact, and portable to a degree not often seen
these days. But it is difficult to dig into and modify. Every time I look at
qmail source code, if it's been more than a few months since I hacked on it,
it's like staring at hieroglyphs, and it takes hours to get comfortable with
it again. As we approoach the 1/4 mark of the 21st century, qmail's genius is
its design, not its legacy codebase.

Charles

(*) heavy on the "might". Email has been slowly devolving towards a walled
garden controlled by the relative handful of "grid-scale" email services. A
brand new MTA, even with a brilliant design and implementation, might not go
anywhere if the current trend to "getting mail through to Gmail users is
unreasonably hard and a constant churn, I'll just use <big service provider>,
who seems to have no problems with it" continues.

--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

On Mon, Sep 26, 2022, at 2:24 PM, Erwin Hoffmann wrote:
> Getting involved with notqmail is a good practicing place; but a lot of
> the code originates back in the 90th of last century.

Hi, Erwin!

There is lots of quality software in production use that that could be said of. One of the ideas behind notqmail is to make incremental improvements, in public, with test cases, that don't break people's existing patches to qmail and netqmail. Eventually, though, once the features of prominent patches have been achieved, I think notqmail would probably make improvements that could break existing patches (not that the goal would be to break them, but that the project might no longer avoid certain improvements solely because they would break existing patches).

For notqmail goals, see

https://github.com/notqmail/notqmail/wiki/Goals-and-Non-Goals

For a notqmail roadmap, see

https://github.com/notqmail/notqmail/wiki/Roadmap

Regards,

Lewis

Good Morning Lewis,

Am Montag, dem 26.09.2022 um 23:31 -0500 schrieb J. Lewis Muir:
> On Mon, Sep 26, 2022, at 2:24 PM, Erwin Hoffmann wrote:
> > Getting involved with notqmail is a good practicing place; but a
> > lot of
> > the code originates back in the 90th of last century.
>
> Hi, Erwin!
>
> There is lots of quality software in production use that that could
> be said of.  One of the ideas behind notqmail is to make incremental
> improvements, in public, with test cases, that don't break people's
> existing patches to qmail and netqmail.  Eventually, though, once the
> features of prominent patches have been achieved, I think notqmail
> would probably make improvements that could break existing patches
> (not that the goal would be to break them, but that the project might
> no longer avoid certain improvements solely because they would break
> existing patches).

I'm absolutely with you! Regarding my comment about the '90th's:
That was aleady on DJB's TODO list. Unlike other products of Dan, qmail
stands still with one leg there.

>
> For notqmail goals, see
>
>   https://github.com/notqmail/notqmail/wiki/Goals-and-Non-Goals
>
> For a notqmail roadmap, see
>
>   https://github.com/notqmail/notqmail/wiki/Roadmap

If you take s/qmail + fehQlibs side by side with notqmail's roadmap and
organize it with checkboxes, you'ld see that a lot of work has already
been done. Simply pick it up.

Interesting: Item 2.4 mentions refactoring Binc IMAP. 
I thought, I'm the only person on the planet using it. 
Could be an interesting project on its own.

Keep on going!

Regards.
--eh.

>
> Regards,
>
> Lewis

--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E

Thus said Erwin Hoffmann on Tue, 27 Sep 2022 09:19:29 +0200:

> Interesting: Item 2.4 mentions refactoring Binc IMAP.
> I thought, I'm the only person on the planet using it.

Even more interesting, I thought I was the only person on the planet
still using Binc IMAP. I suppose, however, I may be able to lay a claim
as the only person using Binc IMAP on OpenBSD. :-)

Andy

Hi Andy,


Am Dienstag, dem 27.09.2022 um 20:41 -0600 schrieb Andy Bradford:
> Thus said Erwin Hoffmann on Tue, 27 Sep 2022 09:19:29 +0200:
>
> > Interesting: Item 2.4 mentions refactoring Binc IMAP.
> > I thought, I'm the only person on the planet using it.
>
> Even more  interesting, I thought  I was the  only person on  the
> planet
> still using Binc IMAP. I suppose, however,  I may be able to lay a
> claim
> as the only person using Binc IMAP on OpenBSD. :-)
>

thus lets put our efforts together. I have the last version running and
working well together with vmailmgr and sslserver.

It would be great to have a stable and working IMAP server for qmail.

AFAIK, Dovecot is cutting service for qmail; though I use here Dovecot
as well together with my qmail-authuser module (also suiteable for
notqmail).

Lets talk offline from that list about a collaboration on that issue.

Regards.
--eh.



> Andy
>




--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E

It appears that Erwin Hoffmann <feh@fehcom.de> said:
>AFAIK, Dovecot is cutting service for qmail;

Dovecot works fine with maildirs and I doubt that will change.

WHat else would be specific to qmail?

R's,
John

Hi John,

Am Mittwoch, dem 28.09.2022 um 14:30 -0400 schrieb John Levine:
> It appears that Erwin Hoffmann  <feh@fehcom.de> said:
> > AFAIK, Dovecot is cutting service for qmail;
>
> Dovecot works fine with maildirs and I doubt that will change.
>
> WHat else would be specific to qmail?
>

it is the authentication for qmail(-smtpd). Here, I use authentication
provided by a Unix socket through Dovecot:

https://www.fehcom.de/sqmail/sqmaildoc_05.html (5.4.3)

and my auth module:

https://www.fehcom.de/sqmail/man/qmail-authuser.html

It is unclear, whether this will be supported in the future. Check:

https://doc.dovecot.org/admin_manual/mta/


Reversely, considering vpopmail as auth provider, see:


https://dovecot.org/pipermail/dovecot/2021-January/120976.html

Actually, we (or at least me) would like to have a full featured mail
environment. Providing a general user authentication capability is
certainly helpful. Thus, is a matter of interaction.

And yes: I'm still working on the qmail-ldapam; though it turns out to
be a project on its own.

Regards.
--eh.


PS: We are far way from the original thread.



> 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