Re: Any benefit to changing the TEMPFAIL message?
Pieter Lange <[email protected]> Thu, 19 Jun 2008 19:25:14 +0200
| Newsgroups | gmane.mail.spam.greylist.user |
|---|---|
| Message-ID | <1213896314.6136.4.camel@comp-desktop> |
> The best you can do is if you know these specific servers are GOOD > people, but unfortunately, have broken SMTP software, and you don't have > an avenue of contact to get them to fix it or its legacy software and > the author no where to be found, then your only choice is to white list > them and not greylist them. dnswl.org maintains a decent whitelist thats excellent for greylisting usage. Saves me from a lot of (unnecessary) delays in delivery and also makes coping with big email farms (ie: google's mta pools) very easy. On Thu, 2008-06-19 at 12:26 -0400, Hector Santos wrote: > Albert E. Whale wrote: > > I have been using (and supporting) the GreyListing software (our own > > version of course), and was wondering if anyone had found any value with > > changing the standard TEMPFAIL message? > > > > The only reason I ask this is because some users, and also some Servers > > will send an email but never retry. > > Then they are not following the RFC x821 requirements. > > > While I understand that the users which send a message directly to us > > will see the TEMPFAIL message, they do not necessary understand that it > > means to retry it again shortly. > > The TEXT part is meaningless. It is the code 45x that triggers a > temporary negative response. 451 is an "attempt" to major clients be > more greylist aware, but it is the 45x response that makes it work in > general. Nothing after that number should be relied on to control > client behavior. > > > Additionally, the servers that do not resend (wow is this inane), I just > > do not know how to kick those servers hard enough. > > You can't. And you shouldn't worry about it. Its not your problem. And > in my view, the odds are fairly high these type of servers are more > 'spammer-type' than not. > > Thats the whole point behind greylisting. The BAD will not follow the > basic rules, the GOOD will. > > > Any Suggestions? > > The best you can do is if you know these specific servers are GOOD > people, but unfortunately, have broken SMTP software, and you don't have > an avenue of contact to get them to fix it or its legacy software and > the author no where to be found, then your only choice is to white list > them and not greylist them. >