On Thu, 20 Feb 2003, Greg A. Woods wrote:
> [ On Thursday, February 20, 2003 at 16:08:54 (-0500), James P. Roberts wrote: ]
> > It seems obvious that (e) would be the preferred solution, in
> > cases where the server has the resources to do so.
>
> No, it's not so obvious that rejecting at SMTP-time is the preferred
> solution. It's not just a question of resources per se, and where you
> choose to deploy them, but also about the knowledge you might have
> about, and the trust you put in, the client-host's SMTP protocol
> implementation, as well as the knowledge you have (or do not have) about
> your own user base.
>
> Assuming the client-SMTP was a remote (and thus untrusted) host then the
> only really obvious (and thus preferred) solution is to accept the
> message, identify it as containing questionable content, and ask the
> intended recipient whether to deliver (perhaps with de-fanging or
> tagging) or delete it.
>
> Maybe if the client-SMTP is actually a locally trusted host then you'll
> want to do something completely different....
I realized earlier in this conversation that yes I am in a non-standard
position, where I can usually trust the sending SMTP server
(My primary MX points at my ISP's mail server, which is run by
people I believe are in the same office as Phil Hazel).
So yes I do want to do something completely different...
In the more normal case, if we can't trust the sending SMTP server to
accept "I don't like that message, and don't try again", and there are
so many machines like that out there that we can't afford to keep telling
them to go away, then we have taken the first step in the slippery road
to the end of email as we know it.
So I still believe that (e) is the ideal solution - ie the solution
to be adopted in an ideal world (except that in that world we wouldn't
need to worry about spam).
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@??? http://www.dpmms.cam.ac.uk/~werdna
