I am kind of lost here. The current infrastructure does not require
"pull", your will require "pull". Even though its running on top of SMTP
and POP3, nevertheless you will require all clients to do "pull" in
order to get email. This looks to me as a major change.
pop3 is unchanged the sytem does not alter pop3 at all
The difference is in the host server(s) (which may happen to be on the
recipients/senders machine)
for example one possible method...
The sender sends a "pull request"
this can be in the form of shortened e-mail no body just headers
the recipients host smtp server accepts that mail as it does now but instead
of queueing it for collection it processes the request and chooses to accept
or deny.
it then sends an accept or deny message to the remote senders machine (smtp
server)
the accept message has a onetime identifier which the remote senders server
attaches to the email and then forwards it to the recipients smtp server
which checks the identifier and queues it for collection (pop3) as normal
So apart from a couple of extra commands there is little change to the
current system and it is compatible with the existing infrastructure.
At some future point e-mails sent without a properly formatted pull message
get returned as not accepted using standard failure codes and an additional
explanation message.
What about the users that force the email to be pulled, just like the
users who click on links in spam today?
Doesn't really apply if the email has made it to the users machine it has
passed all initial tests which is mainly that the source can be traced.
again spam is in the eye of the beholder. if the recipient chooses to accept
the email then so be it.
Chris
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg