Malone notifications forge the address of the person who made the change

I don't think "forging" is right -- Malone is behaving much like mailing list software in this regard. When you send a mail to a mailing list, the mailing list manager re-sends it with your address. A Malone bug acts like a mailing list.

Malone sets the Reply-To header on such email so that other subscribers to the bug are encouraged to email the bug itself rather than discussing things in private email. I think the body of the message makes it clear that the email was sent by Malone on your behalf.

To my understanding, Malone treats email in much the same way as other bug tracking systems such as Debbugs.

Ok, I agree with Daf's comments re forging. I haven't used debbugs in a while, but I'll make a few points about why this behaviour wasn't expected and why it might be bad though.

It's unexpected because:
 1. Bugzilla doesn't do it; and
 1. it's unusual for something entered into a web form (other than a form on a web mail site) to "turn into" an email from me. It's not surprising when an email I sent (eg to a mailing list) looks like an email. I'm not used to it from web based bug trackers and other web forums.

On the undesirability, a bit of background. I'm involved in LinuxChix, which is primarily used by women who are only peripherally involved in FOSS development circles. A substantial proportion of them are very protective of their identities, particularly their email addresses but also their names (a small number have stalkers, lots are worred about spam and a larger number are worried about future employers googling them). This kind of environment has always led me to be a narky about applications leaking names and email addresses as if those things aren't precious to people. They're public property among FOSS developers, but not amongst users.

