Hi All.
I have observed some strange behavior when using VRFY against my Postfix
relays.
I use GLD greylisting called as a policy service:
smtpd_recipient_restrictions = check_recipient_access
pcre:/etc/postfix/recip_access,
permit_sasl_authenticated,
permit_mynetworks,
check_recipient_access proxy:mysql:/etc/postfix/spamattack.cf,
*reject_spf_invalid_sender,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:25252
* spf_mark_only = yes
GLD checks a whitelist of ips and class C nets as well as an "mxgrey" table
that maps trust to ip address of the conecting MTA.
If I use VRFY from a host in $my_networks I get the expected behaviour.
These relays have no local accounts apart from system accounts so will
return 252 almost exclusively, ie. having VRFY enabled is not an issue for
spammer address harvesting.
If however I attempt to VRFY an address from a remote address that is
neither in $my_networks nor trusted by GLD either by the whitelist or mxgrey
tables, then I get the 4xx greylist response. If I keep issuing the same
VRFY command I eventually get 252 2.0.0 (once the greylist period has
elapsed). Similarly, I can generate 554 5.7.1 <[EMAIL PROTECTED]>: Relay access
denied if I try to VRFY an address that I will not relay for from an
untrusted host (ie. no sasl, not in my_networks). So it seems that
smtpd_recipient_restrictions are somehow being invoked when VRFY is used? Is
this expected/correct behaviour or a bug? My understanding is that VRFY
should respond with; 250, 251 or 252 only.
So apart from wanting to understand what is going on, my question is whether
or not I should just disable VRFY, and what are any pitfalls of doing so? I
was content to have it monotonously return 252 but if it is broken and I
don't need it then I will turn it off.
Cheers,
Pete
