Russell Nelson <[EMAIL PROTECTED]> writes:
> Johan Almqvist writes:
> > Hi!
> >
> > 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
>
> That's a misconfiguration. I'd rather that the email bounced than it
> got delivered via SMTP silently. It could be that someone unaware of
> the MXPS standard (which admittedly includes 99.999999% of the world's
> population) could have set their MX priority to 12801. If so, it's
> best to ask them to change their MX priority.
I think that's probably the opposite of what the user who sent the
message wants.
Far better to deliver the message, and include an option for mail
administrators who are concerned about these things to log the
"downshift" to SMTP. If they're concerned, they can look through
their logs (perhaps from a script run from cron), and fix their own
system, or contact the administrator of the misconfigured system.
The sender, who will receive the bounce message, can do nothing to
correct misconfiguration on their side or the recipient's side. It
does no good to send a message to *them* about the misconfiguration,
which probably will never reach any of the involved mail
administrators.
And, since MXPS is not an accepted Internet standard, the (unlikely,
but possible) situation where somebody has chosen an MX priority which
isn't MXPS-compatible should be handled gracefully. The idea of
multiple vendors introducing incompatible extensions to the mail
delivery process, and having messages bounce if their conditions are
not met, makes me very uncomfortable. A mail sysadmin should be able
to read their own system's documentation, and all relevant mail RFCs,
and have a complete working system. They should not be required to
read the documentation of every existing mail system to find out about
incompatible extensions.
If MXPS was a standards-track RFC, the situation would be different,
but I still see no reason to bounce messages that can be delivered.
> It's much more likely that someone intends that the email be
> delivered via qmtpd but it is failing to run for some reason. If we
> fall back to smtp, they'll never know that it's failing unless they're
> watching their qmail logs carefully.
Then provide a script to analyze these logs and email the concerned
parties.
-----ScottG.
