On Fri, 2005-02-18 at 06:14, Alexander Volovics wrote: > While I can understand that mail server admins choose tools > like greylisting to battle the spammers the 'innocent bystanders' > are often caught in the crossfire. > Greylisting IMHO has less collateral damage than RBLs, the message will get through eventually. And once it gets through the next message will not be greylisted until the tuple is expired. > About 2 years ago my email address 'awol@xxxxxxx' was hijacked by > spammers (presumably russians or east europeans) working the russian > market (for all sorts of completely unnecessary home-appliances). > This lasted about 3 months judging by the bounced mails I received. > Sounds like a joe job. Not much you can do about that. > As far as I know there is almost no direct action you can take to > stop this. And even if you use another email address your IP address > becomes (black)listed. > IP addresses are not tied to your email address. IP addresses get black listed because spam traps have seen actual email coming from that IP address. Forged from addresses are very common and are not, as far as I know, used in any kind of black list service. If it is then it is not a good black list to use as it will have way to many false positives. > The same happened recently to some other clients of my ISP @home. > Add to this the fact that some @home clients themselves contributed > small scale spam before they were stopped. > 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. But @home users, or any others, are not being black listed due to forged from addresses. Just does not work that way. > Of course these activities resulted in a (large) block of @home > IP addresses becoming SORBS listed, and recently relisted. > > 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. > This can result in substantial delays of my messages getting to the list > and then often not being read when mail is date sorted because of the > wrong date. > Wrong date? Nothing changes the dates on the messages. Personally I sort messages by received date instead of sent date. And threaded readers will still thread your message correctly. I am sure someone out there reads your messages. :) > Here is an example from my Mail Log: > host mx3.redhat.com[66.187.233.32] said: 451 4.7.1 greylisted > for 30 minutes and 0 seconds. (in reply to end of DATA command) > > 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. The only real problem that greylisting has is when dealing with large institutions that implement email server farms. In such cases it is possible for a message that is initially greylisted from server one to be passed on to server two for retransmission. This of course results in a new tuple for the second server. Depending on how many servers are in the farm, and there can be many, the message may not get retried from the same machine for some time which could hit the point that it is declared undeliverable. The solution used is to whitelist server farms. Most greylisting implementations have well known server farms listed in the initial packages for this reason. > I hope you can understand that I am not enamored of greylisting. > Hopefully you understand that greylisting and blacklisting are two entirely different things. Greylisting can be relatively transparent to all parties and the benefits far out weigh any real or perceived problems IMHO. And remember, email is not instant messaging. It was never intended to be. When systems work well users can communicate near real time, but the system was not intended for that use. As designed it is a store and forward architecture. And as long as we can keep the bulk of the spam in check it works quite well. Until we can track down the dolts that actually buy stuff from spam messages and take their computers and credit cards away the best we can do is try to keep the spam from flooding our inboxes. And from what I have seen so far greylisting blocks 99% of the spam being spewed across the Internet. And it uses very little resources. > Happy greylisting > > Alexander -- Scot L. Harris webid@xxxxxxxxxx tachyon emissions overloading the system
