Great Circle Associates Majordomo-Workers
(July 1998)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Stopping spaming modification to Majordomo
From: Norbert Bollow <nb @ thinkcoach . com>
Date: Sat, 1 Aug 1998 00:58:19 +0200
To: rsw @ Glue . umd . edu
Cc: majordomo-workers @ GreatCircle . COM
In-reply-to: <Pine.GSO.4.02.9807311303330.12004-100000@atlantis.csc.umd.edu>(rsw@Glue.umd.edu)
Prefer-language: de, en, fr

Randall S. Winchester <rsw@Glue.umd.edu> wrote:

> For example, our site has been hit by spam very heavily over the last few
> years, and have thus had a user community grateful for a reasonable spam
> blocking policy. However, when spam that we would normally block, like 
> bulls-eye, comes through other sites majordomo servers to our users, we
> would bounce it back. The user would then get dropped from the other sites
> list as a bad or undeliverable address.
> 
> It would be advantageous if majordomo could evaluate the smtp response codes
> and try to make a determination of the bounce. In other words, majordomo
> should allow some bounces to happen, and ignore them, or at least note them
> as not a bad address issue.

The bounce-handler which I've written for Majordomo2 isn't quite ready
for committing the code to the CVS tree, but I can assure you that it is
very careful not to remove addresses if only a few messages to a
subscribed address bounce.

However it would certainly be handy to have a method to tell from the
bounce when a message was message is rejected because it triggered the
spam filters and not because of delivery problems.

Of course the smtp response code is not in all cases available from the
bounce (we have no control over what MTA might be attempting to relay
the message to your host). However I would be willing to check incoming
bounces for the regular expression /554.*spam/i and in such a case have
much more patience with the address than otherwise.
 
(Note that RFC821 does not define any response code specifically for
"this message not accepted because it looks like spam", and according to
section 5.2.10 of RFC1123, "A receiver-SMTP SHOULD send only the reply
codes listed in section 4.2.2 of RFC-821". Hence the choice is limited
to one of the following:

         550 Requested action not taken: mailbox unavailable
            [E.g., mailbox not found, no access]
         551 User not local; please try <forward-path>
         552 Requested mail action aborted: exceeded storage allocation
         553 Requested action not taken: mailbox name not allowed
            [E.g., mailbox syntax incorrect]
         554 Transaction failed

Which one do you use? Something like "554 Message seems to be spam"
I'd suppose.)

-- NB.


References:
Indexed By Date Previous: Re: Stopping spaming modification to Majordomo
From: Dave Wolfe <dwolfe@risc.sps.mot.com>
Next: Re: Stopping spaming modification to Majordomo
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Indexed By Thread Previous: Re: Stopping spaming modification to Majordomo
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Next: Re: Stopping spaming modification to Majordomo
From: John R Levine <johnl@iecc.com>

Google
 
Search Internet Search www.greatcircle.com