Phil Pennock <exim-users@???> (Do 19 Jan 2017 10:20:19 CET):
…
> Hrm? I wasn't reading the other thread.
>
> Exim used to support both EXPN and VRFY but the default ACL is to deny,
> so you need to explicitly enable via ACL. Although ... it's not showing
> up in EHLO response, when I thought that it used to, so that might be a
> regression?
Does it not to be "advertised"? VRFY and EXPN are normal SMTP commands,
aren't they? MAIL, and RCPT isn't "advertised" too.
> acl_address_check:
>
> accept hosts = +addresscheck_allow_hosts
> endpass
>
> accept authenticated = *
> condition = ${if inlisti{$authenticated_id}{ADMIN_AUTH_IDENTITIES}}
>
> deny message = You may not VRFY or EXPN here
And my idea goes a little bit further. VRFY alone isn't useful, it just
tests the address existence. But, there might be policies, e.g. bounces
are not accepted for specific addresses, or the generally the acceptance
depends on the sender address.
I can imagine to bind VRFY to a preceeding MAIL command. Usage
about this way, plus some ratelimit and such.
And of course, callout code needs to use VRFY instead of RCPT.
Here some POC for the sending side, allowing VRFY for sender
verification:
acl_check_mail:
accept set acl_c_mail = yes
acl_check_vrfy:
require message = please issue MAIL first
condition = ${if def:acl_c_mail}
accept acl = acl_check_rcpt
# message is not used for accept :(
message = $local_part@$domain accepts mail from <$sender_address>
deny message = 551 $local_part@$domain does not accept mail from <$sender_address>
And probably we (the developers) should check about the rationale behind
returning 252 if we do not do any verification at all. 502 seems to be
more approbiate. But maybe there are clients in the wild, that first
check the address via VRFY and consider 502 as "address does not exist".
Does anybody have more information on that?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
