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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2003 10:17:06 -0800

> > Whether or not pull eliminates spam is besides the point.
> > 
> > Pull eliminates false positives which are a serious problem 
> for email
> > broadcasters. It does not matter how good some spam filter 
> might be in
> > theory, if you are on the sending side you have to deal 
> with the rubbish
> > people use, or more accurately their ISP uses.
> > 
> > 
> 
> I am confused Phill. this sounds like a promotion of pull ?

Your problem appears to be that you confuse an honest assement of the
pros/cons of a protocol with outright opposition.

Pull is a useful concept, but it is only applicable for a small subset of
email messages - regular broadcasts. The problem is that for the protocol to
be pull it must be initiated by the recipient. Otherwise it is simply a
baddly implemented push protocol.

RSS does the task you propose better than a bodged version of SMTP.

		Phill

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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 1 Dec 2003 16:02:07 -0500

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Yakov Shafranovich'" <[email-masked]>; "Hallam-Baker,
Phillip" <[email-masked]>
Cc: "'Scott A Crosby'" <[email-masked]>; "Chris" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 01, 2003 1:20 PM
Subject: RE: [Asrg] RE: 6. Proposals - Pull System (revisited)

> It shifts that burden for all email senders.
>
> It seems as if what you want is the ability to read just the headers of an
> email message and then decide to reject it.
>
> This is possible in the existing SMTP deployment, just send a refusal code
> and slam the connection shut as soon as you detect spam.
>

Unlike FTP, we can't gracefully abort the DATA transmission channel.  As you
know, SMTP only uses one channel (port).

In practice (as we saw it during R&D), dropped a DATA transmission will
cause many clients to retry.

Of course, a session record can be recorded and if the client retries again
with similar client attributes (same IP, same HELO, same MAIL FROM and same
RCPT TO:), then you can probably use this information to block the second
attempt at these states by issusing a refusal code the client will now be
able to read.

However, in practices, for spoofing spammers,  they may come in on a
different IP, use a different HELO and/or MAIL FROM.  So it would be hard to
track.

So I don't think dropping a DATA transmission works in the present form of
SMTP.

PS: When we explored it, it was done not for spam but to restrict data size.
Our software will stop receiving once the limit is reach and issue the
refusal code.  All remaining data is discarded as an unknown command error.
This the best solution, but dropping didn't work. They will retry.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com