Charles Cazabon wrote:
> Marc Perkel <marc@perkel.com> wrote:
>>
>> But Qmail won't send the email to the backup MX?
>
> Not if it is able to make a tcp connection to a
> higher-priority/lower-distance one.
>
>> There's a spec - everyone else follows the spec - except qmail.
>
> Your assertion is incorrect. Re-read RFC 974:
>
> If the list of MX RRs is not empty, the mailer should try to
> deliver the message to the MXs in order (lowest preference value
> tried first). The mailer is required to attempt delivery to the
> lowest valued MX. Implementors are encouraged to write mailers so
> that they try the MXs in order until one of the MXs accepts the
> message, or all the MXs have been tried.
yep, it is written right here: "accepts the messeage". I think it is far
different from statment: "accepts the connection".
>
> Only trying the lowest-distance MX is permitted. If you think
> otherwise, you're discarding mail, and you've got no noe to blame but
> yourself.
>
> If you want to make your hare-brained scheme work, don't accept the
> connection in the first place, rather than accepting it and not
> accepting the message.
is this statement also included in RFCs? Don't you think you have gone too
far? Acceptance of connection == acceptance of message? You are suggesting
that Marc's solution should work this way: reject connection if it can't
accept the message. So why not to use this suggestion to all conditions
which cause rejecting of message (bad rcpt, over quota, virus, spam scan at
smtp, etc)? I know why - it is impossilble to check these conditions without
the message. Chicken and egg problem. So acceptance of connection doesn't
mean that the message will be accepted. So if message is rejected (even
temporaily) why not to try next MX (as RFC 974 said)? Is Qmail following the
specs or it is not?
>
> Charles
Greets,
Pawel Panek
|