Re: [mlmmj] undesired help emails

Re: [mlmmj] undesired help emails

[Ben Schmidt]

On 19/09/10 7:25 AM, Robin H. Johnson wrote:
> On Sun, Sep 19, 2010 at 02:27:01AM +0800, Thomas Goirand wrote:
>> One last thing, I still receive very often a mail from MLMMJ with in the
>> subject line: "Commands available for dtcdev@gplhost.sg", telling me how
>> to subscribe / unsubscribe, etc. Could it be possible that this was
>> generated by some spams, as I've configured my list to have a footer
>> with: "To unsubscribe, send a mail to dtcdev-unsubscribe@gplhost.sg" in
>> each email? I would really like to avoid receiving this, as it has been
>> annoying me for years...

I haven't experienced this myself.

> I think I asked about this a while ago, but didn't see any response.
> The command interface mails don't include 'Precedence: bulk' or anything
> else in the headers that mark them as mailing list messages, and they
> often triggered by spammers with forged addresses. I get dozens of them
> each day as the 'owner' for all of the @lists.gentoo.org instances.
>
> I've considered a patch to include control/customheaders in the bulk
> mails, but I only want some of the headers.
>
> [...]
>
> Maybe a custom control/commandcustomheaders, control/commanddelheaders?

I have implemented a feature which hasn't made it into hg yet as I
haven't documented it properly, to allow arbitrary headers to be added
to listtexts, so this would allow you to add the relevant headers. In a
future Mlmmj release, I'll probably try to include more sane and
standards-compliant/best-practice defaults for these, too. See

http://mlmmj.org/archive/mlmmj/2010-02/1666.html

Would this really help, though?

I don't think I understand sufficiently what is going on to properly
consider how to solve it yet. Is a spammer forging your address and
sending a message to listname+help@wherever.tld? This seems unlikely. Or
is Mlmmj responding to
listname+anything-it-doesnt-recognise@wherever.tld with the help email,
and we should have an option to turn that off and ignore such mails? Or
is a spammer forging the list address and sending to
listname+something@wherever.tld and thereby having a help email sent
back to you as owner somehow? In short, are we able to track down more
precisely what's going on?

And is this perhaps something that really should be solved at the MTA
level by doing more to ensure emails with forged addresses don't make it
to Mlmmj at all?

Anyone know if other MLMs suffer from this problem and/or what they do
to attempt to solve it?

Ben.

Re: [mlmmj] undesired help emails

[Robin H. Johnson]

(Sorry if Ben gets a dupe, I had to fix header as my MUA defaulted to
the old list address)

On Sun, Sep 19, 2010 at 10:55:35PM +1000, Ben Schmidt wrote:
> > Maybe a custom control/commandcustomheaders, control/commanddelheaders?
> I have implemented a feature which hasn't made it into hg yet as I
> haven't documented it properly, to allow arbitrary headers to be added
> to listtexts, so this would allow you to add the relevant headers. In a
> future Mlmmj release, I'll probably try to include more sane and
> standards-compliant/best-practice defaults for these, too. See
> http://mlmmj.org/archive/mlmmj/2010-02/1666.html
The downside of that solution is that I would need to build something to
allow easily updating listtexts for each list, with the per-list
headers (presently, since all the texts are identical, we have them
symlinked)

Ideal if we could combine both solutions maybe?
Worst case, I could build the listtexts w/ Make, per list.

> Would this really help, though?
> 
> I don't think I understand sufficiently what is going on to properly
> consider how to solve it yet. Is a spammer forging your address and
> sending a message to listname+help@wherever.tld? This seems unlikely. Or
> is Mlmmj responding to
> listname+anything-it-doesnt-recognise@wherever.tld with the help email,
> and we should have an option to turn that off and ignore such mails? Or
> is a spammer forging the list address and sending to
> listname+something@wherever.tld and thereby having a help email sent
> back to you as owner somehow? In short, are we able to track down more
> precisely what's going on?
Here's a capture of two variants:
1.
SMTP envelope:
MAIL FROM interposec0@rodarmer.com
RCPT TO gentoo-dev+owner@lists.gentoo.org
RCPT TO gentoo-java@lists.gentoo.org
RCPT TO gentoo-laptop+unsubscribe@lists.gentoo.org
RCPT TO gentoo-ppc-dev@lists.gentoo.org
RCPT TO gentoo-security@lists.gentoo.org
RCPT TO gentoo-user-ru+unsubscribe@lists.gentoo.org

