On Friday 19 September 2003 02:37 pm, Chris Berry wrote: > From: Robin Lynn Frank <[EMAIL PROTECTED]> > > > > Well if he's running a server on dialup he's an moron, and if not then > > > >it's > > > > > irrelevant because it will be taken care of by his email provider's > > > >machine > > > > > before he logs in to download messages. > > > >Willie's business is in a remote region of Arizona, Montana or Idaho and > >they > >won't see even DSL there for a couple of years. Also, why is his provider > >supposed to take a beating for something neither he nor Willie are to > > blame for? > > Then he should use managed hosting for his server, such as rackspace and > serverbeach, or get a satellite link. Stupidity on the part of his admin > is not an excuse. > What a solution. That way his mail gets blocked because of all the RBLs that include rackspace's IP block.
> > >That's the best case scenario. Worst case is that he sends out > > > > > > >50,000 challenges. > > > > > > Personally I don't see that as a bad thing. > > > >If bandwidth were free and we had all the time in the world...maybe. > > The amount of bandwidth consumed by 50,000 challenge messages is trivial. > On my fractional T1 with a mere 768kb/s of bandwidth this would consume > about 50 seconds, and that's assuming that every joe job is to a valid > account which is highly unlikely, if it's not mailfront denies it for me. > > > > Software can't prevent ID 10 T errors. The problem here isn't C/R it's > > > >the > > > > > fact that he's being joe-jobbed, and that has nothing to do with TMDA. > > > >Actually, it does. TMDA needs to become joe-job aware > > I'm sure your recommendations on how to accomplish this would be > appreciated on the tmda-workers list, but honestly I'm not sure this is > TMDA's job. > How about per-domain rate limiting. At least that way, if 100 emails are received before the first confirm request expires, only one confirm request is sent, but all are held in the pending queue. > >and virus/worm/trojan/virus-bounce aware, as well. > > Now you're making it sound like MS software, what happened to "do one job > and do it well"? I prefer TMDA to stick to what it's good at. I use > ClamAV to solve this problem. > > >Or do you think sending any > >confirmation mail to anywhere other than where it originated, makes any > >sense > >at all? > > If you have a way to fix smtp to prevent spoofing, I'm sure we'd all like > to hear it. > > >I've use TMDA since 0.33 and wouldn't be without it. But spammers and > >virus > >writers are getting more sophisticated and we have to adapt to current > >conditions. > > I totally agree with that, no system is perfect, which is why I use > rblsmtpd + spamassassin(with bayes and vipul) + tmda for spam while using a > variety of other products for problems like email to invalid addresses, > executeable attachments, etc. On one side, there are the fanatics that inhabit spam-l and nanae, who consider any unsolicited mail to be spam, and here I am surprised to find people say, "as long as we don't get any spam, we don't care if we send confirmation requests to people who never mailed us to begin with." -- Robin Lynn Frank | Director of Operations | Paradigm-Omega, LLC Email acceptance policy: http://paradigm-omega.com/email_policy.html Our current s$p%a&m-t*r#a^p: [EMAIL PROTECTED]
pgp00000.pgp
Description: signature
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
