Pull retains the "openness" of the current system. but ultimately flips the
coin from push to pull
and delivers the choice to the recipient not the sender.
Personally I don't mind hearing about new ideas, but you have to
explain why the new ideas are any better or different from the old
ones. A free-form debate on a mailing list may or may not do it:
reference to a detailed document or description would be better. For
instance:
- What can "pull" do that "push + sender-system-validation" can not?
My imagination may be limited, but I can't think of anything other than
that "pull" introduces a whole nother round-trip conversation. (Now,
"pull" might be able to have other interesting things layered on top
of it, such as issuance of tickets or acceptance criteria or
redirections, but that's a more extended conversation).
- What can "push + sender-system-verification" do that "pull" can not?
Again with my limited imagination, it seems to me that
"push+validation" supports other things in the requirements document
(such as roaming) a lot better than "pull" -- and also supports
multiple sender systems better.
(Note that I am not really looking for answers here, just pushing fodder
for any potential document.)
e.g. porn vendors sending unsolicited e-mail that ends up in childrens mail
boxes
So an SMTP PULL server configured for a child would have a "class/adult deny
all" setting
if the sender classifies the pornographic email as a "class/general" then it
could be actioned and a conviction sought and got.
5xx
mm
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg