[exim-dev] [Bug 855] Sender-callout-Verification should use …

Top Page
Delete this message
Reply to this message
Author: Graeme Fowler
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 855] Sender-callout-Verification should use VRFY not RCPT TO
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=855

Graeme Fowler <graeme@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |graeme@???





--- Comment #4 from Graeme Fowler <graeme@???> 2009-06-21 11:02:02 ---
(In reply to comment #3)
> RFC 821 requires VRFY and defines it as what we need for our purposes.
> http://www.ietf.org/rfc/rfc821.txt
>
> RFC 5321 requires VRFY and defines it as what we need for our purposes.
> http://www.ietf.org/rfc/rfc5321.txt


Indeed. And because of well documented problems with nefarious types using VRFY
as a dictionary address harvester, most sites switch it off. It's been
practically irrelevant for years, but is still implemented within many MTA
applications because it's mandated in the RFC.

All that said:


> However, because of the misuse of RCPT TO, in order to VRFY addresses, my IP is
> now listed on a DNSBL @ backscatter.org


You would likely be listed elsewhere if you continually did VRFY requests, too,
as they're not seen as being particularly friendly these days. I can't recall
the last time I saw a site with VRFY switched *on*.

> However, it is wrong headed (and two wrongs don't make a right) to abuse RCPT
> TO, in order to "get around" the admin's who have disabled VRFY.


The issue here is whether to do callout verification of *any* type to validate
an incoming email. A Joe Job would cause just as much pain using VRFY as using
RCPT TO.

IMO the documentation should be changed, not the code, to include a warning as
follows:


============================================================================
WARNING
============================================================================

Global, blanket usage of callout verification to validate message _senders_
against arbitrary external hosts is frequently considered abusive. Callout
verification of any sort (sender or recipient) should be restricted to networks
or hosts which are either under the same organisational control, or with which
a trust relationship exists.

Arbitrary usage of callouts to verify the existence of sender addresses may
lead to the calling host being added to several DNSBLs which will cause
problems for messages traversing the affected system.

============================================================================


There are many cases (as described above) where this type of verification is
perfectly valid (or indeed VRFY is). Switching, however, to VRFY which is
largely obsolete nowadays, would be a mistake.

Graeme


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email