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

From: "Jon Kyme" <[email-masked]>
Date: Tue, 25 Nov 2003 16:29:54 +0000

> 'Pull' is relevant within the context of obtaining content from sources
> that
> you regularly receive content from, it is not a generic email replacement
> protocol.

Sure, I don't really see how fiddling SMTP to allow envelope (+some
headers?) and body to be transported separately - which is what this would
boil down to - can have any real advantage. As Phillip suggests, existing
pull protocols can be very useful for certain application swhich currently
use SMTP, "mailing lists" /discussion groups for instance. This is also
done with POP, IMAP and HTTP of course.

--

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 09:36:33 +1030

> boil down to -

if this is what you think then you have missed the point

the point is the recipients server then retrieves the email body **if** it
passes initial tests (less load on network)

such as the class is acceptable, the origin (country?) is acceptable.

the act of retrieving the mail is in fact a verification of the identity of
the source server

it is this verification that holds the most power. spammers will find it
much harder to hide behind falsified information
if they do their ISP becomes ultimately responsible for allowing them to
spam the network

can have any real advantage. As Phillip suggests, existing
> done with POP, IMAP and HTTP of course.

not relevant

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 26 Nov 2003 10:01:57 +0000

>if this is what you think then you have missed the point

I *do* think this. Am I wrong in some way? Is there some way of doing some
kind of useful pull mechanism for messaging that wouldn't rely on the
separate transport of the message itself and some "meta-data" ?

>> done with POP, IMAP and HTTP of course.

How can considerations of existing, widely used pull protocols NOT be
relevant when someone proposes a NEW one.

I'm not sure that you've really thought this through.

--

---

From: David Maxwell <[email-masked]>
Date: Wed, 26 Nov 2003 13:55:06 -0500

> done with POP, IMAP and HTTP of course.

One significant difference in a pull infrastructure is feedback.

In the current SMTP 'push' model, the sender has no indication of
whether a message was read or discarded.

In a 'pull' model, the sender knows that the message was refused,
because it was never picked up.

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)

3) How long must my server hold mail for you to pick it up? (balance of
burdens)

-- 
David Maxwell, [email-masked][email-masked] --> Although some of you out
there might find a microwave oven controlled by a Unix system an attractive
idea, controlling a microwave oven is easily accomplished with the smallest
of microcontrollers. - Russ Hersch - (Microcontroller primer and FAQ)

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 26 Nov 2003 22:00:17 +0000

> 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 :-)

> 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.

> 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.

--

---

From: "Chris" <[email-masked]>
Date: Thu, 27 Nov 2003 11:30:50 +1030

> because it was never picked up.

Yes. this is an huge advantage to legitimate senders.
currently "bounced" messages are virtually useless.

> refuses his spam? (negative feedback)

possibly why continue if it is never going to arrive
currently spammers simply ignore such bounces(IMHO).

> suspects Bayes caught it...) (informative property of feedback)

I have considered the possibility. that is why I believe this sort of system
or any other can only work in conjunction with  a legislative approach.

But in my variation of pull the deny message would be very limited i.e.

1/ no classification header - should be fixed (an honest error?)
2/ unacceptable origin - gives the sender the chance to find out why.
perhaps they have been incorrectly blacklisted.
3/ no such mailbox exists - delete the recipient from your list they have
moved on
4/ unacceptable classification - the mail falls into the recipients "don't
accept" category

With the latter the sender may choose to falsify the classification. this is
where legislation must step in.

> 3) How long must my server hold mail for you to pick it up? (balance of

Because in my pull variation the decision to accept or deny is host server
based (not pop3) the decision should be forthcoming within moments.

under normal systems a timeout period applies for undeliverable mail

I can see no reason for this to change

remember it doesn't have to wait till the recipient logs on to get his mail
(which could be weeks/months)

Also the burden of storage is shifted from the recipient to the sender
in the case of a bulk mailing this is much more efficient

only one copy requires to be maintained when there may be many thousands of
recipients

in the case of personalised mailouts the mail could be generated when the
accept is received

this would also be a saving of resources for the sender

and as a sender of bulk mail I sometimes get bounces as "users mailbox is
full"
I often wonder whether their box is just full of spam / virii or simply
abandoned

with less accepted spam this is less likeley to occur

Regards
Chris