Re: [OT] RFC 822?
On Sat, 16 Nov 2002 14:18:31 -0500
"Edward Guldemond" <thedebategod@yifan.net> 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" <thedebategod@yifan.net> 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
Reply to: