****Re: ****Re: [OT] HELP!!! mail attack

Da Rock rock_on_the_web at comcen.com.au
Fri Mar 28 23:00:43 UTC 2008


On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > > Craig White wrote:
> > > >
> > > 
> > > > 
> > > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it. 
> > > 
> > > 
> > > Okay, so Tim wasn't sure, but now we agree retrying, while it might be 
> > > good practice isn't essential.
> > ----
> > not essential in that the RFC does not say MUST
> > 
> > essential only if the intent was to surely deliver e-mail
> > ----
> > > 
> > > I've just done a "host -t mx" for several companies. Most have four mail 
> > > exchangers, one had a dozen. While those are for incoming email, it's 
> > > likely that they generally have a similar number for outgoing email. 
> > > Without information, I assume that to be so. In many cases they will be 
> > > the same machine.
> > > 
> > > I don't know what their retrying policies are, but I can imagine that 
> > > retrying might involve an attempt by each of several machines, each 
> > > getting a 4XY response.
> > > 
> > > It might be a lengthy delay, it might result in email getting returned 
> > > to sender.
> > > 
> > > Tim is right in his belief that greylisting can cause delivery problems. 
> > > You don't have to think it's as big a problem as he does, but I don't 
> > > criticise him for seeing it as a risk he doesn't want to take.
> > > 
> > > 
> > > Here is one list of recommended delays between retries:
> > > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > > 
> > > 
> > > The use of fake mx records suggested here looks enticing:
> > > http://wiki.apache.org/spamassassin/OtherTricks
> > > 
> > > I discontinued using a second mx because it seemed only to receive spam, 
> > > and senders _should_ retry if I'm not listening.
> > ----
> > the 'fake mx records' suggests the use of Temp Fail codes on the highest
> > fake MX
> > 
> > *** sigh *** 
> > 
> > I guess that if you think that NOT running greylisting means you get
> > delivery 100% of the time and running greylisting means that you only
> > get delivery 99.99% of the time (referring of course only to legitimate,
> > non-UBE e-mail) then you must be be indulging in willful sabotage and
> > not worthy of hire (Tim's words).
> > 
> > Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> > SMTP servers.
> > 
> > The alternative is to run user level spam filtering. I submit that it is
> > for most businesses, a stupid, wasteful, inefficient plan but I
> > acknowledge that ISP servers cannot necessarily adopt these aggressive
> > tactics.
> > 
> > Craig
> > 
> But is 99.99% delivery sufficient?  I receive more than 150 emails per
> day (ones that I am interested in), and every few days I need to receive
> certain emails about customer relations and ongoing projects.  99.99
> percent means I would miss one every 66 days.  If the one that I miss
> cost me a contract, it might not matter whether I received the rest or
> not.  Currently I have to parse through the junk mail locally and
> remotely about once a week.  the ISP junk folder often has more than
> 1200 emails in it.  THe local one about 30.  This adds about 1/2 day of
> overhead every week to recapture what should have come through.
> Personally I think the world needs to eliminate spam, or at least make
> every effort to seriously reduce it.
> 
> Regards,
> Les H
> 

Maybe we should send them all an email asking them nicely to stop? ;)

I understand your concern with the loss of important emails, but
consider this: Do you send and recieve faxes? If a fax cannot connect
with the recipient, it queues the call and tries again in a random time.

This is what happens with email. The server tries and if it can't
connect because of a specific error sent back, it'll queue the email and
try again later. Meanwhile, spam only gets attempted once and is
rejected.

So all your important emails WILL get through, because the service is
legitimate. Having seen this in my work in an ISP, as well as knowing
telecommunications technologies, lets me know that this does work. And
once your clients have sent you an email they get whitelisted, plus you
can add them manually as well. There are probably other methods as well
to filter clients through.

If you're concerned with efficiency, and valuable time, etc, then
something which is going to save you time IS going to save you money. If
you want better than 99.99% efficiency (with 6x 9s) then fiddle with
this technology to make it work better- filters are NOT going to be your
answer, just waste your time.




More information about the users mailing list