You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Hontvari Jozsef <ho...@solware.com> on 2003/04/19 16:35:46 UTC
preprocessing after smtp DATA
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 would
help.
I am thinking about introducing an additional processor, which runs within
the frame of the smtp session (instead of the spool). When the sender
completed the transmission, we have a complete mail object. Instead of
confirming the DATA command immediately, james should pass the mail object
to a special processor (similar to "root"). This processor can be completely
compatible with the current LinearProcessor, hopefully the same class could
be used.
The mailets in the processor should set the state to a special REJECT value
and add an error message and an smtp error code, in case the mail was a
virus, or an illegal relaying was attempted.
If the mail is acceptable, then they set the state to another special state,
e.g. ACCEPT.
It is not necessray to have a single processor, instead the whole spool
mechanism could be used - but without a que, and a persistent storage. This
concept may be extended to the RCPT command too.
What do you think about this concept? How difficult is to implement it?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: preprocessing after smtp DATA
Posted by Danny Angus <da...@apache.org>.
Sid,
I think the point is not that there is an argument against certain pre-processing activity during SMTP sessions, but that this pre-processing would be better to be limited to a specific set, and not be a pluggable interface.
There is some will to implement simple RFC oriented pre-processing, I can't remember exactly what was proposed, I'd be surprised if there isn't something on the wiki.
d.
> While this kind of test could be put into the
> message processor, it does not naturally fit there.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: preprocessing after smtp DATA
Posted by Sid Stuart <si...@weaselworks.com>.
Serge Knystautas wrote:
> 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
>> would
>> 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.
I have a couple of concerns with this argument. First off, I've run
several fairly large mail servers and have never seen connections
blocked due to load. So in my experience you are raising a issue that
does not occur in the majority of existing installations. The benefit of
providing a customisable solution is that it lets the end user decide,
based on their environment, whether the additional filtering is appropriate.
My second concern is the terminology is a little fuzzy. Saying "It makes
mail processing synchronous..." makes it sound like the whole message
processing function will be moved to the SMTP protocol sever. I don't
think mail processing should occur at that level (and I don't think you
do either). I do think a customizable mechanism should be available to
validate remote hosts. If the host fails validation, then messages from
it should be refused.
I have seen impressive results from the Exim connection filtering
mechanism that tests to see if the initiating host has an STMP server on
port 25. After moving from Sendmail to Exim, the spam level dropped
80-90% at the sites I support. The level of spam dropped so much, I
didn't even need to set up blackhole list filtering. (Alas, I no longer
know where to buy Viagra to increase my breast size and reduce my
mortgage payments.) While this kind of test could be put into the
message processor, it does not naturally fit there.
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: preprocessing after smtp DATA
Posted by Danny Angus <da...@apache.org>.
Joszef,
> 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.
My sugestion would be that helping to indetify and eliminate the bug might be a better use of your time in the long run.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: preprocessing after smtp DATA
Posted by Hontvari Jozsef <ho...@solware.com>.
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
emails.
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" <se...@lokitech.com>
To: "James Developers List" <ja...@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
would
> > 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
Re: preprocessing after smtp DATA
Posted by Serge Knystautas <se...@lokitech.com>.
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 would
> 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
Re: preprocessing after smtp DATA
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Hontvari Jozsef" <ho...@solware.com>
> Maybe a coincidence, but yesterday I received not less then 75 virus
emails.
> Most of them are simply trying to relay. (And the number doesn't include
the
> ones I immediately send to Null based on the subject.)
One thing that high volume sites like yahoo do is that they check for relay
in Handler itself. While it is not a general mechanism like having a
processor I think it would be worth while doing rcpt to check in handler.
This should filter away the bulk of your load. right ?
Also are you concerned with 75 'bad' emails in a day ? It does not seem too
much. fyi - my mail server classified 249 emails as spam yesterday and that
is low.
> Is there any idea when will 3.0 released? 1 month, 1 year?
I think it is far away. The main change is moving to a different repository
implementation and there has been limited activity on that front. I would
guess release is 6 months or so away.
Harmeet
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: preprocessing after smtp DATA
Posted by Hontvari Jozsef <ho...@solware.com>.
Maybe a coincidence, but yesterday I received not less then 75 virus emails.
Most of them are simply trying to relay. (And the number doesn't include the
ones I immediately send to Null based on the subject.)
(Actually I don't even know why I get these mails on my postmaster account,
this requires further investigation. I forward them to a bounce processor,
which notifies the sender, not the posatmaster. Only errors shoud go to the
posmaster - theoreticaly).
But even if it works correctly I already feel sorry for the innocents who
will get these unnecessary bounces.
What happened with Peter Goldstein?
Is there any idea when will 3.0 released? 1 month, 1 year?
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, April 20, 2003 12:47 AM
Subject: RE: preprocessing after smtp DATA
> I disagree with your assertion that James attracts viruses, etc. The only
> thing that it does do is not discard traffic early in the transaction.
> There is a plan to provide short cut termination within James v3. As far
as
> I know, the only implementation so far on that plan is in Peter
Goldstein's
> fork of James.
>
> Your idea might be an interesting suppliment, but it needs to be worked
out
> in further detail. Things that are not covered in your approach are
earlier
> termination related to the connecting IP, MAIL FROM, RCPT TO, or other
> commands. These are all in the shortcut filter approach for James v3.
The
> short cut approach allows returning the proper 4xx/5xx result code, along
> with the string, to the client. That is something to be considered for
the
> in-line processor proposal.
>
> Although it would need further fleshing out and discussion, it might be
> reasonable to define an in-line processor for the SMTP handler. The
result
> of that processor would normally set the mail state to the ROOT processor.
> I don't believe that I would go further than a single processor. That
> simplifies various implementation issues, and discourages putting more
than
> a minimum of work in-line.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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
RE: preprocessing after smtp DATA
Posted by "Noel J. Bergman" <no...@devtech.com>.
I disagree with your assertion that James attracts viruses, etc. The only
thing that it does do is not discard traffic early in the transaction.
There is a plan to provide short cut termination within James v3. As far as
I know, the only implementation so far on that plan is in Peter Goldstein's
fork of James.
Your idea might be an interesting suppliment, but it needs to be worked out
in further detail. Things that are not covered in your approach are earlier
termination related to the connecting IP, MAIL FROM, RCPT TO, or other
commands. These are all in the shortcut filter approach for James v3. The
short cut approach allows returning the proper 4xx/5xx result code, along
with the string, to the client. That is something to be considered for the
in-line processor proposal.
Although it would need further fleshing out and discussion, it might be
reasonable to define an in-line processor for the SMTP handler. The result
of that processor would normally set the mail state to the ROOT processor.
I don't believe that I would go further than a single processor. That
simplifies various implementation issues, and discourages putting more than
a minimum of work in-line.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org