Actual mail:
From: Mel Peterson <interposec0@rodarmer.com>
To: gentoo-laptop+unsubscribe@lists.gentoo.org

Effects:
- Two unsub failure messages to to interposec0@rodarmer.com, as the
  address is not subscribed to gentoo-laptop or gentoo-user-ru.
  If the from address was an autoresponder, I get a response because
  those mails do not have anything identifying them as listmail.
- The original spam was forwarded to owner of gentoo-dev (eg me).

2.
SMTP envelope:
MAIL FROM insultedj81@rjfruth.com
RCPT TO gentoo-desktop@lists.gentoo.org
RCPT TO gentoo-desktop-research@lists.gentoo.org
RCPT TO gentoo-desktop+subscribe@lists.gentoo.org
RCPT TO gentoo-dev@lists.gentoo.org
RCPT TO gentoo-devrel@lists.gentoo.org
RCPT TO gentoo-dev+subscribe@lists.gentoo.org
RCPT TO gentoo-doc-cvs@lists.gentoo.org
RCPT TO gentoo-doc-de+subscribe@lists.gentoo.org

Actual mail:
From: gentoo-desktop+owner@lists.gentoo.org
To: (all of the addresses in the envelope)

Effects:
- listowner gets confsub emails from 3 lists (gentoo-desktop, gentoo-doc-de,
  gentoo-dev)
  
> And is this perhaps something that really should be solved at the MTA
> level by doing more to ensure emails with forged addresses don't make it
> to Mlmmj at all?

> 
> Anyone know if other MLMs suffer from this problem and/or what they do
> to attempt to solve it?
mailman does from a brief check, and is mitigated by better headers on
the subconf/unsubconf/help.

mailman subconf:
========
Precedence: bulk
X-BeenThere: alsa-devel@alsa-project.org
X-Mailman-Version: 2.1.9
List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" <alsa-devel.alsa-project.org>
X-List-Administrivia: yes
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org

mailman listhelp:
========Precedence: bulk
X-BeenThere: coreutils-announce@gnu.org
X-Mailman-Version: 2.1.5
List-Id: announcements about the GNU coreutils <coreutils-announce.gnu.org>
X-List-Administrivia: yes
Sender: coreutils-announce-bounces+base-system=gentoo.org@gnu.org
Errors-To: coreutils-announce-bounces+base-system=gentoo.org@gnu.org

Interesting use of VERP in the last headers there.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [mlmmj] undesired help emails

[Ben Schmidt]

On 27/09/10 2:40 AM, Robin H. Johnson wrote:
> On Sun, Sep 19, 2010 at 10:55:35PM +1000, Ben Schmidt wrote:
>>> Maybe a custom control/commandcustomheaders, control/commanddelheaders?
>> I have implemented a feature which hasn't made it into hg yet as I
>> haven't documented it properly, to allow arbitrary headers to be added
>> to listtexts, so this would allow you to add the relevant headers. In a
>> future Mlmmj release, I'll probably try to include more sane and
>> standards-compliant/best-practice defaults for these, too. See
>> http://mlmmj.org/archive/mlmmj/2010-02/1666.html
> The downside of that solution is that I would need to build something to
> allow easily updating listtexts for each list, with the per-list
> headers (presently, since all the texts are identical, we have them
> symlinked)
>
> Ideal if we could combine both solutions maybe?
> Worst case, I could build the listtexts w/ Make, per list.

I'm not really against a tunable like this, though I am trying to 'cut
back' on tunables, particularly where they're ambiguous or conflict
(e.g. there are many that deal with access control, so it's hard to know
which might 'win' sometimes).

However, I still suspect this might be unnecessary. I have written
documentation now. Have a look at

http://mlmmj.org/hg/mlmmj/file/32d3f7e3b523/README.listtexts

