Open
Bug 126151
Opened 23 years ago
Updated 11 years ago
Set From header to the user making the change
Categories
(Bugzilla :: Email Notifications, enhancement, P3)
Bugzilla
Email Notifications
Tracking
()
REOPENED
People
(Reporter: BenB, Unassigned)
References
Details
Attachments
(4 files, 2 obsolete files)
6.13 KB,
patch
|
justdave
:
review-
|
Details | Diff | Splinter Review |
1.44 KB,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
598 bytes,
patch
|
mkanat
:
review-
|
Details | Diff | Splinter Review |
979 bytes,
patch
|
mkanat
:
review-
|
Details | Diff | Splinter Review |
All bug notification I get from bugzilla.mozilla.org has
"From: bugzilla-daemon@mozilla.org". This means that I cannot see from the
header line in the thread pane, who made the comment / change. This means that I
might miss an important notification because of lot of spam in a certain bug
(and so I don't read the notifications or not timely).
Few people get bugzilla notifications from different bugzilla installations.
This means that the "Bug ..." in the subject line already tells me that it's
(most likely) something from a certain bugzilla installation. Otherwise, the
subject of the bug often gives hints about the product.
You could add, in any case, a new header would clearly marks the bugzilla
installation sending the notification. I think that "Resent-From" would be
appropriate.
That way, I can still filter bugzilla mail (even of a certain bugzilla
installation) unambigously, but have the original originator clearly visible.
I think there is nothing in the RFC822 specs that clearly says which option (the
current behaviour or the one I isuggest here) is right. If you consider bugzilla
just a web-based discussion forum, making the From header represent the bugzilla
user makes sense (and the Resent-From header represent the bugzilla software),
however. Esp. if you campare it to other, similar setups, e.g. the mail<->news
gateway at mozilla.org or hotmail (if a Hotmail user enters a mail in a
web-based form and sends it, Hotmail shows the user in the From line, not
"Hotmail-daemon" :) ).
Reporter | ||
Comment 1•23 years ago
|
||
> a new header would clearly marks the bugzilla installation sending the
> notification. I think that "Resent-From" would be appropriate.
"Sender" might be appropriate, too.
In fact, reading the spec, I think that the current use of From is wrong.
<quote src="RFC822">
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
4.4.2. SENDER / RESENT-SENDER
This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.
[...]
</quote>
<quote src="RFC822">
3.6.2. Originator fields
[...]
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field.
[...]
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message.
[...]
</quote>
Esp. the last sentence is quite clear, IMO. (enhancement -> normal)
Severity: enhancement → normal
Reporter | ||
Comment 2•23 years ago
|
||
> <quote src="RFC822">
The latter quote is from RFC 2822, not RFC 822.
Comment 3•23 years ago
|
||
Changing default owner of Email Notifications component to JayPee, a.k.a.
J. Paul Reed (preed@sigkill.com). Jake will be offline for a few months.
Assignee: jake → preed
Comment 4•23 years ago
|
||
Investigate for 2.18.
Severity: normal → enhancement
Priority: -- → P4
Target Milestone: --- → Bugzilla 2.18
Comment 5•23 years ago
|
||
Bug 137261 has a, in my opinion, better way of handling this: an X-Bugzilla-Who
header, which specifies the user who made the change to the bug.
I like this method better than tweaking the From header because then you can
sort your Bugzilla mail from different installations based upon the From header
(which you know won't change), and then dump all mail matching an X-Bugzilla-Who
of you in the trash or do whatever further sorting you'd like to on it based
upon this header.
But the From changing for every message... that's kinda scary.
Comment 6•23 years ago
|
||
I sort of agree with the doubts presented in comment 5, but on the other hand
the RFC citations in comment 1 are rather clearly against the current practice
(of course not against the X-Bugzilla-Who -method, but it won't resolve the RFC
conflict).
I think it's a good idea to implement this and forget the X-Bugzilla-Who thing.
Although the change will surely cause some grief, it simply makes sense to have
the From field contain the changer's name. It should be noted that this doesn't
really affect email filtering (apart from breaking existing rules); it is still
possible to differentiate bugmail from different Bz installations by using other
headers (possibly Sender).
Comment 7•22 years ago
|
||
Here's a patch that implements this feature. The From field of the mail
is set to the user doing the change (or reporting the bug in the first place).
The ReplyTo is still bugmail@, so no problems there.
I developed this patch for the KDE bugsystem, but I figured it might be
useful to others, seeing this report ;)
You need a similar change in the mail interface (contrib dir, 2 scripts), this
isn't
provided since I completely rewrote the mail interface (to remove "create new
bug",
but to add "close bug, reopen bug, etc." and merge with the "append a comment"
stuff,
improved too).
If anyone's interested, the script for that mail interface is in KDE's CVS, in
bugs/bugz/bug_email.pl
Comment 8•22 years ago
|
||
Wouldn't it be much easier to just support a %userid% (or sth similar) in the
newchangedemail as specified in the editparams.cgi
The default
From: bugzilla-daemon
would then just need to be changed to
From: %userid%
if maintainer would want this feature
Comment 10•21 years ago
|
||
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 11•21 years ago
|
||
> Wouldn't it be much easier to just support a %userid% (or sth similar) in the
> newchangedemail as specified in the editparams.cgi
>
When I was thinking about how to implement this here, this was the solution I
thought most elegent.
Then, while people decide how to interpret the RFCs (for default settings),
administrators can choose their own course.
Comment 12•21 years ago
|
||
(In reply to comment #7)
> Created an attachment (id=99539)
> Patch for the 'set the From header' feature
>
Just a quick comment:
In DBID_to_fullemail, you'll want to add the emailsuffix:
if (!defined $r || $r eq "") {
return $l . Param('emailsuffix');
} else {
return "$r <$l" . Param('emailsuffix') . ">";
}
Comment 13•20 years ago
|
||
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged
enhancement that hasn't already landed is being pushed out. If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Comment 14•20 years ago
|
||
It is somewhat saddening to see that the patch that I provided for this still
hasn't been applied :(
Our patched bugzilla has been using that patch for 2 years now, without any
trouble.
Comment 15•20 years ago
|
||
Comment on attachment 99539 [details] [diff] [review]
Patch for the 'set the From header' feature
(In reply to comment #14)
> It is somewhat saddening to see that the patch that I provided for this still
> hasn't been applied :(
Because there's a lot of sites that like it the way it is, and this patch
doesn't provide a way for the admin to choose.
The method suggested in comment 8 would be my prefered way of doing it.
Attachment #99539 -
Flags: review-
![]() |
||
Comment 17•19 years ago
|
||
*** Bug 300792 has been marked as a duplicate of this bug. ***
Comment 18•19 years ago
|
||
(In reply to comment #15)
> The method suggested in comment 8 would be my prefered way of doing it.
That's basically what I'd done (see the patch attached to duplicate bug 300792
above).
![]() |
||
Comment 19•19 years ago
|
||
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---
![]() |
||
Comment 20•19 years ago
|
||
*** Bug 318099 has been marked as a duplicate of this bug. ***
Comment 21•19 years ago
|
||
*** Bug 318238 has been marked as a duplicate of this bug. ***
Comment 22•19 years ago
|
||
Isn't this a duplicate of Bug 94293 ?
Comment 23•19 years ago
|
||
(In reply to comment #22)
> Isn't this a duplicate of Bug 94293 ?
Not really. Bug 94293 was about changing SMTP envelope sender to one set in From header of email parameters/templates. This bug is about allowing to change the From header or adding a separate header to specify the user that made the change.
Comment 24•19 years ago
|
||
*** Bug 337959 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•19 years ago
|
Assignee: nobody → email-notifications
Comment 25•19 years ago
|
||
(In reply to comment #7)
> Created an attachment (id=99539) [edit]
Hi David. If you would be willing to submit a replacement patch, I'm willing to review it for you.
Comment 26•19 years ago
|
||
Sorry I haven't touched the bugzilla code for 4 years now, and the only bugzilla installation I can hack hasn't been updated for ages so the patch would be useless.
After #8 I thought you were waiting for a better patch from me, but then #9
talked about related work going on anyway, which #18 confirmed.
You guys know the code and how it should be, please go ahead :)
Comment 27•19 years ago
|
||
Here's a patch based on the latest released 2.22 code that enables use of %fromwho% in your templates. It should be non-intrusive for those who don't want any part of this.
Comment 28•19 years ago
|
||
Comment 29•18 years ago
|
||
Comment on attachment 230664 [details] [diff] [review]
Add %fromwho% to 2.22
Patches need a review before they have any chance on getting committed. Kevin, you sounded interested in reviewing patchses for this bug?
Attachment #230664 -
Flags: review?(kevin.benton)
![]() |
||
Comment 30•18 years ago
|
||
Comment on attachment 230664 [details] [diff] [review]
Add %fromwho% to 2.22
We already have a X-Bugzilla-Who header with the name of the changer. I see no reason to have 2 fields with the same information. Moreover, I get emails from a half-dozen Bugzilla installations. I would hate to loose the ability to quickly see from which installation bugmail is coming.
Attachment #230664 -
Flags: review?(kevin.benton) → review-
![]() |
||
Comment 31•18 years ago
|
||
*** This bug has been marked as a duplicate of 137261 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 32•18 years ago
|
||
The main reason for this bug is to quickly see from the threadpane who made the comment/post, so that I decide whether I open the mail now. A comment from darin is more important than most chatter we see on b.m.o. That's why it's very important to have it in the actual From header. *This* is what this bug is about.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Updated•18 years ago
|
Attachment #230664 -
Flags: review- → review?(kevin.benton)
Reporter | ||
Comment 33•18 years ago
|
||
Let me emphasize that this is about quickly scanning your inbox/bugspam folder, for anything important, esp. when you don't have much time and opening every bgumail is not an option.
![]() |
||
Comment 34•18 years ago
|
||
Comment on attachment 230664 [details] [diff] [review]
Add %fromwho% to 2.22
Please do not overwrite my reviews.
This patch is wrong (you have to use the already existing 'changer' variable), and this patch doesn't apply cleanly on tip. We accept no feature change on Bugzilla 2.22 (nor on 3.0 as the code is frozen to prepare 3.0 RC1), so this patch won't be taken anyway.
Attachment #230664 -
Flags: review?(kevin.benton) → review-
Comment 35•18 years ago
|
||
This should be a user preference.
Comment 36•18 years ago
|
||
> This should be a user preference.
>
At some sites, this is an administrative setting rather than a user pref., especially when users are subscribed by mailing list. Making the From address be the updater 1) helps mail recipients immediately see who made the update and more importantly, 2) encourages off-line discussion without making clutter in a bug.
Comment 37•18 years ago
|
||
(In reply to comment #30)
> (From update of attachment 230664 [details] [diff] [review] [edit])
> We already have a X-Bugzilla-Who header with the name of the changer. I see no
> reason to have 2 fields with the same information. Moreover, I get emails from
> a half-dozen Bugzilla installations. I would hate to loose the ability to
> quickly see from which installation bugmail is coming.
>
(In reply to comment #34)
> (From update of attachment 230664 [details] [diff] [review] [edit])
> Please do not overwrite my reviews.
>
> This patch is wrong (you have to use the already existing 'changer' variable),
> and this patch doesn't apply cleanly on tip. We accept no feature change on
> Bugzilla 2.22 (nor on 3.0 as the code is frozen to prepare 3.0 RC1), so this
> patch won't be taken anyway.
>
Never mind - [% changer %] is the name of the person who changed the bug. It's possible to set the From address simply by adding
From: [% changer %]
Sender: bugzilla@...
...
to the newchangedmail param. This is already fixed unless I'm misreading what Ben is looking for. Ben - if you think this doesn't fix the problem, please add your reasoning behind why having [% changer %] available doesn't fix the issue for you.
LpSolit - nice catch. I missed that one.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 38•18 years ago
|
||
What bugzilla currently does *violates RFC822*. The default install of bugzilla (and the one at bugzilla.mozilla.org) should have the commiter name and email in From. Admins or better yet users should have to take special action to change it (because that would be a standard violation).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
![]() |
||
Comment 39•18 years ago
|
||
(In reply to comment #38)
> What bugzilla currently does *violates RFC822*.
No! You don't write an email. All you do is changing some bug fields and adding a comment. *Bugzilla* generates and writes the email based on your changes, not the user doing changes. So technically, we don't violate any RFC.
And assuming we later want to hide email addresses of Bugzilla users (which could be a good idea), this request would generate an empty From: field, which is illegal AFAIK.
Reporter | ||
Comment 40•18 years ago
|
||
> No! You don't write an email.
A comment is practically and technically an email by the commenter, at least for me as bugzilla mail reader. (And if you want to split hairs, Thunderbird also generates mail, albeit with less cruft.)
> hide email addresses of Bugzilla users
That's very important on the webpage (spam-harvesting), but I don't think spammers will cc themselves.
Comment 41•18 years ago
|
||
(In reply to comment #40)
> > No! You don't write an email.
>
> A comment is practically and technically an email by the commenter, at least
> for me as bugzilla mail reader. (And if you want to split hairs, Thunderbird
> also generates mail, albeit with less cruft.)
Quoting RFC 2822 3.6.2:
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
Person or system responsible. There is no violation. Technically a comment is not an email by the commenter but some text in a table. IMO referring to a RFC is splitting hairs.
The changer doesn't have to be responsible for all the comments that might be in that bugmail. There also doesn't have to be comments in there.
I might agree to having something like this by default, as long as all bounces (etc) go to the 'bugzilla-daemon' (means at least a different envelope from).
Comment 42•18 years ago
|
||
Not exactly a violation not to, but at least perfectly reasonable to say that the user is the author of the notification Bugzilla composes and sends.
Anyway, since both [% changer %] and [% changername %] is available in the template, and the templates are meant to be customized, this is IMHO as good as FIXED. But see bug 362289.
Reporter | ||
Comment 43•18 years ago
|
||
It may be fixed from the POV of a bugzilla admin, but not from my POV as a bugzilla *user*. I am still getting (IMHO) broken From headers from bugzilla.mozilla.org and other installations. As long as that is the case, this bug is not fixed.
Reporter | ||
Comment 44•18 years ago
|
||
Guys, I *need* this to be fixed, in the default install and on bugzilla.mozilla.org. I cannot process my bugspam efficiently without seeing right in the threadpane who made the comment, so I can look over 100 mails within *2 seconds* and pick the 3 important ones.
I still maintain that bugzilla violates RFC822.
Also, Jira (which we use at work) puts the commenter's realname in the From header. Which is *very* useful in practice.
*PLEASE* fix this.
Reporter | ||
Comment 45•18 years ago
|
||
Patch is probably something like:
BugMail.pm:
+ $substs{"fromwho"} = $values{'changername'} . " <" .$values{'changer'} . ">";
or MTA.pm:
+From: %changername% <%changer%>
Comment 46•17 years ago
|
||
Do people want to just change the From: line, or also the Reply-To: line? And would this be a user-preference or an administration preference?
Seems like this should be a user preference, and let the user decide if which of the four modes (From: and Reply-To:, all 4 combinations).
Comment 47•17 years ago
|
||
(In reply to comment #46)
> Do people want to just change the From: line, or also the Reply-To: line? And
> would this be a user-preference or an administration preference?
>
> Seems like this should be a user preference, and let the user decide if which
> of the four modes (From: and Reply-To:, all 4 combinations).
>
We have chosen to set just the from address of emails emitting from Bugzilla. To help identify emails from our Bugzilla installation, we also added "X-Bugzilla-Installation: UBTS" in the message header so our users can use their MUA filters to file Bugzilla messages appropriately. We've also chosen to add X-Bugzilla-Product and X-Bugzilla-Component in the message headers, further assisting those that want automatic filtering of emails. We don't set a reply-to address because we want users to be able to respond directly to each other without getting Bugzilla involved. If we used the email response system, this would tend to increase the already large amount of emails users get. From our perspective, this is and should remain an administrative option.
An upcoming customization we're making will allow users to specify a subset of the users associated with a bug that should be notified when a bug is updated. This will help keep minor updates from clogging up user in-boxes further. So, when a user reports they made a slight change that's kept in source control, and wants to note the bug as such, but really doesn't want to notify a long list of CC list members, there are times when it's appropriate that the notification be restricted to just a few individuals. This causes Bugzilla to log the update, to note the limited distribution, and yet the note is available to anyone who can view the bug so others can continue to monitor progress if desired.
Comment 48•17 years ago
|
||
We just want the From to be something like "Bugzilla Reply from Real Username <bugzilla-daemon@example.com>" so that it's easy to tell in a message index where in a conversation the message is and so that people can easily find replies from specific people by using their MUAs built in "sort by sender" facilities.
Comment 49•17 years ago
|
||
> an upcoming customization we're making will allow users to specify a subset of
> the users associated with a bug that should be notified when a bug is updated.
Kevin, is this something you'll be contributing to Bugzilla? Sounds like a great patch. My folks are getting frustrated with all large amount of emails, even after they've pared down the email preference settings.
> We just want the From to be something like "Bugzilla Reply from Real Username
> <bugzilla-daemon@example.com>"
I believe some email clients will complain if string name changes for the same email address? Seems like it should either hold the complete username info, or the bugzilla-daemon info.
Comment 50•17 years ago
|
||
> I believe some email clients will complain if string name changes for the same
> email address? Seems like it should either hold the complete username info, or
> the bugzilla-daemon info.
We've been doing this for a few years now and have never had a problem.
Comment 51•17 years ago
|
||
I think there's value in making this a user-preference instead of a administration option. In any case, who's going to decide (and approve) the interface approach?
Comment 52•17 years ago
|
||
It would probably a better idea to do something like the mailing lists do:
FROM: bugzilla-daemon@bugzilla.org ON BEHALF OF bug-changer@mysite.com
not sure how that equates to the message header. Then you can have both, filtering on stuff that comes from bugzilla, and an instantaneous view of the sender.
Comment 53•17 years ago
|
||
(In reply to comment #52)
> It would probably a better idea to do something like the mailing lists do:
>
> FROM: bugzilla-daemon@bugzilla.org ON BEHALF OF bug-changer@mysite.com
>
> not sure how that equates to the message header. Then you can have both,
> filtering on stuff that comes from bugzilla, and an instantaneous view of the
> sender.
>
We do that now with the following in the newchangedmail parameter which starts like this:
From: %changer%
Sender: bugzilla
Comment 54•16 years ago
|
||
At our installation, we use the newchangedmail.txt.tmpl:
From: "[% changername %]" [% Param('mailfrom') %]
However, this ran afoul of bug 452649 which munges some user's names.
We found it nice to leave the actual reply address the same, but make it easy to look and see who made the change.
Ciao!
Comment 55•16 years ago
|
||
The comment above to set From: to %changer% in the template works, but then the changer sees all the bounces, which is annoying. We went with putting the admin in the MAIL FROM, and the changer in the From: header. Bounces go to the admin, the 'reply' and 'reply to all' buttons in the MUA do what you'd expect. Requires the short patch to Mailer.pm above, and then this template change if you want to enable it:
From: [% changer %]
X-Bugzilla-Envelope-From: [% Param('mailfrom') %]
Attachment #366460 -
Flags: review?(mkanat)
Comment 56•16 years ago
|
||
What we should be doing is always using mailfrom as the MAIL FROM envelope sender.
Then the "Sender" and "Errors-To" and "Return-Path" headers can be the mailfrom. The changer can be the From, with their fullname if it exists.
Priority: P4 → P3
Comment 57•16 years ago
|
||
Comment on attachment 366460 [details] [diff] [review]
Hook in Mailer.pm to allow different envelope/From:
r- based on my above comment.
Attachment #366460 -
Flags: review?(mkanat) → review-
Comment 58•16 years ago
|
||
Also, include any template changes in your patch.
Comment 59•16 years ago
|
||
(In reply to comment #58)
> Also, include any template changes in your patch.
I didn't include the template changes because it's not really appropriate for everyone to split the envelope/from. That'll tick off most spam filters, for example. As for the other headers, if you split the from/envelope and leave the rest out, the mta will fill them in appropriately. (Most notably return-path will get set correctly.)
The method you describe may be more elegant for your code base, but is certainly beyond my "perl as a blunt instrument skills", given Mailer.pm's current interface. Thanks for looking.
Comment 61•16 years ago
|
||
This is to implement the suggestion in comment 54. It only adds the Changer name to the from field, but leaves the email address unchanged. We haven't seen any problems with unicode in names like someone described above, probably because we are using the 3.2 branch which seems to handle this situation properly.
Attachment #393418 -
Flags: review?(mkanat)
Reporter | ||
Comment 62•16 years ago
|
||
Keeping the bugzilla email address still violates the email standard. It will also thoroughly confuse Thunderbird 3, which doesn't show the email address, but allows to "star" people (put them in address book) with one click, and during display associates mails with address book entries based on email address etc.pp..
You can filter based on other headers, like Sender or Resent-From, which should be set to bugzilla@. You can even set a "Reply-To: noreply@bugzilla" header, if you want to prevent private replies. But From needs to be the author, with both clearname and email address.
Comment 63•15 years ago
|
||
Alright, this change is more in the spirit of the RFC <http://tools.ietf.org/html/rfc2822#section-3.6.2>, but changes the headers so mail still appears to come from the bug changer, while still basically preserving the existing functionality of all mail going to and from the mailfrom preference.
Attachment #393418 -
Attachment is obsolete: true
Attachment #396617 -
Flags: review?(LpSolit)
Attachment #393418 -
Flags: review?(mkanat)
Comment 64•15 years ago
|
||
(In reply to comment #63)
> Created an attachment (id=396617) [details]
> Change From to changer, and Sender/Reply-To to bugzilla mail
>
> Alright, this change is more in the spirit of the RFC
> <http://tools.ietf.org/html/rfc2822#section-3.6.2>, but changes the headers so
> mail still appears to come from the bug changer, while still basically
> preserving the existing functionality of all mail going to and from the
> mailfrom preference.
You really don't want to do this without my change above that let's you specify an alternate envelope FROM, else your users will get bounces whenever an address on the CC list bounces, because Mailer.pm takes the From header as the envelope sender, not the reply-to header.
Comment 65•15 years ago
|
||
Hey, I looked at the patch you sent to Mailer.pm (comment 55), but was a bit confused by the response. Was it rejected because of the conditional use of the X-Bugzilla-From header?
It seems like the way I'm doing it with From being the changer, and param(mailfrom) being the Sender and Reply-To, that the change to Mailer.pm to match would be to always use the Sender header as the envelope from. Or is it not desired to even use the headers to determine $from in Mailer.pm, and instead just hard code it to param(mailfrom)?
In addition, should the Errors-To and Return-Path headers be defined, along with Sender and Reply-To?
Comment 66•15 years ago
|
||
Yup, same change, but use a different header for the envelope in the case of your template change. Return-Path or Sender, most likely.
Comment 67•15 years ago
|
||
For reference, here's my template change to go along with the Mailer.pm change. I purposely used an X-header to let the MTA sort out the headers other than From. Ignore the subject change.
diff -r1.11 newchangedmail.txt.tmpl
22c22
< From: [% Param('mailfrom') %]
---
> From: [% changer %]
24c24,25
< Subject: [[% terms.Bug %] [%+ bugid %]] [% 'New: ' IF isnew %][%+ summary %]
---
> Subject: [[% comp %]/[%+ bugid %]] [% 'New: ' IF isnew %][%+ summary %]
> X-Bugzilla-Envelope-From: [% Param('mailfrom') %]
I also modified it to send out the bug emails with a shared envelope, so that 'reply to all' works. Great for an enterprise setting; awful for an internet product like the one we're typing at here. Let me know if you want the diff.
Comment 68•15 years ago
|
||
Ok, here is the change that also sets the sender envelope to the mailfrom parameter in Mailer.pm. I also added Return-Path and set that to the mailfrom parameter as well.
I understand this change to Mailer.pm is necessary to prevent bounces from going to the changer, rather than the mailfrom address. One thing I don't get is, is it even necessary to modify Mailer.pm with the from envelope if Return-Path is defined. It seems from reading RFC 2821 (third paragraph on pg. 51 "The primary purpose..." http://tools.ietf.org/html/rfc2821#page-51), that just including Return-Path in the headers should be enough to fix the bounce problem, and maybe the change to Mailer.pm isn't even necessary.
What do you guys think?
Attachment #396617 -
Attachment is obsolete: true
Attachment #396834 -
Flags: review?(mkanat)
Attachment #396617 -
Flags: review?(LpSolit)
Comment 69•15 years ago
|
||
Comment on attachment 396834 [details] [diff] [review]
Change From to changer, use Param('mailfrom') for Sender, Reply-To, Return-Path
Mmm, we don't want a Reply-To. Replies actually *should* go to the Changer, not the bugzilla-daemon address.
MessageToMTA sends a *lot* of messages, not just this one. You need to account for that.
Attachment #396834 -
Flags: review?(mkanat) → review-
Reporter | ||
Comment 70•15 years ago
|
||
(In reply to comment #69)
> Reply-To. Replies actually *should* go to the Changer
or to <do-not-reply@domain>, depending on policy. I don't care either way, but to keep current policy (currently, replies bounce), maybe you should use
"Reply-To: <do-not-reply@domain>" per default. Sites can remove that line, if they want to allow easy replies per email.
Comment 71•15 years ago
|
||
I thought we always wanted mail going through the bugzilla-daemon and never
directly from one user to another so that mail is sent by bugzilla based on
preferences. I can't think of a message that gets sent where we'd want the
response to go directly to the changer... How can I figure out all the types of
mail messages that need to be accounted for? All I can think of are changes to
bugs and whines, which as far as I know should go through bugzilla-daemon. Any
hints?
Is the issue that incoming mail is not set up to pipe to email_in.pl by
default? In that case, maybe what is needed is an admin setting for the
reply-to address. Empty leaves the reply-to field blank and replies go to the
changer, and anything else sets the reply-to header.
Comment 72•15 years ago
|
||
Actually, looking at the existing preference, it seems that the purpose of the mailfrom preference is to direct replies to the bugzilla-daemon, isn't it? If the preference is left empty, then maybe reply-to, sender, and return-path should be left out of the headers, but if it is defined, then those three headers should be set to mailfrom. I think perhaps I am misunderstanding the purpose of the mailfrom preference.
Comment 73•15 years ago
|
||
You don't really need to set anything except From and MAIL FROM. The rest will be inferred by the MTA. There are three scenarios:
1) From & MAIL FROM are set to bugzilla-daemon/param from. Bounces and replies go to the bz daemon/bit bucket.
2) From is the changer, MAIL FROM is bugzilla-daemon. Replies go to the changer, bounces to the daemon/bit bucket.
3) From & MAIL FROM are set to the changer. Replies AND bounces go to the changer.
#3 is annoying. #1 is the default behavior today. #2 is what I believe is being asked for here. Set the envelope from to param from, set the From header to the changer to achieve this. It requires a change to both Mailer.pm and the template file in order to be sane and not affect anything else (as I keep trying to say.) The other headers really don't matter much here.
Comment 74•15 years ago
|
||
I think I see what you mean, but I don't really get why, and I think I missed the intent of this bug. I've been trying to make essentially a cosmetic change so that bugmail appears to come from the changer, but the existing functionality is essentially unchanged like #1 (hence the reply-to header).
If the purpose of this bug is to change to scenario #2, and replies always go to the changer, then setting mailfrom to pipe to email_in.pl no longer works unless we introduce an additional paremeter for setting the reply-to address. What would be the workflow/settings for allowing people to respond and add comments via email if we were to change to scenario 2?
Comment 75•15 years ago
|
||
I did it by adding a global CC, which is already a parameter.
Comment 76•15 years ago
|
||
I'd think the expected receiver of a reply depends hugely on whether I've got email_in set up, doesn't it? Generally, I want people communicating via Bugzilla instead of e-mail, because if a question in Bugzilla is answered via e-mail, information is lost to others. This means I generally don't want a reply to a bugmail to reach a person.
Reporter | ||
Comment 77•15 years ago
|
||
Uri wrote:
> I think I missed the intent of this bug
No, you didn't, see comment 0 and comment 1.
And I really want to see it on bugzilla.mozilla.org, which doesn't have email_in.pl enabled, so please make it work well in both scenarios.
I think that's best achieved with setting "Reply-To: bugzilla-daemon" in both cases: sites without email_in.pl avoid communication bypassing bugzilla, by bouncing email replies, and sites with email_in.pl avoid that the changer gets the email reply twice (once directly and once via bugzilla).
Reporter | ||
Comment 78•15 years ago
|
||
(and
From: changer
Sender: bugzilla-daemon
MAIL-FROM bugzilla-daemon
of course - that is indeed what is being asked here)
Comment 79•15 years ago
|
||
(In reply to comment #77)
> I think that's best achieved with setting "Reply-To: bugzilla-daemon" in both
> cases: sites without email_in.pl avoid communication bypassing bugzilla, by
> bouncing email replies, and sites with email_in.pl avoid that the changer gets
> the email reply twice (once directly and once via bugzilla).
That's what I figured, which is why I set Reply-To to param(mailfrom) in all cases, though it seems that Max disagrees with that. I wouldn't mind making a larger change, and perhaps adding a preference to control this sort of thing, but I'm not exactly sure what is wanted or what would satisfy the most people. I think I need some guidance on a change like that from the maintainers.
![]() |
||
Comment 80•13 years ago
|
||
(In reply to Max Kanat-Alexander from comment #69)
> Mmm, we don't want a Reply-To. Replies actually *should* go to the Changer,
> not the bugzilla-daemon address.
Hum no. As Marc said in comment 76, replies must go to email_in.pl (if set up) so that the comment and other changes are applied to the bug itself. I personally dislike when a newbie replies to me privately. We shouldn't make this easier.
What several other Bugzilla installations do is to keep the mailfrom parameter for the From: header, but use the user real name. This is what attachment 393418 [details] [diff] [review] does.
Either that, or attachment 396617 [details] [diff] [review]. I see no other alternative.
Comment 81•13 years ago
|
||
There is an alternative, which involves giving people a parameter that says whether or not they want to accept replies via email_in. But barring that (because we're not going to do it right now) I would be in favor of setting the real name of the From to the user's realname and the email address to mailfrom.
Reporter | ||
Comment 82•13 years ago
|
||
mkanat, that's a violation of RFC 822/2822:
"In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply."
The From: address must match the realname. Anything else doesn't make sense anyways and will terribly confuse mailers like Thunderbird and others, which rightly assume that one email address belongs to one person and thus one realname.
Reporter | ||
Comment 83•13 years ago
|
||
s/one email address belongs to one person and thus one realname/a given email address has exactly one realname/
Comment 84•13 years ago
|
||
Some corporate spam filters (yes, my company's) will flag externally originating mail with an internal from address as spam. so, From: internal.mail@company will be rejected. The official response is "Use the On Behalf Of function".
In any case, the best bet is to use params and templates to control how mails are sent and who from. This will allow each system to pick its own methods. Obviously some run email_in and some do not. Some care about bounces, and some do not. Some companies don't like using Reply-To and some don't like using On Behalf Of.
Reporter | ||
Comment 85•13 years ago
|
||
> the best bet is to use params and templates to control how mails are sent
> and who from
Agreed.
And the default should follow the word and spirit of the RFC 822 standard.
Please also note comment 1.
Comment 86•13 years ago
|
||
(In reply to Ben Bucksch (:BenB) from comment #82)
> mkanat, that's a violation of RFC 822/2822:
> "In all cases, the "From:" field SHOULD NOT contain any mailbox that does
> not belong to the author(s) of the message.
Last time I looked, the definition of "mailbox" was the email address, not the real name.
But your point about Thunderbird is something to consider, yeah.
(In reply to miketosh from comment #84)
> The official response is "Use the On Behalf Of function".
If every MTA and MUA followed RFC 2822, there would be very straightforward ways of doing this; we'd separate out the From and Sender headers separately. But we don't want *any* situation in which the user who writes a comment in Bugzilla gets auto-response mailers sending them out-of-office notifications.
Reporter | ||
Comment 87•13 years ago
|
||
> Last time I looked, the definition of "mailbox" was the email address, not the real name.
Yes. And the spec says that the email address must match the author. The author of this bugzilla comment is me, "Ben Bucksch <ben.bucksch domain.invalid>" and the Sender is "Bugzilla at Mozilla.org <bugzilla-deamon@mozilla.org>".
Reporter | ||
Comment 88•13 years ago
|
||
> we don't want *any* situation in which the user who writes a comment in Bugzilla
> gets auto-response mailers sending them out-of-office notifications.
Well, I fear you can't satisfy that "*any* situation" without violating the RFC. But I think Reply-To: bugzilla-daemon@mozilla.org could get you close enough. Hopefully, most autoresponders would consider the Reply-To headers (or Sender). Some implementations will always be broken, yes, but a proper From: has high value, too.
Comment 89•13 years ago
|
||
(In reply to Ben Bucksch (:BenB) from comment #87)
> The author of this bugzilla comment is me, "Ben Bucksch <ben.bucksch
> domain.invalid>" and the Sender is "Bugzilla at Mozilla.org
> <bugzilla-deamon@mozilla.org>".
But the author of the email that gets sent out is not you. Don't forget that BugMail looks for anything that has changed since the value of lastdiffed, which could include other changes besides your own.
Reporter | ||
Comment 90•13 years ago
|
||
> But the author of the email that gets sent out is not you.
Frankly, I find that almost offending.
We had that. The spec says (see comment 1):
> From: … contains the identity of the person(s) who wished this message to be sent.
I write this comment and wish this bugmail to be sent. I am very much the author of this comment and any emails that are triggered as the result of it, no matter how much enhanced by the sending software. I am the mind writing the text. Just like you wrote the last comment and the last bugmail I got was a message from you, and I respond to you, not to bugzilla.
From is the author, the one writing the text, and Sender is the agent doing the sending process. For me, the spec has pretty much forseen and specced exactly this case.
Comment 91•13 years ago
|
||
That's fine. I'd be happy to test:
From: User
Sender: Bugzilla
Errors-To: Bugzilla
Reply-To: Bugzilla
Return-Path: Bugzilla
![]() |
||
Comment 92•13 years ago
|
||
(In reply to Max Kanat-Alexander from comment #91)
> Errors-To: Bugzilla
Errors-To is non-standard and discouraged by RFC 2076.
You need to log in
before you can comment on or make changes to this bug.
Description
•