Hi Philip, on Mon, 23 Dec 2002 10:22:24 +0000 (GMT) you wrote:
> Tim Jackson wrote:
> > Am I doing something silly, or is it simply not possible to do
> > verifications in the MAIL ACL? What's the reasoning behind this?
> Well, you certainly can't verify recipients or header lines, for obvious
> reasons. I suppose in principle you could verify the sender address that
> the MAIL command has just given you.
Indeed. In fact, that's what I was expecting most people might use the new
feature for (and assumed that was why you'd added it). Just for
comparison, from my (limited) experience (and memory, so with sendmail,
it has for some time rejected invalid senders at the MAIL stage (if you
enable verification):
$ telnet old.mail.server.which.needs.migrating.to.exim 25
220 blah ESMTP Sendmail 8.11.6/8.11.6; Tue, 24 Dec 2002 18:14:03 GMT
HELO remote.blah
250 blah Hello remote.blah [x.y.z.a], pleased to meet you
MAIL FROM: <dfdf@dfd>
553 5.1.8 <dfdf@dfd>... Domain of sender address dfdf@dfd does not exist
Now, I don't think it desperately matters either way, and
I can think of some arguments for waiting until RCPT (e.g. you will be
blocking mails that might be to postmaster), but personally I would like
to reject at the MAIL stage, on the basis that the bounces generated by
originating MTA's often look something like this:
# Hello this is an MTA, blah blah failure etc.
# ...
# I said:
# # MAIL FROM: <address@domain>
# The remote server said:
# # 5xx something about an invalid address
If you reject at the MAIL stage, it's clearer to a genuine user with a
misconfiguration/problem that the errormessage is related to the envelope
address the mail came from, not who it was going to; this (which happens
if you do sender verification at RCPT) could be confusing:
# Hello this is an MTA, blah blah failure etc.
# ...
# I said:
# # RCPT TO: <validuser@someotherdomain>
# The remote server said:
# # 5xx something about an invalid address
(The "something about an invalid address" refers to what a typical
end-user might interpret the message as)
> It looks as though I just overlooked this possibility, and just locked
> out "verify" completely. Noted for consideration.
Thanks, that would be good for the next release, and a fairly trivial
patch I assume (?). I'll have a look at patching it myself if I get a
chance, if for no other reason than as a learning exercise.
Thanks,
Tim
