On Tue, 2007-09-25 at 18:19 +0200, Marc Haber wrote: > Did you read what you quoted? They think their product does not need
> fixing as it is working as designed.
And they're correct. Putting on my Devil's Advocate cloak for a moment,
just imagine the following design discussion (which assumes reasonable
knowledge of SMTP at protocol level on the design team's part):
What do we do when the backend server we're proxying to goes away? Do
we:
Queue the mail? No, this isn't an MTA, it's a transparent proxy.
Refuse the connection? Hey, yes, we could - but we're working, it's the
backend that isn't, so that isn't right. Best generate some sort of
error.
Should it be a temporary error? A "451 backend server not responding",
perhaps? Hrm, probably not - that gives away too much about the local
infrastructure. We could make the error more generic, but it isn't us
having the problem, it's the backend server - and this is supposed to be
transparent. And how do we code it so that we know the error is
temporary? If we're frontending lots of backend servers, maybe one of
them has been taken offline permanently - in which case remote mail
destined for that one should be bounced anyway.
OK, what about a permanent error? Now that solves a lot of engineering
and code problems, and makes the solution much easier to produce.
Backend server offline, we can't verify anything, send back a 550.
Perfect! Can you have that written by Wednesday?
...now, back in the real world, many people will disagree *but* their
design decision has been made based on facts of which none of us are
privy (the conversation above is, after all, hypothetical). If that
gateway decides that an unresponsive backend merits a 550 to remote
senders, so be it. That's the *vendor's* design decision, whether any of
us think that the design is right or wrong.
Can we all stop arguing about Marc's problem now? Hopefully moving your
Exim system elsewhere will fix it, which is a much more elegant solution
than bastardising protocol handling.
