>>>>> "Narain" == Narain C Ramadass <[EMAIL PROTECTED]> writes:
Narain> Hi Guru's, I found the following quoted on an FAQ at:
Narain> http://www.tux.org/lkml/#s3 (Q11)
Narain> <SNIP> Another way to quickly get yourself removed is to
Narain> use program called "fetchmail" -- which in itself is not
Narain> all that bad, but apparently it is way too easy to get to
Narain> re-post email to addresses which the visible RFC 822
Narain> headers contain -- that is, what the original sender used,
Narain> like:
Narain> To: [EMAIL PROTECTED]
Narain> If you let that happen, you can be quite sure that your
Narain> subscription will be removed as soon as possibe </SNIP>
Narain> I could not make head or tail out of this??? Can someone
Narain> help me understand what this means???
OK. Will try.
Assume person X sends a mail to [EMAIL PROTECTED] Also
assume [EMAIL PROTECTED] is subscribed to linux-kernel. Further assume that
company xz.com runs fetchmail in multidrop mode to fetch all the mails
for its employees (which are accumulated in one mailbox on pop.xz.com).
In the beginning, vger.kernel.org contacts the MX for xz.com (which we
will assume, for simplicity's sake, is pop.xz.com) and delivers a
mail, which lands in Company xz.com's mailbox:
>From [EMAIL PROTECTED] Wed Nov 21 13:42:03 2001
Return-Path: <[EMAIL PROTECTED]>
Received: from vger.kernel.org (localhost.localdomain [127.0.0.1])
by pop.xz.com (8.11.2/8.11.2) with SMTP id fAL8B3g03468
for <[EMAIL PROTECTED]>; Wed, 21 Nov 2001 13:41:08 +0530
Message-Id: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
Date: Wed, 21 Nov 2001 13:41:08 +0530
To: [EMAIL PROTECTED]
Subject: module foo not working
The subject says it all
Now, xz.com runs fetchmail in multidrop mode, fetchmail correctly
figures out that [EMAIL PROTECTED] (From the Received: header, fetchmail uses
the first Received: header it finds) is the recipient of this mail and
delivers this mail to him.
So far, so good. Now let us say Z, who also works for xz.com,
subscribes to linux-kernel. Now, a follow-up to the above mail that
ends up in xz.com's mailbox looks like:
>From [EMAIL PROTECTED] Wed Nov 21 14:25:32 2001
Return-Path: <[EMAIL PROTECTED]>
Received: from vger.kernel.org (localhost.localdomain [127.0.0.1])
by pop.xz.com (8.11.2/8.11.2) with SMTP id fAL8t5g03726;
Wed, 21 Nov 2001 14:25:17 +0530
Message-Id: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
Date: Wed, 21 Nov 2001 14:25:17 +0530
To: [EMAIL PROTECTED]
Subject: module foo not working
Ignore the earlier mail - this was fixed
Again xz.com runs fetchmail - but now there is a difference; fetchmail
cannot determine the final recipient from the Received: header. So, it
looks for, in order, Resent-To:, Resent-CC:, Resent-BCC:, To:, Cc: and
Bcc:.
Here, fetchmail figures the final recipient address is the one in the
To: line, which is [EMAIL PROTECTED] So, it tries to
deliver the mail to linux-kernel@localhost - which is almost certain
to bounce - and fetchmail will send the mail back to the address in
the Return-Path:, which is [EMAIL PROTECTED]
The result of all this? Misery to the subscribers of the linux kernel
mailing list, and immediate suspension from lkml for Y and Z,
probably.
Hence, the warning in the lkml FAQ. Even ESR warns of potential
problems with the multidrop mode of fetchmail. It is to be used only
by a mail administrator who understands his job, RFC 821/822 and
sendmail (or whatever his choice of MTA is) thoroughly.
This is probably one of many ways one can misconfigure fetchmail wrt
mailing lists, and one that I had personally encountered. There might
be others, depending on your MTA.
Binand
_______________________________________________
linux-india-help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/linux-india-help