Note that $whatever$ substitutions are supported in the headers. I think
this means you should be able to code pretty much whatever you want in a
list-independent way and continue to use shared listtexts.

Is there something I'm missing?

I'll look at your specific examples in more detail later. Thanks for
forwarding them.

Ben.

Re: [mlmmj] undesired help emails

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Mon, Sep 27, 2010 at 11:19:30AM +1000, Ben Schmidt wrote:
> http://mlmmj.org/hg/mlmmj/file/32d3f7e3b523/README.listtexts
> 
> Note that $whatever$ substitutions are supported in the headers. I think
> this means you should be able to code pretty much whatever you want in a
> list-independent way and continue to use shared listtexts.
I'm wondering if we added existing customheaders to administrative mails maybe,
since we can have the other per-listtext headers.

However, it would require an override order of:
mlmmj default
customheader
listtext

Which might introduce other bugs.

> Is there something I'm missing?
Reviewing that README.listtexts, the only header not covered by the above is
List-Id. All the rest are covered nicely by the new header functionality.

Examples from the Gentoo lists:
List-Id: Gentoo development announcement list <gentoo-dev-announce.gentoo.org>
List-Id: Gentoo Development-related help <gentoo-devhelp.gentoo.org>
List-Id: Gentoo Foundation Official Announcements <gentoo-foundation-announce.gentoo.org>
List-Id: Gentoo Graphical User Interfaces Project <gentoo-guis.gentoo.org>
List-Id: Gentoo Lisp mail <gentoo-lisp.gentoo.org>
List-Id: Gentoo Package Manager Specification discussions <gentoo-pms.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
List-Id: Gentoo SCM discussions <gentoo-scm.gentoo.org>
List-Id: Gentoo Greek Users <gentoo-user-el.gentoo.org>
List-Id: Gentoo Dutch Users <gentoo-user-nl.gentoo.org>
List-Id: Gentoo Turkish Users <gentoo-user-tr.gentoo.org>
List-Id: Gentoo VDR list <gentoo-vdr.gentoo.org>

> I'll look at your specific examples in more detail later. Thanks for
> forwarding them.
The bulk header should cut a lot of them.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: [mlmmj] undesired help emails

[Ben Schmidt]

On 27/09/10 11:36 AM, Robin H. Johnson wrote:
> On Mon, Sep 27, 2010 at 11:19:30AM +1000, Ben Schmidt wrote:
>> http://mlmmj.org/hg/mlmmj/file/32d3f7e3b523/README.listtexts
>>
>> Note that $whatever$ substitutions are supported in the headers. I think
>> this means you should be able to code pretty much whatever you want in a
>> list-independent way and continue to use shared listtexts.
> I'm wondering if we added existing customheaders to administrative mails maybe,
> since we can have the other per-listtext headers.
>
> However, it would require an override order of:
> mlmmj default
> customheader
> listtext
>
> Which might introduce other bugs.

Yeah, I think it probably would cause hassles, and it's particularly
awkward as there are occasionally supposed to be multiple headers of a
single type.

Don't throw the idea away, though.

Perhaps a variation where a postheaders tunable contained headers to be
added to list posts would be sensible. Then customheaders would be added
to all mails, but listtexts and postheaders would define headers at a
finer grain. The override order and behaviour would still have to be
carefully considered.

Any of these changes would be a behaviour disruption, and potentially
break compatibility, so would wait until a fairly major release to come
through.

>> Is there something I'm missing?
> Reviewing that README.listtexts, the only header not covered by the above is
> List-Id. All the rest are covered nicely by the new header functionality.
>
> Examples from the Gentoo lists:
> List-Id: Gentoo development announcement list<gentoo-dev-announce.gentoo.org>

Hmm. Yeah, OK.

I guess adding a listid tunable isn't out of the question, though if we
went down that road I'd want to carefully consider how to best structure
it for possible future use by mlmmj itself.

Another thought...What about a generic $tunableX$ substitution that
pulls the text out of the given tunable X? That would enable you to do
as much list-specific stuff as you wanted, and although it seems pretty
powerful and a candidate for exploitation, I don't think it would open
any security holes.

