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

[Craig White]

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.
----
but your example completely misses the point.

the 'Junk' directory is a result of some type of agent parsing accepted
e-mail, scoring it and redirecting it based on a score.

The point of greylisting is always about (or virtually always...depends
upon various implementations anyway) sender/recipient/smtp server
'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
sender attempts redelivery.

http://www.greylisting.org/

I would suggest that rather than prove the argument about the problems
with greylisting, you have proven the opposite because if you can lop
approximately 70% of that junk mail off the top via greylisting, you
wouldn't have to look through so much 'junk' to find the false positives
that inevitably occur with any type of spam scoring system.

Craig