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 username(_at_)example(_dot_)com VIA 134.193.4.60
and mx.example.com replies 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) <-- (possibly cached
non-local 250 response)
253 (good user, they have path-checking turned off so we reccommend
optimism)
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
about the path)
454 possibly cached non-local 453 response
504 I cannot understand the path parameter
550 (bad user, don't care about the path)
551 not our user (implies that we don't do recursive queries)
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)
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
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.
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 tuco(_dot_)ramirez(_at_)example(_dot_)com 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?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg