On Fri, Feb 18, 2005 at 09:03:26AM -0500, Scot L. Harris wrote: > Ah, there were spammers on @home which resulted in whole sale black > listing. Now that does happen. Also a lot of email admins will block > dynamic IP address ranges. If you happen to be trying to run an email > server from a dynamic IP address (even if your assigned address has not > changed in years) a large part of the Internet will not accept SMTP > connections from you. In that case you just need to route your email > through your ISPs SMTP servers. Not much else you can do about that. The problem is I *am* routing my email through my ISPs SMTP server! I have complained loudly about this situation and eventually received a reply from @home that they had contacted SORBS and that the problem would be resolved. Wether or not the problem was resolved a whole block of @home IP addresses is listed (again) at SORBS. The dynamic IP addresses assigned to me are selected from this block. The IP address block does *not* contain the IP addresses of the @home servers, as far as I can see, but only of @home clients! I will complain forcefully about this again but in the mean time this "internet police" system is targeting a completely innocent person: me. With irritating consequences. > > My dynamic IP addresses are in this block which means I can't even send > > any mail to some mail servers and that I am greylisted by others > > (like RedHat). Look at the headers of my messages: > > X-RedHat-Blacklist-Warning & X-RedHat-Spam-Score. > Greylisting is very different from black listing. Greylisting simply > utilizes the standard RFC behavior for temporary failure codes to weed > out legit MTAs from bots. Worst case is that your message will sit in > your MTAs queue for at least the amount of time that the recipient MTA > has you greylisted. The remainder of the time your message is delayed > is based on your own MTA setup. > > And after the first message goes through subsequent messages from the > same user and IP address won't be greylisted at all until that tuple > expires. Most systems keep such data around for at least a week and > some set it for as much as 6 months. OK. Thanks for the clear explanation. I did not quite understand the difference between blacklisting and greylisting. But then, how did RedHat come to greylist (or blacklist) me? And why are both these terms mentioned in the mail comments and headers: "X-RedHat-Blacklist-Warning" and "host mx3.redhat.com[66.187.233.32] said: 451 4.7.1 greylisted" And even more to the point, how do I get off the RedHat (black)greylist? > > The actual delay is often *much* longer than 30 minutes due > > to all kinds of imponderables. > Not that many imponderables. Once the 30 minutes, as indicated in your > log file, expire the recipient MTA will accept your message and any > subsequent messages. Any additional delays are purely dependent on the > senders MTA setup and how busy that MTA is. Sendmail from my experience > generally retries a message several times in the first 10 to 15 > minutes. After that it delays longer and longer each time it is unable > to deliver the message. It will keep trying for about 3 days doing this > until it decides that it will never deliver that message. Standard > practice for many many years. Well I do not have a mail server on my PC but relay my email through my ISPs SMTP server and I am quite certain there are quite a few imponderables where @home is concerned. I am fairly certain that it takes more than 30 minutes before 'mail.home.nl' finally gets around to dealing with this delay queue or whatever. Thanks again for your reply and clear explanations. Alexander
