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)

enhancement

Tracking

()

REOPENED

People

(Reporter: BenB, Unassigned)

References

Details

Attachments

(4 files, 2 obsolete files)

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" :) ).
> 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
> <quote src="RFC822"> The latter quote is from RFC 2822, not RFC 822.
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
Investigate for 2.18.
Severity: normal → enhancement
Priority: -- → P4
Target Milestone: --- → Bugzilla 2.18
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.
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).
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
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
By the way, bug 84876 has a built-in fix for this...
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
> 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.
(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') . ">"; }
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
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 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-
David, also note comment 12.
Assignee: preed → nobody
*** Bug 300792 has been marked as a duplicate of this bug. ***
(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).
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 → ---
*** Bug 318099 has been marked as a duplicate of this bug. ***
*** Bug 318238 has been marked as a duplicate of this bug. ***
Isn't this a duplicate of Bug 94293 ?
(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.
*** Bug 337959 has been marked as a duplicate of this bug. ***
QA Contact: mattyt-bugzilla → default-qa
Assignee: nobody → email-notifications
(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.
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 :)
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 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 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-
*** This bug has been marked as a duplicate of 137261 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
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 → ---
Attachment #230664 - Flags: review- → review?(kevin.benton)
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 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-
This should be a user preference.
> 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.
(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 ago18 years ago
Resolution: --- → WORKSFORME
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 → ---
(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.
> 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.
(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).
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.
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.
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.
Patch is probably something like: BugMail.pm: + $substs{"fromwho"} = $values{'changername'} . " <" .$values{'changer'} . ">"; or MTA.pm: +From: %changername% <%changer%>
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).
(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.
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.
> 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.
> 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.
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?
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.
(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
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!
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)
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 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-
Also, include any template changes in your patch.
(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.
Attached patch Add Changer name to From header (obsolete) — Splinter Review
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)
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.
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)
(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.
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?
Yup, same change, but use a different header for the envelope in the case of your template change. Return-Path or Sender, most likely.
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.
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 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-
(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.
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.
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.
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.
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?
I did it by adding a global CC, which is already a parameter.
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.
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).
(and From: changer Sender: bugzilla-daemon MAIL-FROM bugzilla-daemon of course - that is indeed what is being asked here)
(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.
(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.
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.
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.
s/one email address belongs to one person and thus one realname/a given email address has exactly one realname/
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.
> 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.
(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.
> 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>".
> 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.
(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.
> 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.
That's fine. I'd be happy to test: From: User Sender: Bugzilla Errors-To: Bugzilla Reply-To: Bugzilla Return-Path: Bugzilla
(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.

Attachment

General

Creator:
Created:
Updated:
Size: