Subject: [Asrg] 3c: *MX through extended ESMTP VRFY extenstion

From: david <[email-masked]>
Date: Wed, 18 Feb 2004 18:44:37 -0600

Proposal:  define an ESMTP extension that allows the VRFY command to
accept additional information -- a host address -- and defines 
responses.  Instead
of using DNS for distributing this information.

The MX hosts for your domain would need to be aware of where
you are when you roam -- but that is between you and your domain and could
be resovled as part of your e-mail service.

Information about how long to cache a result would be included in the 
responses

MTAs might become caching verifiers just like DNS servers?

I imagine a new EHLO heyword VRFYVIA which would extend VRFY so that
you can ask example.com's MX

      VRFY [email-masked] VIA 134.193.4.60

and mx.example.com will reply with one of the following extended list of 
response codes
    250 (good user, good path, we would accept and deliver to them)
    251 (good user, good path, but not local)
    253 (good user, they have path-checking turned off so we reccommend 
optimism)
    453 (good user, they might be roaming, we're checking with them 
about the path)
    504 I cannot understand the path parameter
    550 (bad user, don't care about the path)
    551 not our user
    553 problem with mailbox name
    554 (good user, bad path: do not accept)
    555 (good user,  known to roam, but query about this path has 
expired so we reccommend pessimism)

and NOT one of these keywords listed in rfc 2821
    252 "Cannot VRFY user, but will accept message and attempt delivery"
    502 not implemented.  We lied when we listed VRFYVIA in our 
capbilities list.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: David Nicol <[email-masked]>
Date: Wed, 18 Feb 2004 19:26:07 -0600

Whoops, left out non-local cases and the whole caching concept.

Any VRFYVIA response can contain a CACHEFOR [number] keyword, which
indicates how many seconds to cache the result.  Participating MTAs are
responsible for caching CACHEFOR information in terms of an expiration time
and including propoerly adjusted CACHEFOR numbers in non-local replies.

> Client asks: VRFY [email-masked] VIA 134.193.4.60
> and mx.example.com replies with one of the following extended list of 
> response codes
>    251 (good user, good path, but not local)  <-- (possibly cached 
> non-local 250 response)

    254  possibly cached non-local 253 response
    255  the mx that handles the recipient of this message does not do 
VRFYVIA

>    453 (good user, they might be roaming, we're checking with them 

    454 possibly cached non-local 453 response

>    551 not our user (implies that we don't do recursive queries)

    505 possibly cached non-local 504
    556 possibly cached non-local 550
    557 possibly cached non-local 553
    558 possibly cached non-local 554
    559 possibly cached non-local 555

>    502 not implemented.  We lied when we listed VRFYVIA in our 

Better still, we could allow 502 and use reply code 502 as a signal for 
indicating
which MX (other than us) is the designated VRFYVIA host for a domain:
    c: VRFY [email-masked] VIA 134.193.4.60
    s: 502  mta3.example.com CACHEFOR 2419200
then client would have to disconnect from wherever they are connected to
(mta1.example.com perhaps) and connect to mta3.example.com instead to
get VRFYVIA data.

Implementing for receiving MTAs:

Choose a participating r3-type box to be the main VRFYVIA cache for your 
network or ISP,
and consult with it before accepting any mail.  When the machine is 
heavily loaded it might
start fail gracefully by issuing 551 codes so we have to watch for the 
551 code and do our
own recursive VRFYVIA queries when we see one, otherwise we can accept 
or not based on
the possibly cached data.  Also have to watch for 502 and go ask 
elsewhere when we
see that too.

Comments, please?

---

From: Andreas Saurwein <[email-masked]>
Date: Wed, 18 Feb 2004 22:37:56 -0300

>Comments, please?

Only one: Which halfway sane mail administrator has VRFY enabled nowadays?

Are you trying to introduce better address harvesting support for ESMTP or 
what?
Sorry, I dont get it.

Andreas

---

From: David Nicol <[email-masked]>
Date: Wed, 18 Feb 2004 19:48:57 -0600

Andreas Saurwein wrote:

> Are you trying to introduce better address harvesting support for 
> ESMTP or what?
> Sorry, I dont get it.
>
> Andreas

the proposed VRFYVIA does not imply VRFY.

Does LMAP etc. have a response to the "it would facilitate harvesting" 
argument?
That would apply here too.

---

From: Philip Miller <[email-masked]>
Date: Wed, 18 Feb 2004 22:00:07 -0500

> That would apply here too.

I think Andreas was keying on the subject line you used and the way you 
phrased your proposal. This has disadvantages similar to VRFY, in that it 
could potentially be used to verify the authenticity of addresses if one 
isn't careful with the responses.
On the other hand, we've seen that spammers have little to no motivation to 
prune invalid addresses from their lists, as they have little cost either in 
sending or in dealing with bounces.

LMAP has no response to 'it would facilitate harvesting' because anyone who 
reads the discussion document (not sure about the specific implementations) 
can see that it doesn't. It gives no information about any specific mailbox 
specification, only the relationship between an IP and a domain.

I'll comment on your proposal separately.

Philip Miller

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 18 Feb 2004 22:06:35 -0500

> That would apply here too.

There is a key difference between LMAP and your proposal: LMAP only 
deals with domains, not individual senders. This is why harvesting would 
be a bigger issue with your proposal rather than LMAP.

However, the same exact issue applies with any kind of SMTP-based 
challenge response system like Verizon uses. So far we haven't seen any 
facts on whether it has facilitated harvesting.

The following presentation might be useful, since it looks like the same 
thing as you are trying to do:

http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf

In general, it is a good idea to consider other means of authentication 
and identification aside from STMP. The key question is to decide which 
do we care to identify and authenticate: IP address, domain or 
individual sender. There is still significant disagreement on that.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Feb 2004 08:31:16 -0500

David Nicol <[email-masked]> wrote;
> That would apply here too.

  Not for email addresses, because LMAP doesn't publish information
about email addresses.

  LMAP does have a statement about the records it does publish.  All
such information is already public in one form or another.

  Read the document for more details.

  Alan DeKok.