On Sat, 9 Feb 2002, Joachim Wieland wrote:
> A mail comes in, the domain is checked but not the user. If the domain
> is a local one, the message is accepted and processed further. Then exim
> recognizes that there is no such user and sends back a bounce message.
>
> Normally one would do it within the acl_smtp_rcpt directive.
You could certainly set up an ACL that checked the domain but not the
user. Just omit "verify=recipient", but use a "domains" test to check
the domain.
> Yet, if I
> got this correct, the ACLs would be evaluated right after the RCPT TO:
> command. If I am an evil[tm] person and want to see if email addresses
> are (still) valid, why does this do a different job than EXPN or VRFY
> which are widely regarded insecure?
There is very little difference between RCPT and VRFY. I suspect most
checkers now use RCPT to do their checking. Yes, it's evil. The only
thing you can do is reject after too many RCPTs in one message, but even
that's a bit dangerous.
There is a lot of difference between RCPT/VRFY and EXPN, which can
display the contents of an alias list. That is much more dangerous.
> Okay, I disabled this check not only because it is similar to the
Disabled which check? The domain or the user verify?
> EXPN/VRFY commands but because the user setting is quite complex in my
> situation (database involved, forwards, virtual local users...)
Sounds like you just disabled the verify=recipient. No problem. If you
want to do that, that's fine. You just end up with more undeliverable
bounce messages on your host.
> Of course I could send back a custom message with the redirect router
> and specify either :fail: or autoreply but I'd like to have a bounce
> message that really looks like a bounce message, i.e. one that contains
> the name of the server, the reason of the failure, the header lines and
> the head of the message...
It is certainly the case on our hosts that the vast majority - by far -
of invalid RCPT addresses are attempts to send spam. I'd much rather
bounce these at RCPT time, because otherwise we end up with a queue full
of undeliverable messages since most spam has an invalid sender address.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
