On Wed, Apr 07, 1999 at 10:37:48AM -0400, Chris Johnson wrote:
> On Wed, Apr 07, 1999 at 08:53:29AM -0500, Fred Lindberg wrote:
> > Since SMTP and QMTP are linked anyway, the advertizing of QMTP by the
> > SMTP server could easily be linked to QMTP being up. Thus, a working
> > smtpd with a failed qmtpd (admin forgot to start?) would not advertize
> > QMTP. This would also make this part of config automatic, i.e. if you
> > choose not to use qmail-qmtpd, you won't advertize it.
>
> Why not just implement QMTP in qmail-smtpd? qmail-smtpd would advertise QMTP in
> its banner, and then the host connecting would be free to start firing away in
> QMTP lingo. There would never be any question of QMTP being up, since
> qmail-smtpd would know how to talk QMTP itself. The fact that a particular host
> talked QMTP on its SMTP port could be cached so that one wouldn't even have to
> wait for the banner next time.
Just one point.. the qmtp protocol would then need to be adapted so that it would
ignore this banner.
> If the remote host sent some kind of magic string to indicate that it was about
> to start QMTPing, the above could be implemented with a simple patch to
> qmail-smtpd that exec'ed qmail-qmtpd upon reception of the magic string. Or it
> could be done in the qmail-popup fashion--a program could answer the
> connection, advertising QMTP, and exec qmail-smtpd or qmail-qmtpd depending on
> whether it received a HELO command or a QMTP command.
Also very feasible, but this too would require a change to the QMTP standard. I think
if we want this, we should do it right now, while qmail is still the only
qmtp-supporting mta.
Your point with the caching is very good. I don't know which of the mentioned
approaches would be the best, but this is one good possibility.
Greetz, Peter
--
| 'He broke my heart, | Peter van Dijk |
I broke his neck' | [EMAIL PROTECTED] |
nognixz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl |
| Hardbeat@undernet - #groningen/#kinkfm/#vdh |
