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