[Top] [All Lists]

Re: RFC2821bis-01 Issue 2: VRFY/EXPN

2007-03-29 02:49:33

Tony Hansen wrote:
As yet, there has been no discussion on this issue.

Any comments?

        Tony Hansen

John C Klensin wrote:
Question:  The second paragraph of Section 3.5.3 has been rewritten
slightly for clarity and to note the parallelism between VRFY and
RCPT.   This should be checked carefully by someone with experience
actually using VRFY other than me.

Is this the only consideration you want?

VRFY (and EXPN) is talked about all over the document and in my view, I think 2821bis too much of an effort to ENFORCE it and RECOMMEND it when in fact, it is by far ignored and it is a generally feature that is OFF or enabled for authorized sessions only. This is so prevalent, even spammers consider it obsolete. If they are going to harvest, they will use RPCT where most SMTP systems are increasing performing dynamic validation to avoid serious delay validation issues such as accept-bounce spam/virus attacks.

One might suggests, if the implementation is going to validate at RCPT anyway, then why not offer VRFY validation as well. Simple, VRFY allows information to not get gathered such as MAIL FROM.

In any case, I suggest the following:

Remove the following statement in 3.5.3.

   As stated elsewhere, implementation (in the sense of
   actually validating addresses and returning information) of
   VRFY and EXPN are strongly recommended.

or changed to lesser recommendation and/or coupled with insight to offer the option to authorized clients only. I don't understand why the heavy push for something that is hardly used and if so, it is highly abusive.

Similarly, the Last sentence in 3.5.3 should be removed:

    Implementations generally SHOULD be more aggressive about
    address verification in the case of VRFY than in the case
    of RCPT, even if it takes a little longer to do so.

or changed to:

    Implementations generally SHOULD be more aggressive about
    address verification in the case of VRFY for authorized

If the goal is to change the direction so that systems are more confidence in once again begin to offer or enable this option, then tell us why and if so, how we can use it and also protect against abuse.