[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ASRG] Re: Spam send/receive ratio



Snip

in a private reply to Alan Dekok I said...

> > I do not back away from my claims that mail volume is indeed a
> flawed method
> > for a receiving MTA to try and deduce whether a message is indeed spam.
> ...
> > As stated in a latter response, I *do* believe a mail volume spike is an
> > excellent method for a source MTA to trap a possibly compromised MUA.
>

Alan Responded...

>   Those two statements are mutually contradictory.  If an MTA can use
> volume to deal with spam when it comes from a local MUA, that same MTA
> can use volume to deal with spam when it comes from a remote MTA.  The
> two situations are nearly *identical* from a network perspective.

No they are not. Not by a long shot.

All you have to do is consider the possible implementations to see how
different they are.

For the recipient MTA to perform such tests you *MUST* implement some (huge)
mail monitoring service that monitors mail from every conceivable address.
A service such as AOL *may* be able to gather enough information by itself
to do a reasonable job as the recipient but smaller ISP's would have to rely
on a third party.

However the source MTA can record what its clients do with little problem.

If the recipient MTA was to refer back to the source MTA for that
information. Then it must trust the source MTA in the first place. So why
can't the source solve the problem without the need for the recipient to be
involved?

If the recipient MTA doesn't trust the source MTA it must use a trusted
third party.
Who is that going to be? Who pays for that system? and what prevents it from
being compromised?

AND finally after all this is implemented and running. IF we used recipient
mta's to do the job and possibly include my turing test to validate the
volumes. the poor sender would be inundated by emails from all these MTA's
trying to confirm if the volume was in fact "intended" This is as opposed to
just 1 from the source MTA.

The other choice is for the recipient MTA to drop the email from the source
as possible spam with no validation test. which is in opposition to the
proposal. which was to get confirmation that such volumes were in fact
intended.

If you think a recipient MTA volume check will work. go ahead and design a
system. just psuedo code it and we will see where we can go from there.

and finally a quote from Alan
> It's nice to wave your hands and say "it can be done".  It's even
> better to say *how*.  Everyone here knows we can do *something* to
> deal with spam.  The problem is deciding *what* and *how* and we do it.



Chris


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg