susan barnes wrote:
> --On Thursday, July 10, 2003 04:56:40 PM -0500 Daniel Liston <firstname.lastname@example.org> wrote:
>> It is local policy here, that anyone creating this kind of loop
>> be removed and blacklisted from subscribing to any of our lists
>> for a period of one year. Idle threat, considering how easy it
>> is to get and use a different address, but our point gets made.
Let me first add that when I said "here", I mean sonny.org, not
greatcircle.com. I have been supporting majordomo for so long
that people are assuming I am somehow associated with it's authors.
> Well, we did track the person down who started the loop and she was somewhat technically challenged, not doing it on purpose.
Ignorance is no excuse, as until they become educated, they are
likely doing the same stupid things to many others, not just you.
> (Given that we sent a few thousand emails to their info@ address on two separate occasions and nobody contacted us to find out what is going on, I would guess the above applies to the whole company/domain.)
The info@ address is only an RFC suggestion, not a requirement.
Even with that, the RFCs may be ignored. The info@ address could
easily be going to /dev/null. Since I do not operate a business,
my info@ address returns an error:User unknown. In MANY cases the
info@ address is an alias to a script that sends a canned message
with no checking of Return-Path, Precedence, or other anti-looping
> Just to clarify, the loop was started by a simple subscribe to majordomo, and the subsequent sending of help-files and autoresponder messages. So no mailinglist was involved at that point.
So the other side of the request had an auto-responder "while" the
address was being used interactively? No problem, until they
interact with automated processes. Then they become danerous.
>> Considering the query may not have even been from a subscriber,
>> this could be considered a weak DOS attack on your system. You
>> might consider leaving the user or their domain listed in your
>> access.db file.
> It is more like a DOS Attack on both of our systems.
> I have told the other side, to exclude majordomo, listserv etc. from autoresponder replys and set a reply-to Header.
What is the "other side" running as an autoresponder? Does the
autoresponder generate a new message, or include headers and body
of the message being responded to?
> However our majordomo does more or less the same thing, when triggerd this way. So a third party could deliberatly cause a DOS-Attack on two systems with one simple email.
> I am sure there are other people, who run autoresponders like this.
Majordomo has "some" safety built-in against these kind of mail loops
but with new software (some from programmers without a clue), it is
up to us to keep updating our protection and configurations.
No vacation, auto-reply, or intelligent autoresponder is supposed to
reply to a message with "Precedence: bulk" or "Precedence: junk" in
the headers. In this case, "list" should be synonymous with "bulk".
Nor are they supposed to respond to messages from Postmaster, MAILER,
MAILER-DAEMON, UUCP, or <anything>-REQUEST.
>> Take a look at your majordomo.cf file. Down at the bottom is a
>> majordomo_dont_reply variable that does what it's name says. You
>> might also want to consider a global_taboo_headers expression to
>> bounce null senders to the majordomo-owner without being responded
>> to. Using your own example, the expression would look like this;
>> /^Return-Path: <>/i
I see another (unique?) header to list in this case anyway;
> This has been suggested, but taboo-headers do only work if the mails go via resend to an actual mailinglist, or am I wrong?
I have to dig into the majordomo and majordomo.pl scripts to see if
this is true. I always "assumed" that GLOBAL taboo expressions in
the majordomo.cf file would work for mail coming to majordomo as well.
Otherwise you are correct in regards to individual listname.config
files use of the taboo_* settings depending on resend.
> I have added their address into $majordomo_dont_reply, but that is no general solution.
Does this mean you added "info" to the array? Here are some more that
I recommend majordomo should not respond to;
$majordomo_dont_reply = '(mailer-daemon|uucp|listserv|majordomo|listproc|autoreply|(post|host|web)master|usenet|news|ftp|www|noc|abuse|security|info|sales|support|marketing)\@';
Anything that is or can be considered a "Role" account or has the
potential to be automated should be listed in the dont_reply array.
>> I would really like to study a sample of the 3000 messages before
>> I could offer anything better. Are they all identical, with the
>> exception of date/time stamps?
> Yes they are just basically confirmation messages. They do not quote any part of the original mail.(see below, if you want one for yourself ask email@example.com).
> I am not really looking for a solution for this specific case, but to generally avoid such incidents. I think it would be much better if there was a hard limit on how many helpfiles majordomo would send to one specific address, after which any further requests are dropped for a while.
The above should help, but as long as majordomo is willing by design
to reply to "almost" anyone, the potential will always exist for a loop.
To make matters worse, when autoresponders do not include any of the
original headers, you can not even protect yourself with a customized
header like "X-Loop: firstname.lastname@example.org".
I hope my comments and suggestions shine some light on the situation,
> Regards and thanks for your input
> Susan Barnes
> This is the full autoresponder mail:
> (Return-Path is not empty because I have requested the autoreply to postmaster, the original envelope-sender was <>)
> Return-Path: <email@example.com.Uni-Koeln.DE>
> Received: from cyrus.rrz.uni-koeln.de ([unix socket])
> by cyrus.rrz.uni-koeln.de (Cyrus v2.1.12-Invoca-RPM-2.1.12-3) with LMTP; Thu, 10 Jul 2003 01:07:04 +0200
> X-Sieve: CMU Sieve 2.2
> Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [18.104.22.168])
> by cyrus.rrz.uni-koeln.de (8.12.9/8.12.8) with ESMTP id h69N735k024870
> (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
> Thu, 10 Jul 2003 01:07:03 +0200
> Received: from mail1.rrz.Uni-Koeln.DE (mail1.rrz.uni-koeln.de [22.214.171.124])
> by smtp-out.rrz.uni-koeln.de (8.12.9/8.12.8) with ESMTP id h69N726W024867;
> Thu, 10 Jul 2003 01:07:02 +0200
> Received: from lima01.sserv.de (lima01.sserv.de [126.96.36.199])
> by mail1.rrz.Uni-Koeln.DE (8.12.9/8.12.8) with ESMTP id h69N71Mp001594
> for <firstname.lastname@example.org>; Thu, 10 Jul 2003 01:07:01 +0200 (MEST)
> Received: from courier by lima01.sserv.de (Exim 3.22) with local
> for <email@example.com>
> id 19aO1Z-0000Pg-00; Thu, 10 Jul 2003 01:06:57 +0200
> From: firstname.lastname@example.org
> To: email@example.com
> Subject: Ihre Anfrage an das Hood.de Support-Team
> In-Reply-To: <E19aO0V-0000CKfirstname.lastname@example.org>
> X-Mail3Admin: Vacation-Autoreply
> Message-Id: <E19aO1Z-0000Pgemail@example.com>
> Sender: <firstname.lastname@example.org>
> Date: Thu, 10 Jul 2003 01:06:57 +0200