[SpamCop-List] Re: Bouncing spam

[Rascle]

Sorry I've been gone a few days and I'll try to get caught up in
the conversation as quick as I can.  A very unexpected death in 
the family a week ago last friday and a last minute business
trip the end of last week/beginning of this week has kept me away
from the newsgroups.

On Mon, 17 Feb 2003 13:23:30 -0800 in article <b2rjsp$la$1> Mike Easter wrote:
> Mike Easter wrote:
>> Not only is
>> the "bounce" term used rather loosely sometimes, but so is "reject".
>>
>> There is much interest in leaving spam at the sending server level
>> during mta-mta, of course,
> 
> For example, here's a clip from the commercial app CanIt, whose greatest
> claim to fame is rejection at mta-mta transaction.  Exactly what kind of
> "rejection" is it when the spam administrator checks the trap every so
> often?
> 
><snip>
> How CanIt Works
> 
> Every so often, a spam administrator checks the CanIt trap,
> releasing any false positives and rejecting actual spam. The
> next time the sending relay attempts to send the message,
> false positives are accepted for delivery while spam is
> refused with a permanent-failure indication. Until messages
> are released, they remain on the sender's server.
> CanIt's user interface allows the administrator to very
> efficiently make the spam/non-spam decision. A single
> person can de-spam an organization with hundreds of
> mailboxes in just 10-15 minutes per day.
></snip>
> 

>From reading this, to me it appears it works like this.  CanIT
monitors the incoming traffic and anything that appears to be
spam it instructs the MTA it is running with to send a temporary
reject (4xx status code).  Because of the 4xx status code the
sending MTA should automatically keep retrying to send the email
at its programmed interval.  The data(email) itself is stored
in the CanIT program for review of an admin in the meantime. If
the admin reviews the information and deterimes it not to be spam
then he can instruct CanIT to allow the message through.  Once he
does this, when the sending MTA retries sending the email in 
question CanIT then instructs the MTA to issue an Accept(2xx status
code) and it accepts the message for delivery to the mailbox.  If
on the other hand the admin determines it is spam he selects that
option in the CanIt software which then instructs the MTA to send
a perminant reject (5xx status code) when the sending MTA attempts
its next send.

the biggest problem I see with this "solution", if it works as
I interpret the paragraph above to say that it does, is that the
receiving MTA would have to keep receiving that same message from
its initial attempt to be sent until the admin either releases
or rejects it.  Which could be quite a number of times depending 
on the retry interval of the sending server and how often the admin
actually reviews the stored information.  And no matter what every
email that is accepted has to be sent at least twice.  Once to get
stored for review and once to actually accept it.
when the suspected spam if first recieved but the message is
still stored for admin review.  Because of the 4xx message the
sending MTA will retry sending the message at its programmed
interval(s).  In the meantime if the admin reviews the stored
data and decides a message that was caught is not spam he informs
the software (CanIt) which then instructs the MTA to accept
the email (2xx code) the next time the sending MTA tries.  Which
will work OK as long as the stored data is reviewed often enough
to have the sending MTA's not time out (which is typically a few
days).  If on the other hand the admin determines the stored
info to be spam, the admin informs CanIT which then instructs
the MTA to send a perminant reject (5xx code)


-- 
Rascle

I am not SPEWS, nor a SpamCop admin.  Just a user of both and I love what they do.
Please respond only to the newsgroups.  Do not email replies.  Thank you.