[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] 6. Proposals - Pull System (revisited)



> 
> 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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg