On Tue, 3 Jul 2001, Sheldon Hearn wrote:
> > > Did I ask before whether you'd consider adding an option to disable
> > > recipient address syntax validation at SMTP time? It would sure be
> > > useful for CF and other equally stupid systems. :-)
> >
> > It's called the S flag on a rewriting rule.
>
> That's what you said last time, and I've just taken another look. I
> still can't figure out how this helps me. I have to supply a regular
> expression that'll match bad addresses (hard) and then rewrite them.
Yup.
What kind of syntax errors are you seeing? Surely they fit some pattern,
and if so, a regex can be written to match them.
Alternatively, maybe you know a pattern for the *valid* addresses that
come from this source; then you can write a regex that matches "not this
pattern".
> This doesn't sound like it fits the requirement:
>
> 1) From a specific list of hosts
> 2) accept invalid RCPT TO addresses and then
> 3) later, generate an appropriate bounce message
I'm sure there is a possibility of breaking all kinds of things inside
Exim if it were to accept syntactically invalid RCPT TO addresses.
Internally, it assumes that the guards on the doors are working
correctly, and that every address it has to handle is syntactically OK
and fully qualified.
What you are saying is that instead of rejecting the RCPT TO (according
to the RFC, which everybody implements perfectly, don't they?) you want
to accept the message, and send back a separate bounce to the sender
later? (This of course runs the usual risk that the sender's address is
undeliverable. And, presumably, you don't want to do it if the sender is
<>.)
I think this is a pretty exotic requirement, just to cope with sending
hosts that don't obey the RFC rules, and I'm strongly tempted to draw
the line after the 'S' flag. To implement anything else is going to
require special-purpose code inside Exim for what seems a very minority
requirement.
Or is it? What do other people on this list think? Are there lots of
things out there sending syntactically invalid addresses and not coping
with error responses? (Note that *semantically* invalid addresses can be
taken care of by not verifying from the relevant hosts.)
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
