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. That's up to you, but if your business model is based on email never being lost then I suggest you need to rethink it. Email is a best-effort service. It works reasonably well precisely because it's not designed to be ultra-reliable. An example: on our site, a university with about 20000 user accounts, eliminating greylisting would mean the collapse of our mail server (this isn't just a guess, it's based on real measurements) and consequent loss of many more emails than we might lose to false positives. There are no hard and fast rules here. You need to understand your specific needs and situation and act accordingly. poc
