On Fri, 2008-03-28 at 12:02 -0430, Patrick O'Callaghan wrote: > 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. ---- Oh oh...Tim thinks you are sabotaging your mail system by implementing greylisting and he would never hire you either. Craig -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