I'm going to turn on the "hide email address" option before I post this and see if it's still leaked in the email that goes out. (I registered with LP way back, I don't recall if it had that option then.)

Yup, if I turn on that "hide email address" option, my email address is still mailed out with the bug comments, at least to me.

I didn't realise there was a "conceal your identity" option in LP when I filed this bug. If the "mail out my comments using my name and address" feature can be made to respect these "use my display name, hide my email address" then my problems with the functionality would be gone.

FInal comment: it uses the display name fine, but it still uses my supposedly hidden email address.

On Thu, Feb 16, 2006 at 05:34:04PM -0000, Dafydd Harries wrote:
> I don't think "forging" is right -- Malone is behaving much like mailing
> list software in this regard. When you send a mail to a mailing list,
> the mailing list manager re-sends it with your address. A Malone bug
> acts like a mailing list.

I wouldn' say that it acts like a mailing list. A mailing list simply
re-sends the same message as it is, maybe adding a footer, while Malone
basically constructs a new email, using the same message id as the
received email. Some content is added, and some content is removed. And
the headers aren't preserved like in a mailing list.

On 15-Feb-06, at 8:12 PM, Mary Gardiner wrote:

> Public bug reported:
> https://launchpad.net/malone/bugs/31586
>
> Affects: launchpad (upstream)
> Severity: Normal
> Priority: (none set)
> Status: Unconfirmed
>
> Description:
> I have no interest in corresponding with fellow bug commenters in
> private email, I only wish to discuss a bug in the bug comments
> itself,
> not in private email. The fact that my comments arrive in other
> people's
> mail boxes with my full name and email address in them looking for all
> the world like I typed them in and emailed them out myself (unless one
> checks the headers) encourages people to mail me privately in response
> to the mail they think I sent them.

I agree with Mary, less so for the privacy concerns, more so for
having zero interest in getting a direct reply or, for that matter,
needing to directly reply.

Using the person who made the change in the From also has causes
confusion for each and every user that isn't subscribed to a
subscriber-only mailing list to which bugmail might get sent (bug 3003).

Cheers,

--
Brad Bollenbach

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 subscribe
 done

X Zerothly, I have prefixed all of the non-command lines in this email
X with an X to avoid Malone 34339. (My first attempt only prefixed
X the quotes from earlier LP mails, but the forbidden word `status'
X happened to wordwrap to the beginning of one of the lines in my list
X of bullet points at the bottom.)
X
X Firstly, I think that 29209 and 31586 are the same problem.
X
X Secondly, I have another nice example of a broken behaviour:
X
X I sent this message:
X
X From: Ian Jackson <email address hidden>
X To: <email address hidden>,
X <email address hidden>,
X <email address hidden>,
X <email address hidden>
X Subject: firefox bugfixes
X Date: Fri, 10 Mar 2006 16:28:08 +0000
X Message-ID: <email address hidden>
X
X -----BEGIN PGP SIGNED MESSAGE-----
X Hash: SHA1
X
X affects /distros/ubuntu/firefox
X status fixreleased
X done
X
X
X I believe I have fixed these bugs in dapper, [...]
X
X When these mails came back to me from Malone, they looked like this:
X
X From: Ian Jackson <email address hidden>
X Sender: <email address hidden>
X To: <email address hidden>
X Subject: [Bug 30603] "Comment" in .desktop file doubly utf-8 encoded
X Date: Fri, 10 Mar 2006 16:30:07 -0000
X Message-Id: <email address hidden>
X
X Public bug report changed:
X https://launchpad.net/malone/bugs/30603
X
X Comment:
X -----BEGIN PGP SIGNED MESSAGE-----
X Hash: SHA1
X
X affects /distros/ubuntu/firefox
X status fixreleased
X done
X
X
X I believe I have fixed these bugs in dapper, [...]
X
X plus
X
X From: Ian Jackson <email address hidden>
X Sender: <email address hidden>
X To: <email address hidden>
X Subject: [Bug 30603] "Comment" in .desktop file doubly utf-8 encoded
X Date: Fri, 10 Mar 2006 16:30:07 -0000
X Message-Id: <20060310163007.30701.37383.launchpad@<email address hidden>>
X
X Public bug report changed:
X https://launchpad.net/malone/bugs/30603
X
X Task: ubuntu firefox
X Status: Unconfirmed => Fix Released
X
X for each of the four bugs I was addressing.
X
X This is completely wrong in almost every possible respect ! Note how
X the mail that the subscribers of 30603 get is so garbled they can't
X see where else the mail went, nor the originally quoted email address
X of the person who sent it.
X
X
X These mails should have looked like this one mail:
X
X Resent-From: Ian Jackson <email address hidden>
X Resent-To: Ian Jackson <email address hidden> (subscriber to 30603),
X David Farning <....[etc]>
X [etc]
X Resent-Date: Fri, 10 Mar 2006 16:28:08 +0000
X Resent-Message-ID: <[something]@gangotri.ubuntu.com>
X Resent-Sender: Malone Bug Tracking System <email address hidden>
X Reply-To: <email address hidden>
X X-Malone-PR-Path: /malone/bugs/30603
X X-Malone-PR-Affects: /distros/ubuntu/firefox
X X-Loop: <email address hidden>
X From: Ian Jackson <email address hidden>
X To: <email address hidden>,
X ...

When composing a private e-mail message to someone involved with Ubuntu, I entered their name in the "To:" field, and my mail client auto-suggested an e-mail address for that person. However, it was actually the e-mail address of a Launchpad Answers question that the person had commented on, and not the person's real e-mail address. Fortunately I noticed this in time, but I wasn't pleased.

I think Launchpad bug reports should behave either like mailing lists, "From" the name and real address of the commenter and "Followup-To" the number and address of the bug report; or like Bugzilla, "From" the number and address of the bug report.

Please note that forging the sender is illegal in many countries.

Since Launchpad includes a Sender header to say the it's Launchpad sending the mail on behalf of the user in the body From, it's really not forgery. Also Mail From is not the user's address so I think that the current behavior (which may not be what it was when this bug was filed) is consistent with RFC 2821 and RFC 2822. It's also correct from an SPF (RFC 4408) and SenderID (RFC 4405 - 7, I think) perspective.

If anything, this plays havoc with spam filters. Which means I have to keep logging in to launchpad and check every bug, question, etc for added comments. An email directly from Launchpad would suffice.

When user turns on that "hide email address" option, launchpad should use <email address hidden> instead of the user's email address.
Now it's :

from : User <email address hidden>

it should be :

from : User (Via Launchpad Bug #) <#@bugs.launchpad.net>

This bug is more severe when someone reply quoting the previous email. The address is fully viewable to every logged in user. The address is hidden for non-logged in so couldn't launchpad hide the email address of people with privacy option turned on for every body, not only non-logged in? (Should I file a new bug for this ?)

It may make sense to fix this at the same time as bug 111147 and bug 138592.

I have to strongly disagree with the proposed "fix" in the linked branch. I consider it a regression.

On 9 June 2010 15:08, William Grant <email address hidden> wrote:
> I have to strongly disagree with the proposed "fix" in the linked
> branch. I consider it a regression.
>

Duly noted. What do you think would be a better solution? I'm assuming
that you're referring to what you say in comment #24 above about
wanting to send an out-of-bug reply, but I'd like some clarification.

William, I was referring to https://bugs.edge.launchpad.net/launchpad-foundations/+bug/111147/comments/24, sorry. E_TOO_MANY_TABS_OPEN.

My preferred solution would be to simply expand the "if not email_addresses" special case to also cover the case where the email addresses are private. That way the sane behaviour is retained for people who disclose their addresses.

On 9 June 2010 22:21, William Grant <email address hidden> wrote:
> My preferred solution would be to simply expand the "if not
> email_addresses" special case to also cover the case where the email
> addresses are private. That way the sane behaviour is retained for
> people who disclose their addresses.
>

Thanks for the clarification.

If you haven't seen it already I've opened up this particular can of
worms on the launchpad-dev mailing list. Luckily, this is the easy
part, so I'll change my branch tomorrow to behave in the way that you
describe, which seems to have a consensus.

FWIW, wgrant's proposal would lead me to mark my address private. I don't like a bit that Malone pretends it's me sending the mail.

Scott, didn't your comment #10 here suggest that you thought it was OK?

On 9 June 2010 23:57, Scott Kitterman <email address hidden> wrote:
> FWIW, wgrant's proposal would lead me to mark my address private. I
> don't like a bit that Malone pretends it's me sending the mail.

I appreciate your point (indeed I went down the route of just hiding
email addresses for all cases initially, which is what wgrant objected
to). The reason it looks like we're going to go down the route of only
using the bug address for cases where the user doesn't have a
preferred email address or has marked their address private is that
there's more of support for that approach on the launchpad-dev thread
(I'm ambivalent about it myself, which is why I took it to the list).

In 2008, I wasn't considering DKIM ADSP (since it didn't exist yet). The state of the art in email authentication has advanced since then. Sender ID is not really a concern anymore and ADSP keys of of the body from exclusively, so the presence of Sender isn't relevant.

I've unlinked the branch from this bug because at the moment it's not clear how (or if) we're going to fix it. There's an ongoing thread on the launchpad-dev mailing list if anybody wants to add their voice to the discussion: http://<email address hidden>/msg03483.html

We'll come back to this soon, but I think the best thing to do for now would be to fix bug 111147 (don't leak private email addresses) , which would pretty much be a case of implementing wgrant's solution above.

Recently, when a bug reporter was wondering why he did not receive the comment requesting info from a bug triager.

It turned out due to a strict spam rule. There seems to be an issue when someone has set their spam rule to " Message goes to spam if sender is not in address book. "

The following was the request from the reporter:
" <intrader> there should be a way for contributors to send message on behalf of launchpad, and then I would only have to have launchpad in address book "

Seems like a reasonable request, and we can probably expect more users with such strict spam rules.

[The triager's mail id was sent since his id was public.]

Apart from mpt's desire to mail people privately, I'm not sure what is blocking from hiding everyone's email id?
[oh i did see wgrant's objection, but not sure why it was objected?]

Why do we need to send it as from the commenter's email address, when it actually isnt being sent from that address?

I can confirm the sender email address spoofing, and have been actively observing this with mild annoyance for some time now.

I'm tempted to put this back to high: what sender to use is a Big Picture Question affecting all the mail LP sends where the initiating action is not LP itself.

Email authentication deployments are continuing to spread (as you know since LP now uses DKIM).

The current LP behavior of using the user's From address will increasingly cause deliverability problems.

Thats a very good point; man doing the high review is going to be a pain. I will put this one back to high.

I'm going to trim the focus on this bug on the email delivery aspects; wanting non-email subscriptions to bugs is already covered I think via the feature request for favourite bugs lists - an implementation that let you choose email/no-email on a per bug basis would essentially be providing in-webapp changes vs email changes.

Also, I *think* that now we no longer forge the users email address, but we do pretend to be them ('Joe Bloggs <email address hidden>') which is a bit terrible for auto managed address books.

We still impersonate (not forge) the email address if the user allows their email addresses to be visible.

Forge/Impersonate is a distinction without difference. The problem is the
same.

My email server has a DMARC policy that says "all the emails from arty.name should be sent from that IP, emails originating from other IPs are forged". When this policy is applied to the notification emails about my actions on Launchpad, these emails are considered spam. Even my own notifications end up in my spam folder.

I don't consider my email address private, but I don't like that people miss my bug reports or comments because of Launchpad using my email address as "From" in notifications.

Hi all,

This seems to be 11(!) years old, but the problem is still there. As a concrete example, I have a lot of emails from the launchpad which are sent with fields "From: XXX <email address hidden>" and "To: Myself <email address hidden>".

Of course in my inbox they end up as a phishing as "From: XXX <email address hidden>" is not a legitimate value. That makes us miss quite some of them. I think it still affects a lot of addresses for which mail servers are configured in a decent secure way.

Any chance of finally changing this and sending emails just from <email address hidden> (or anything what is not spoofed) ?

Thanks a lot,
Mateusz

This behaviour in Launchpad has begun to create backscatter rejections as DKIM-based spam filters at various levels are beginning to reject mails they deem to have been "forged" by LP.

Mailman has had a feature since at least the version in Xenial that munges the "From:" header, and the comment in the admin interface explains that in 2016+ this is the desired behaviour because of the DKIM/SPF problem. Quite a change from the days of SysAdmins tearing their beards out over "Reply-To:" munging, eh?

At any rate, speaking as someone who would have personally preferred to use the users' correct "From:" addresses everywhere, I have come to accept that in 2018 we should not be sending mail purporting to be from anyone else. This does not just affect malone, but may also extend out to Launchpad's use of mailman for team lists.

For reference, this came to Canonical IS's attention when a bug commenter in the community helpfully forwarded a bounce message to us to help us diagnose a possible mail problem within our systems.

A slightly more focused and recent discussion on DMARC compliance can be found at Bug #1589693.