[Top] [All Lists]

Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax

2007-07-16 01:55:32

At 22:29 14/07/2007, Markus Stumpf wrote:

On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:

Does anybody know about any MTA actively using these today?
Is there any secenario (besides address harvesting) within which these
are still useful in todays email communication?

I have seen VRFY used by spam filter appliances/services for checking whether an email address is valid, and also whether an alias which resolves to a different mailbox.

This can be useful for licencing requirements, eg a '10 user' spam filter might get a message for sales(_at_)(_dot_)(_dot_) and fred(_at_)(_dot_)(_dot_)(_dot_) If it can tell that sales@ resolves to fred@ by using VRFY, it can treat it as '1 user', if it relies on a test RCPT TO, then it has to treat it as 2 users.

Some spam filters use LDAP for this, but this relies on either the LDAP server being tied to the mail server somehow (which is by no means certain unless you are working in a MS Exchange/Lotus Domino world) or the sysadmin keeping them both in sync (again which is by no means certain). Using VRFY means that you are only asking the mail server about mail addresses, which it should know, rather than asking a totally separate server about them.

For address harvesting, using dummy RCPT TOs can be just as useful, because you don't care if an address is an alias, but for legitimate management purposes like this it does matter.

I haven't seen anyone use EXPN, but it's not hard to implement.

IMHO most MTAs support the commands but respond something like:
    252 send some mail, i'll try my best

Our MTA has a set of restrictions so you can tell it which IP addresses it will support VRFY and EXPN for, so for most people it will return an error, but for the IP address of a spam filter service it will work properly. So, if YOU were to test our mail server you'd think they weren't supported, but they are (for a select few).

Why not simply drop them completely?

I'd say no. Possibly make them an extension, or an option, but they do play a purpose that can't be achieved any other way, and they're pretty trivial to implement.