On Aug 18, 3:47am, John Levine wrote:
The disadvantage is that it requires that senders and receivers all
be connected to the same network all the time, which is a lot closer
to true now than it was in the 1980s, but still a long way from
universally true.
I'm not a proponent of the pull model, but it seems to me this could
be overcome if each receiver in a store-and-forward sequence were
able to inform its immediate upstream when it is not able to perform
the pull.
E.g., transmit the "pull handle" as far as possible, then have the
last relay that is capable of doing so, issue the pull request.
This could probably even be done with one new SMTP verb plus ETRN.
E.g. DATA FROM:<message-id> where the domain part of the message-id
must resolve to the host that will cough up the message. If the
receiver responds 50z or 455, the sender must do the pull. If the
receiver responds 354, sender sends dot, and eventually some receiver
connects to <message-id-domain> and issues ETRN #<message-id-local>.
All sorts of security implications to be worked out, Tumbleweed
problems aside.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg