[Warning: possibly wacky idea ahead!]
We have a problem with mail queued to a site for which we provide
backup MX. Names and addresses changed for obvious reasons:
delivering message 0zUkl0-0004vs-00
Connecting to lame.example.com [10.0.0.1] ... connected
SMTP<< 220 lame.example.com SMTPXD version 1.24 ready at Mon, 19 Oct 1998
11:05:36 BST
SMTP>> HELO central.ulcc.ac.uk
SMTP<< 250 lame.example.com Hello central.ulcc.ac.uk, pleased to meet you
SMTP>> MAIL FROM:</G=Justin/S=Example/OU=KEBNKHSE/O=AFCARME/PRMD=BARCLAYS/ADM
D=CWMAIL/C=GB/@???>
SMTP<< 251 Sender not approved
SMTP>> RCPT TO:<support@???>
SMTP<< 251 use the MAIL command, first
SMTP>> DATA
SMTP<< 251 use the MAIL command, first
SMTP>> QUIT
It appears that 'SMTPXD version 1.24' (Digital Firewall for Unix)
is rejecting the message because it doesn't like that butt-ugly (but
legal) sender address. Well, that's their problem, and I won't lose
any sleep over it. But in that case I'd prefer not to keep retrying.
In a case such as this, when the SMTP receiver is not obeying SMTP
state rules (completely bogus use of 251), I wonder whether exim
could be a bit more clever.
I'd prefer to see that message frozen. But there are enough broken
SMTP implementations to make me wonder whether there isn't a case for
providing hooks for tweaking the SMTP transport's protocol exchange.
Something which would allow me to say things like "if, when talking
to lame.example.com, you get a 251 response to a MAIL command, rewrite
the response to 501 before continuing". With a little effort, exim's
SMTP handling could be made sufficiently configurable to cope with most
forms of bogosity. Whether this is a Good Thing is another matter,
of course.
--
Malcolm Ray University of London Computer Centre
--
*** Exim information can be found at
http://www.exim.org/ ***