>> I'll look at your specific examples in more detail later. Thanks for
>> forwarding them.
> The bulk header should cut a lot of them.

Cool.

Ben.

Re: [mlmmj] undesired help emails

[Ben Schmidt]

> Perhaps a variation where a postheaders tunable contained headers to be
> added to list posts would be sensible. Then customheaders would be added
> to all mails, but listtexts and postheaders would define headers at a
> finer grain. The override order and behaviour would still have to be
> carefully considered.
>
> Any of these changes would be a behaviour disruption, and potentially
> break compatibility, so would wait until a fairly major release to come
> through.

I have filed this as a feature request to remind myself of it, for
consideration later as part of a more major update.

> I guess adding a listid tunable isn't out of the question, though if we
> went down that road I'd want to carefully consider how to best structure
> it for possible future use by mlmmj itself.

Ditto.

> Another thought...What about a generic $tunableX$ substitution that
> pulls the text out of the given tunable X? That would enable you to do
> as much list-specific stuff as you wanted, and although it seems pretty
> powerful and a candidate for exploitation, I don't think it would open
> any security holes.

Since this is a compatible change that shouldn't cause disruption, I
have implemented it, as a $controlN$ substitution. I have given it a
quick test and it seems to work.

Robin, might you be able to pull the current sources from hg and give it
a test? I believe the code there is fairly stable, though there are a
number of changes awaiting review, so I'm not yet wholly confident and
wouldn't recommend it for production use just yet.

Perhaps this is wishful thinking, but is there any chance you'd be able
to code-review the change, too? Are you a C-programmer? It is here:

http://mlmmj.org/hg/mlmmj/rev/ecb991e41a4c

>>> I'll look at your specific examples in more detail later. Thanks for
>>> forwarding them.
>> The bulk header should cut a lot of them.

I think let's focus on getting the relevant changes into production so
that you can test this, and report back if the problem still exists and
needs work.

Cheers,

Ben.

Re: [mlmmj] undesired help emails

[Ben Schmidt]

On 7/10/10 12:47 AM, Ben Schmidt wrote:
>> Perhaps a variation where a postheaders tunable contained headers to be
>> added to list posts would be sensible. Then customheaders would be added
>> to all mails, but listtexts and postheaders would define headers at a
>> finer grain. The override order and behaviour would still have to be
>> carefully considered.
>>
>> Any of these changes would be a behaviour disruption, and potentially
>> break compatibility, so would wait until a fairly major release to come
>> through.
>
> I have filed this as a feature request to remind myself of it, for
> consideration later as part of a more major update.
>
>> I guess adding a listid tunable isn't out of the question, though if we
>> went down that road I'd want to carefully consider how to best structure
>> it for possible future use by mlmmj itself.
>
> Ditto.
>
>> Another thought...What about a generic $tunableX$ substitution that
>> pulls the text out of the given tunable X? That would enable you to do
>> as much list-specific stuff as you wanted, and although it seems pretty
>> powerful and a candidate for exploitation, I don't think it would open
>> any security holes.
>
> Since this is a compatible change that shouldn't cause disruption, I
> have implemented it, as a $controlN$ substitution. I have given it a
> quick test and it seems to work.
>
> Robin, might you be able to pull the current sources from hg and give it
> a test? I believe the code there is fairly stable, though there are a
> number of changes awaiting review, so I'm not yet wholly confident and
> wouldn't recommend it for production use just yet.
>
> Perhaps this is wishful thinking, but is there any chance you'd be able
> to code-review the change, too? Are you a C-programmer? It is here:
>
> http://mlmmj.org/hg/mlmmj/rev/ecb991e41a4c

Missed a #include before. Added as a new change now.

http://mlmmj.org/hg/mlmmj/rev/bb803487199c

>>>> I'll look at your specific examples in more detail later. Thanks for
>>>> forwarding them.
>>> The bulk header should cut a lot of them.
>
> I think let's focus on getting the relevant changes into production so
> that you can test this, and report back if the problem still exists and
> needs work.
>
> Cheers,
>
> Ben.