On Wed, 2006-04-05 at 11:38 -0400, Brian J. Murrell wrote:
On Wed, 2006-04-05 at 15:31 +0200, Erik Slagter wrote:On Wed, 2006-04-05 at 08:55 -0400, Brian J. Murrell wrote:On Wed, 2006-04-05 at 08:57 +0100, David Woodhouse wrote:All this 'Junk' stuff on the client side is entirely suboptimal, because any well-run server will be doing it server-side.Indeed. _Determining_ junk belongs on the server. Disposition of Junk belongs on the client though.Nope.Ah, yup.The server must be able to already REJECT the spam. When it accepts the spam, it's too late.For spam that is coming from a known source of spam of course. Reject it at the SMTP envelope, sure. But not all spam comes from known sources of spam in which case you have receive the entire DATA before you can call it spam. At that point you have accepted it already and REJECTing is not an option.
Indeed it is. Although you have the disadvantage of the bandwidth already wasted, you at least make clear to the sender that you don't want it's *****. If it's ham though, then at least the sender will be notified, without _you_ having to send a non-delivery report.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature