james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hontvari Jozsef" <hontva...@solware.com>
Subject Re: preprocessing after smtp DATA
Date Sat, 19 Apr 2003 15:50:55 GMT
On the large traffic I mean not the bandwith but the processing time.
Especially considering that we cannot set remote delivery threads to more
then one because of the 100% processor usage bug. Yesterday there were far
more traffic then the usual at us, and the output directory contained 300
Regarding viruses (I mean both the virus emails and the active viruses
trying to relay), eliminating the bounces is quite useful for everybody,
because the bounces ususally affects an innocent.
However I also understand your points.

----- Original Message -----
From: "Serge Knystautas" <sergek@lokitech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Saturday, April 19, 2003 5:33 PM
Subject: Re: preprocessing after smtp DATA

> Hontvari Jozsef wrote:
> > It seems to me that the current james behaviour, accepting everything in
> > smtp, wonderfully attracts viruses, generating large and unnecessary
> > traffic. Rejecting most messages immediatly within the smtp session
> > help.
> We've discussed the idea before, and some people have interest in this.
>   I've been against it because of these reasons:
> 1. It makes mail processing synchronous instead of asynchronous, so when
> you're mail server is busy, you become unable to accept both good and
> bad messages.
> 2. The bandwidth-preservation argument is not very compeling IMHO.
> Virus scanners are licensed in messages per hour, so unless you are very
> rich or have a 9600 baud modem, you'll probably not have an issue.  Spam
> rejection is a bit more compeling, but given that the MAIL FROM and RCPT
> TO commands can be 100% forged, you can't do much spam rejection without
> receiving the message, thus not saving you much.
> 3. It takes bounces by *your* mail server and puts the burden of writing
> a good explanation on the *remote* mail server.
> 4. Denial-of-service is probably the most compeling reason to do
> something like this, but these don't need to be programmatic, and some
> standard conf file settings could handle most needs.
> I understand there are reasons that people would want to do this, but to
> date have seen the benefits as marginal and not worth complicating the
> processing notion.
> --
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >> http://www.lokitech.com/
> p. 1.301.656.5501
> e. sergek@lokitech.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message