ietf-asrg
[Top] [All Lists]

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

2004-02-18 17:54:51

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 username(_at_)example(_dot_)com 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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg