In the current SMTP 'push' model, the sender has no indication of
whether a message was read or discarded.
Doesn't *usually* have any indication. I don't suppose a sender will ever
*know* if a message hase been read or discarded. I hope not :-)
In a 'pull' model, the sender knows that the message was refused,
because it was never picked up.
the sender *may* *conclude* that the message was refused if it wasn't
picked up in a certain time.
To me this raises some interesting questions.
1) Will a spammer stop trying to send spam to a domain that always
refuses his spam? (negative feedback)
2) Does this feedback help the spammer (i.e. reformat spam if he
suspects Bayes caught it...) (informative property of feedback)
These are interesting points and have been brought up in discussions of the
value of filtering during SMTP transaction.
( http://www.merseymail.com/asrg/Filter-SMTP.txt - I must have a look at
this again)
Consider SMTP transaction under the control of the recipient, then getting
envelope need not be followed by the getting of body, and the getting the
body need not be folowed by a positive response. I can't see why recipient
controlled filtering during SMTP doesn't give most (all) of the advantages
of a SMTP/pull system. It's kindof equivalent, except it has to be
automated (i guess) and it doesn't build in a delay.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg