Hello Davide,
>>The target domain has 3 MX entries:
>>
>>20 buch.biblio.etc.tu-bs.de.
>>58 rzcomm5.rz.tu-bs.de.
>>10 mailscan.biblio.etc.tu-bs.de.
>>
>>MX 10 seems to be filtered by a firewall or a spam policy going
>>wild (responds to ping, connect to port 25 times out).
>>
>>MX 20 seems to be shielded by policy (only allows local connects?)
>>reports with a bit atypical message 520 (but "5" IMHO is quite
>>correct: This MX permanently won't accept [my] mail)
>>
>>MX 58 would accept the mail, but XMAIL (1.20, WinNT) doesn't even try
>>to connect to this MX. Here is the complete slog of the delivery
>>attempt:
>
>
> The 5xx responses are for definitive errors. Why should a server be listed
> as MX record to spit out 5xx responses for such domain?
I have no idea: Laziness or a broken backup MX strategy or someone
being overly clever ("If the AV scanning gateway is overloaded give
at least campus local users an alternative server"). But extra
backup MX servers also help in this situation ;-)
RFC 2821 says: "The SMTP client is discouraged from repeating the
exact request (in the same sequence)" (4.2.1). It does not even say
"SHOULD NOT" or "MUST NOT". And SMTP replies reflect "the state
of the SMTP server" (4.2). RFC does not say something like "status
message tell the truth about the world" or "message will not be
accepted by any other means you may try".
Specifically "55x" indicates a "permanent negative completion reply"
with respect to "status of the receiver mail system". "52x" is uncommon
but indicates a "permanent negative completion reply" "referring to
the transmission channel". Status codes as "550 relay not permitted" or
"554 no SMTP service here" (let one speculate about the sanity of the
remote setup but) give no clue about the status codes other MX servers
will or would give. Even for "552 mailbox full" it would be a viable
strategy to deliver the message to a backup MX for that domain: Maybe
they have put the queue on hold or whatever. In any case the backup MX
has the chance to deal more adequately (know better) than the sending
MX.
XMAIL should drop servers which gave 5xx errors from further retries
in transmission but should continue as long there are any servers
left. This will be a bit inconvenient when (due to misconfiguration)
some of the MX time out permanently because XMAIL will try again and
again for the whole retry period and not bounce immediately.
viele Gruesse
Thomas Berger
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
