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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
