Hello Mean,

On Wednesday, December 4, 2002 at 4:56:49 AM you [MD] wrote (at least
in part):

>> So I, as postmaster, would be receiving bounce messages from users who
>> have been spoofing my return address and routing? That'll get them
>> kicked off the system as fast as I can dig up my logs.

> With the number of bounced messages on the net, do you really think
> that the postmaster address is going to be monitored


Definitely yes! RFCs not only recommend, but require postmaster@ being
a active and read address per domain.

> and someone is going to make a living of studying bounced messages

Yes. It might be a male function in mail server if a message bounces.
With routine you get used to 'misaddressed' messages and learn to
recognize them quickly, but nevertheless every single mail in
postmasters mailbox is inspected by myself.

> and finding out if it was a spoofed email addy that caused it.

If I stumble over a mail that was bounced because "the address does
not exist" in the domain I'm responsible for I do have a look if this
is true. If the address does not exist further bounces, telling about
the same address are deleted.
If the address exists,  but the bounce says No I dig, WHY the message
was bounced.
Figuring out the spoofing is child's play, as the headers let easily
guess _who exactly_ sent the bounce.

> No one has taken Mailwasher to court...I guess when it comes to
> fighting spam, a little flexibility is expected.

I'm sorry for being forced to disillusionate you, but this "faking
bounces" ain't "fighting spam" even in the slightest way. It has
nothing in common with any successful "spam fighting technology", the
effect of bounces and faked bounces on amount of spam is near to zero,
not measurable.
If you want flexibility in fighting spam make use of RBLs and systems
like SpamAssassin (like!!! there might be others that work in a
similar fashion. I don't want to break it down on SA being "the
one"!).

Flexibility too is a patch I applied for example to qmail, that allows
to deny mails from and to addresses specified by regular expressions.
I do get a lot of spam on one domain I'm technically responsible for
on addresses like [EMAIL PROTECTED] and [EMAIL PROTECTED]
Denying mails to "support\d+@" on SMTP level decreases the amount a
lot. THAT is flexible, not "annoying innocent postmasters" (especially
the one from your own ISP!) by filling their inbox with those
ineffective doublebounces ('double' because in 99% your "bounce" will
bounce itself and the so called double bounce will end up in
postmasters mailbox).

I'm in a lucky position: if one of our customers would come to the
idea to use a system like Mailwasher for creating "faked bounces" I'd
phone him, please him to stop this stupid behavior and if he don't I'd
forward _every single_ double bounce to his mailboxes. ISP might not
be able to do so, because of to many different customers.

But there the problem is located: ISP can't direct the double bounces
to the originator and they can't fire all customers. So the result is:
postmaster@ _will_ become read less and lesser. You might think: who
cares? I, and many others, do. THIS is one of the _really few_
addresses you (yet) can be sure to reach somebody in case of a
technical problem with the MTA. As time goes by and this mailbox is
more and more unread or feeded to /dev/null it get's unusable. So
where to direct a problem to, if you're no customer, but only
recognize a problem between your MTA and the other one?

So all you reach with these dubious practice is lowering the quality
of technical background of the Internet:

1.) waste of bandwidth
    - I know you're bounces aren't big, but sum them _all_ up. It will
      make a significant amount of traffic.
2.) decrease of read postmaster mailboxes, which will earlier or later
    significantly cumber solving of problems, because of an artificial
    barrier for contacting a technical responsible.
-- 
Regards
Peter Palmreuther
(The Bat! v1.62 Beta/17 on Windows 2000 5.0 Build 2195 Service Pack 1)

Do not believe in miracles--rely on them.


________________________________________________
Current version is 1.61 | "Using TBUDL" information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Reply via email to