On Tue, 6 Apr 1999 19:40:59 -0400, Peter C. Norton wrote:
>I'm not concerned with this. I'm concerned with Fred's proposal
>relying on the status of the remote smtp and qmtp server. If I'm
>"local" and someone else is "remote" and remote's qmtp service is
>down, but remote's smtp server is still advertising qmtp then I
>shouldn't have my queue grow because of it. There should be some
>local communication about bum servers if this database is used, to
>prevent it from severely slowing down email.
If you use qmail (the only QMTP implementation I'm aware of), the
likelihood of SMTP working and QMTP being down is virtually zero. Thus,
the likelihood of a slowdown due to this is very low.
For external problems (e.g. firewalled qmtp port with open smtp port
and both servers running) you'd fail on qmtp, log that, continue
failing until the db is updated, use smtp for the message, log the qmtp
banner, etc. This means that mail to that host will be delayed for up
to an update interval and work fine via SMTP for the next update
interval. Update db every 15 min and it still works quite well. Again,
this requires misconfiguration.
Also follows that, when QMTP fails, one would assume that the failure
is true for both channels. Thus, one would go on to the next MX. If
failure is due to a firewall misconfig, you're no worse of that with
the MX magic.
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.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
