Johan Almqvist <[EMAIL PROTECTED]> writes:
> I think there may be a problem with the patches to qmail-remote that make
> it speak QMTP based on MXPS.
>
> If the QMTP connection fails (because the remote host doesn't have a qmtpd
> running) this failure will be logged as
>
> deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/
>
> which means that the message will not be retried at the next best MX but
> go back to the queue.
I don't see it. Russ's patch looks like this (at least, in the
version I downloaded):
- if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) port,timeoutconnect) == 0) {
+ if (qmtp_priority(ip.ix[i].pref)) {
+ if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) qmtp_port,timeoutconnect) ==
+0) {
+ tcpto_err(&ip.ix[i].ip,0);
+ partner = ip.ix[i].ip;
+ qmtp(); /* does not return */
+ }
+ }
+ if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) smtp_port,timeoutconnect) ==
+0) {
In other words, if the MX priority indicates QMTP, try to make a QMTP
connection. If that connection fails--if it times out, or if the
remote system does not accept the connect request--timeoutconn will
return -1 and qmail-remote will go on to try to make an SMTP
connection.
The scenario you describe should only occur if the connection to the
QMTP server succeeds, implying that something is listening on port
209, but that whatever program is listening doesn't speak QMTP as
expected.
What am I missing?
Ian
