I have a few comments ...
"Karsten M. Self" <[EMAIL PROTECTED]> writes: > on Mon, Sep 22, 2003 at 02:51:45PM -0600, Jason R. Mastaler ([EMAIL PROTECTED]) > wrote: >> "Karsten M. Self" <[EMAIL PROTECTED]> writes: >> >> [ ... ] >> >> Second, why do you assume that nothing will be done at the MTA level >> to stop/reduce forged messages as they become more prevalent? > > Typical TMDA proponent tactic: tacitly acknowledge the problem, and > blame someone else. I'm not sure how you come to characterize that as "typical". But anyway, here's how I, a TMDA proponent who may or may not fit your definition of "typical", handle incoming email at my site, including at the MTA level: 1. And SMTP connection is made for incoming email. 2. MTA blacklists, RBL, and home-grown filtering procedures are used to reject certain emails immediately (see number 6, below). Certain other email is flagged with special headers as being "questionable". 3. SpamAssassin rejects its spam after that. 4. For users who do not elect to use TMDA, the email then gets delivered. 5. TMDA processing is done for those users who request it. Whitelisted email gets through; email blacklisted by the user is dropped; certain other mail with special headers that were put onto the message during earlier steps gets passed to the user; other email gets challenged. 6. My MTA is configured to monitor outgoing TMDA challenges. Any of those which cannot be delivered after a couple hours go through analysis (semi-automated at the moment). Any of these which cannot be delivered after a few hours have their sender addresses or possibly even their domains into one of my MTA blacklists. One of these blacklists is a home-grown "sender to specific user" blacklist, where a sender may or may not be rejected, based upon whom the mail is going to. I have a not-too-tight configuration of SpamAssassin, so that certain users don't complain. Even with that, the amount of spam that makes it to step 5 is less than 2 percent, the last time I measured this statistic. The only false positives so far that didn't make it past the SpamAssassin step occurred for a user who mis-configured his own SpamAssassin "user_prefs" file. Steps 1 through 4 have been successful so far at stopping floods of forged emails, thereby preventing the C/R problem that's been discussed here. > Why not apply the same fix to TMDA, which is actively generating the > spam, rather than offloading this task elsewhere? TMDA doesn't need to be the sole implementor of this, because other tools already do a good job for their pieces of the overall spam-reduction task. I see no reason to put all this into one software item (be it TMDA or whatever), if a mix of software like the one I mentioned above can do a good job. > [ ... ] > >> > I would find C-R systems such as TMDA far less objectionable if they >> > mandated C-R only as a last recourse: >> > >> > - Mail that isn't viral in origin. >> >> Install a virus checker. Demanding that TMDA handle virus detection >> makes even less sense than demanding that the MTAs build this in. > > The very simple expedient is to not challenge mail with executable > attachments. I've already posted a list of these to this list in a > related discussion on filtering executables. > >> Have you approached the MTA authors with this request yet? > > Again, whether I have or haven't doesn't address or absolve TMDA of > its obligations and faults. I'm not sure what "obligation" TMDA has to be one software package that does everything. MTA's are good for certain things; heuristic-based spam filters like SpamAssassin are good for other things; TMDA is good for still other things. I agree that certain emails should not get challenged. Whether TMDA is the sole agent that makes this determination, or whether another tool higher up in the chain does so is not important to me. I use SpamAssassin and my homegrown filtering to pre-reject quite a few messages before TMDA can even consider them. The "special headers" I refer to in step 5, above, are designed to make it easy for TMDA to pass some other emails onto the user, even though they are deemed as highly questionable. This includes certain emails with executable attachments. Even if a future version of TMDA has an "executable attachment" test, I would still probabably perform that determination higher up the chain, where it already is being done with a decent amount of efficiency and success. I don't think that TMDA is faulty simply because it doesn't do all of these steps by itsef. > [ ... ] -- Lloyd Zusman [EMAIL PROTECTED] _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
