Bugmail from address might be problematic for MLMs

[Brad Bollenbach]

The bugmail from address is bugid@..

The bugmail from address is bugid@... (the part after the @ is irrelevant.)

This may pose a problem if one of the contact email addresses for someone Cc'd on a bug is a mailing list. This will be most an issue when the MLM:

  * is configured to only accept mail from list subscribers (each and every bugid@ address will not be a list subscriber, of course!)

  * can't be configured to whitelist email regexes (e.g. \d+@...)

This is not necessarily a critical issue, but it does deserve some thinking about.

[Brad Bollenbach (bradb)]

On Wed, Jun 15, 2005 at 06:59:28PM -0000, Malone Bugtracker wrote:
> Comments and other information can be added to this bug at
> https://launchpad.ubuntu.com/malone/bugs/1034
>
> Title: Bugmail from address might be problematic for MLMs
> Comment: The bugmail from address is bugid@... (the part after the @ is irrelevant.)
>
> This may pose a problem if one of the contact email addresses for someone Cc'd on a bug is a mailing list. This will be most an issue when the MLM:
>
> * is configured to only accept mail from list subscribers (each and every bugid@ address will not be a list subscriber, of course!)
>
> * can't be configured to whitelist email regexes (e.g. \d+@...)

I'm just trying out the email UI, that's all.

Blah.

Cheers,

--
Brad Bollenbach

[Christian Reis (kiko)]

A couple of comments and questions here:

  - You say "the part after the @ is irrelevant" but you actually mean that "the part after the @ stays constant".

  - You could argue that each bug /should/ be accepted individually, since it may represent something which is on or off-topic for a list.

  - Does GNU Mailman allow whitelisting email regexes?

  - The trivial solution is having a single sender address (<email address hidden>). Doesn't that create its own set of serious problems?

  - Debbugs has the same problem, doesn't it?

[Stuart Bishop (stub)]

Mailman, and I suspect most other MLMs, allows a regexp on the sender whitelist. We are using this right now on the launchpad mailing list to allow bugmails to flow through.

[Stuart Bishop (stub)]

The issue *I* see with the bugid@.* style email addresses is that it will cause address books to bloat when they are setup to harvest email addresses from incoming messages, which is often the default.

Roundup solves this by having one inbound email address and using the In-Reply-To: header to identify the thread and thus the issue the message was intended for (and Subject: line sniffing as a backup).

We can either solve this the Roundup way or by setting the From: address to something constant, and the Reply-To: address to the bug id.

I don't know if the second solution addresses address book bloat.

The first solution should work, but is complicated by Mark's non-unique message-id fixes he needs to put in to support debbugs syncing. If we ensure that all messages that come from Malone have a unique message-id, then this will not be a problem.

(It does mean that we can't have debugs syncing generate comment emails to bug subscribers though unless we do message-id munging, in which case we can revert to having a UNIQUE message-id).

[Christian Reis (kiko)]

When you say "Roundup solves this by having one inbound email address" what do you mean by "inbound email address"? I'm asking because I am confused because the address is meant for both inbound and outbound communication (AFAICS).

Also, I repeat:

  - The trivial solution is having a single sender address (<email address hidden>). Doesn't that create its own set of serious problems?

  - Debbugs has the same problem, doesn't it?

[Stuart Bishop (stub)]

> When you say "Roundup solves this by having one inbound
> email address" what do you mean by "inbound email address"?

All email into a Roundup system is sent to a single email address. Roundup then files the messages appropriately by sniffing the In-Reply-To: header.

Email into Malone is currently sent to many addresses. Emails are filed appropriately by sniffing the To: header.

So Roundup has a single inbound email address. Malone has MAXINT inbound email addresses.

The trivial solution you talk about (which is what Roundup uses) only creates difficulties on our system because we are just removing the UNIQUE clause on Message.rfc822messageid so it is now trickier to determine the parent message purely using the in-reply-to: header.