qmail-smtpd: introduce an array of EHLO string generators

[DerDakon]

This is of no direct use for the vanilla version, but it allows to simplify the integration of different patches which add add EHLO arguments. They will only need to add their print function to this array and it will get called.

[leahneukirchen]

Doesn't simply adding a newline to smtp_ehlo achieve the same patchability?

[DerDakon]

No, it doesn't. STARTTLS introduces a struct stat to check if the certificate exists, SIZE adds a local buf to print the databytes into it… With this the collisions can simply be ignored and things are put into the array, in no particular order, which can easily solved during patching as simply "pick both". At least that's what I with my packager hat on would like to see.

[leahneukirchen]

But what's the difference between:

--- foo.c	2020-07-26 22:17:54.612884429 +0200
+++ foo1.c	2020-07-26 22:18:14.456097603 +0200
@@ -1,3 +1,4 @@
 static void (*ehlo_gen[])() = {
+	ehlo_starttls,
 	NULL
 };

and

--- bar.c	2020-07-26 22:18:58.620572058 +0200
+++ bar1.c	2020-07-26 22:19:15.076748845 +0200
@@ -1,6 +1,7 @@
 void smtp_ehlo(arg) char *arg;
 {
   smtp_greet("250-");
+  ehlo_starttls();
   out("\r\n250-PIPELINING\r\n250 8BITMIME\r\n");
   seenmail = 0; dohelo(arg);
 }

[DerDakon]

Right, that would be the same. But it would be possible even now, and it has not happened yet. So I guess we need to invent some sort of infrastructure, the crappy it may be, to move people in the right direction.

[josuah]

The use case we might want to get hanlded (maybe the most complex): starttls and authentication:

Auth advertized never on port 25, never on non-tls, always on 465, only after STARTTLS on port 587.

But even so, I do not see a technical advantage on a function pointer, as then, there are still patch(1) conflicts that can occur: patch only sees text.

Do we want to move from patch toward (statically linked) modules interacting with qmail at pre-defined hooks?

[josuah]

I am happy with it, two suggestions that might be for another commit.

[schmonz]

Related, I've written up some design ideas for TLS, AUTH, etc.. Maybe this gives us a bigger picture worth arguing about :-)