On Sat, 16 Nov 2002 14:18:31 -0500 "Edward Guldemond" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 16, 2002 at 12:00:17PM -0600, Gerald V. Livingston II > wrote:> On Sat, 16 Nov 2002 10:45:09 -0500 > > "Edward Guldemond" <[EMAIL PROTECTED]> wrote: > > > > > On Sat, Nov 16, 2002 at 02:48:53AM -0600, Gerald V. Livingston II > > > wrote: > > > > > > > Many ISP's do not bounce mail sent to addresses that do not > > > > exist because robot software can use that info to build a > > > > database of valid addresses at that domain for spamming > > > > purposes. > > > > > > Doesn't this break RFC 822? I would think that a mail server > > > > Yes, it breaks 822. But it's slowly becoming necessary for smaller > > operations. > > Get an MTA that sets limits to the ammount of mail that it > will process. For example, have it only process 50 mails in an hour > from each host and keep the rest in a queue. Don't bounce the other > addresses until later. Surely, if you're keeping tabs on a server, an > hour is more than adequate to block people out and clear out all of > the crap in the queue. This won't work on a large scale though, > ------------------------------------------ > Edward Guldemond It should work for small operations except small operations usually have fewer people to physically scan logs etc. I was just a user/file system admin and happened to nitice that /var/log was hogging space suddenly. That's the ONLY reason we spotted the bounced mails, sudden log file size increase. Setting up a queuing mail server only causes legitimate mail to be delayed indefinitely. If a robot is intent on scanning for valid addresses and chooses to search only for valid user names from 3 to 6 characters using the alphabet only, no numerals, underscores, or full-stops then we are looking at (3^26)+(4^26)+(5^26)+(6^26) or 172,076,350,440,456,172,706 messages in the queue. They can send a very short message in batches of 20 and send a WHOLE lot more than 50 per hour. At a processing time of 50 messages per hour it would take 3441527008809123454 hours or 143396958700380144 days or 392599476250185 YEARS to process those messages. Yes, most systems would die from lack of space before that happened, and most robots are intelligent enough to send only a few hundred or thousand per day. But, finding it happening in the logs, writing a filter to reject ALL mail from that host, then manually clearing the queue could take several days if it isn't caught quickly. This is one area where I think the ISP should be a bit more like the snail mail post office. You send the mail (regular letter). It should arrive at it's destination, but if it doesn't then we are not responsible and it is up to you and the intended recipient to determine that actual final delivery was made. We aren't going to watch your letter from the time it leaves your hands and then come back and tell you that it was lost somewhere between Albuquerque and Kalamazoo. We MIGHT return it to you, someday, if you provided a valid return address and the error was a bad delivery address entered at the origin. That way messages COULD be bounced, but the BOUNCE MESSAGES could be queued rather than the incoming spool. If the server is busy with higher priority tasks then the bounces just sit there. If some CPU cycles come free then a few of the queued bounces can be sent. G -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
