135812 - Add a 'mailfrom' parameter to unify bugmail originating address

Status: RESOLVED FIXED

(Bugzilla :: Email Notifications, enhancement, P2)

Description

[John Vandenberg]

The mail templates introduced for the change of email address feature (bug
23067) are from 'bugzilla-admin-daemon' by default.  Each of these needs to be
modified by the maintainer to append a domain.

The following could be added to ease the maintainers job:
1) A global email header, which is included from any mail template.  This single
file could then be documented, and a simple check placed in checksetup.pl to
inform the maintainer that the mail header has not been customised.
2) A 'Bugzilla mail domain' param, which could then be automaticually appended
to 'bugzilla-admin-daemon'.

Comment 1

[Dave Miller [:justdave]]

the existing mail templates in the params ship without a domain on the headers.
 Sendmail will add a domain if you forget it.  Usually you only have to set the
domain if you need it to be something different than the local machine name.

Note that this is null and void if you use something besides /usr/bin/mail or
/usr/lib/sendmail to send the email, so the big email configuration patch which
is upcoming will probably screw this up.

I'd vote for a param for the domain to append to the email that's sent out.

Comment 2

[Dave Miller [:justdave]]

This will only be necessary when bug 84876 lands.  If bug 84876 doesn't make
2.16, this won't, either.

Comment 3

[Gervase Markham [:gerv]]

> I'd vote for a param for the domain to append to the email that's sent out.

Can't we use the defaultdomain thing we use for logins?

Gerv

Comment 4

[John Vandenberg]

I think you are refering to emailsuffix, which can not be used (at present) as
that is appended to every login, and could only be used on installations when
there are no logins with domain names.

Comment 5

[Gervase Markham [:gerv]]

Bug 84876 got pushed off, so this will be too.

Gerv

Comment 6

[John Vandenberg]

Attachment: Patch v.1

If the MTA config patch is not going to make it for 2.16, we could still make
the bugzilla emails easier to customise for 2.16.
This patch also changes whinemail's from header, bringing it into line with the
other from addresses.  I apologise if it is the way it is by design.  Comments
welcome.

Comment 7

[Joel Peshkin]

These unloved bugs have been sitting untouched since June 2002 or longer.  If
nobody does anything else to them, they certainly won't make 2.18
Retargetting to 2.20.  If you really plan to push them right now, you might pull
them back in.

Comment 8

[Cédric Caron]

I use an exchange as SMPT server and when I receive e-mail from my bugzilla 
server the from is [e-mail]

I tryed an other SMPT server (IMail from ipswitch) and this server refuse to 
relay messages without a full e-mail address in the from field.

Comment 9

[Cédric Caron]

Oups, i forgot the end of the command

looks like this bug need to be fixed to allow use on a Win32 server and 
probably some other "non sendmail" MTA.

Comment 10

[Marc Schumann [:Wurblzap]]

*** Bug 281353 has been marked as a duplicate of this bug. ***

Comment 11

[:glob ✱]

with bug 277437 landed, we need to add this parameter as the current default
won't work on most smtp servers, and it's not obvious where it needs to be changed.

Comment 12

[Marc Schumann [:Wurblzap]]

Comment on attachment 81483 [details] [diff] [review]
Patch v.1

Not surprisingly, after more than two years this doesn't apply to HEAD any
more.

John, are you still interested in this bug and in updating the patch? From
looking at it, I think it's the right way to go.

Comment 13

[Cédric Caron]

I manualy applied this patch to my bugzilla installation and it seems to work 
fine.

are you interested by a diff ?

Comment 14

[Marc Schumann [:Wurblzap]]

(In reply to comment #13)

Very much so :)

Comment 15

[Cédric Caron]

Attachment: Patch v.2

Comment 16

[Frédéric Buclin]

Comment on attachment 174805 [details] [diff] [review]
Patch v.2

The patch is bitrotten and does not apply at all. Please update your patch.

Comment 17

[Frédéric Buclin]

Comment on attachment 174805 [details] [diff] [review]
Patch v.2

Hummm... visually, I don't see how it could be bitrotten, but I cannot apply
the patch anyway. Removing my r-. Sorry Cedric! ;)

Comment 18

[Cédric Caron]

I created this patch under widnows maybe problem with CR\LF ?

Comment 19

[:glob ✱]

(In reply to comment #18)
> I created this patch under widnows maybe problem with CR\LF ?

fyi this isn't a problem -- cvs will issue a warning about trailing CR's but it
will still be able to apply the patch.

Comment 20

[Frédéric Buclin]

Comment on attachment 174805 [details] [diff] [review]
Patch v.2

I definitely cannot apply this patch. Try to resubmit a clean one. 

Pushing this patch out of my request list.

Comment 21

[Cédric Caron]

Attachment: Patch v.2bis

I generate a new diff.

Comment 22

[Marc Schumann [:Wurblzap]]

Comment on attachment 175926 [details] [diff] [review]
Patch v.2bis

There's a third address, namely the bugzilla-request-daemon (see
template/en/default/request/email.txt.tmpl).

Please include that, and it's r=wurblzap.

By the way, your patch had some strange file ending, so I got the message
"patch unexpectedly ends in middle of line". I could work around it by removing
the last line break. Did you perhaps do some copy-and-paste magic on it? If so,
then maybe you can try redirecting the diff output directly into a file.

Comment 23

[:glob ✱]

another approach would to to set the sender in MessageToMTA by setting
$headers->{From}.

then you're sure to get all instances, and the param would apply to upgraded
installs as well.

Comment 24

[Marc Schumann [:Wurblzap]]

(In reply to comment #23)

Wouldn't the result then be to have one sender address only?

Comment 25

[Cédric Caron]

(In reply to comment #22)
> There's a third address, namely the bugzilla-request-daemon (see

Is the description 

The email address of the Bugzilla request daemon

ok for this param ?

My englich is still in beta test ;-)

Comment 26

[Cédric Caron]

Attachment: Patch v.3

new patch with vith bugzilla-request-daemon added

Comment 27

[Marc Schumann [:Wurblzap]]

Comment on attachment 176397 [details] [diff] [review]
Patch v.3

Exactly :)

Comment 28

[Gervase Markham [:gerv]]

Hang on a minute... defining three email addresses seems like massive overkill.
Why do we need more than one, particularly given that you can't reply to any of
them?

Gerv

Comment 29

[Marc Schumann [:Wurblzap]]

(In reply to comment #28)
> Hang on a minute... defining three email addresses seems like massive overkill.
> Why do we need more than one, particularly given that you can't reply to any of
> them?

I always wondered why Bugzilla uses several addresses. Do we want to change this
now?

Comment 30

[Cédric Caron]

I agree with the one address option

just give me the variable name and the description and I will do the patch ;-)

Comment 31

[Gervase Markham [:gerv]]

Dave should make a quick ruling on whether we need more than one.

I would have thought "mailfrom" would be a good parameter name.

Gerv

Comment 32

[Myk Melez [:myk] [@mykmelez]]

Apologies, I approved this too soon, without letting Dave rule on the issue
brought up post-review.  Unapproving so that Dave can make a ruling.

Comment 33

[Dave Miller [:justdave]]

Comment on attachment 176397 [details] [diff] [review]
Patch v.3

Since the default values for these don't include an FQDN, the description
should explain that an FQDN is legal (and perhaps necessary in cases where the
MSA can't or doesn't figure it out for you).

Comment 34

[Dave Miller [:justdave]]

The address thing is a matter of filtering.  I filter my requests to a different
mailbox than my bugmail, and mail about password resets and so forth I'd rather
go to my inbox.  If we consolidate it to a single address then we need to come
up with an easy way for people to continue to do that filter separation.

Comment 35

[Cédric Caron]

(In reply to comment #33)
> (From update of attachment 176397 [details] [diff] [review] [edit])
> Since the default values for these don't include an FQDN, the description
> should explain that an FQDN is legal (and perhaps necessary in cases where 
the
> MSA can't or doesn't figure it out for you).

My english is still in beta test !!!

Who can write this comment for me ?

Comment 36

[Myk Melez [:myk] [@mykmelez]]

> I filter my requests to a different mailbox than my bugmail, and mail about
> password resets and so forth I'd rather go to my inbox.  If we consolidate it
> to a single address then we need to come up with an easy way for people
> to continue to do that filter separation.

We could add a custom mail header "X-Bugzilla-Type" and set it to either change,
admin, or request depending on the type of mail it is.  Then you could filter on
that header.  This makes more sense than overloading the sender address with
that information anyway.

Comment 37

[Cédric Caron]

(In reply to comment #36)
> We could add a custom mail header "X-Bugzilla-Type" and set it to either 
change,
> admin, or request depending on the type of mail it is.  Then you could 
filter on
> that header.  This makes more sense than overloading the sender address with
> that information anyway.

Not all the e-mail sowtware allows to filter e-mail based on a header filed.

Comment 38

[Marc Schumann [:Wurblzap]]

I think we can have one param 'mailfrom', maybe even without the addition of a
new header field X-Bugzilla-Type.

We'd use the param in other params (newchangedmail, passwordmail,
voteremovedmail) as %mailfrom%, and in templates as Param('mailfrom') -- as a
default. If a site needs (or wants) to have their mail come from specialized
sender addresses, it's a simple matter of tweaking newchangedmail, passwordmail
or voteremovedmail away from using %mailfrom%. The sender addresses of the
template-generated mails can be changed globally by the new mailfrom param, and
for individualizing these even further, template customization would be the
solution.

Comment 39

[Dave Miller [:justdave]]

Hmm, okay, I'll go for one address with the type header.  It'll break people,
but hey, it's a full-version upgrade anyway. :)  

Comment 40

[Cédric Caron]

Attachment: Patch v.4

Version with one e-mail address and X-Bugzilla-Type header type !!!

Comment 41

[:glob ✱]

since there's only one address now, how about fixing it in MessageToMTA (comment
#23) ?

my concern with fixing it in the templates is for upgraded installs.  unless
they modify the templates manually, the parameter does nothing.

Comment 42

[Cédric Caron]

(In reply to comment #41)
> since there's only one address now, how about fixing it in MessageToMTA 
(comment
> #23) ?

look like you forgot the messges send using the "maintainer" parameter as 
from...

Comment 43

[:glob ✱]

Comment on attachment 177044 [details] [diff] [review]
Patch v.4


>+   desc => 'The email address of the Bugzilla mail daemon.',
>+   type => 't',
>+   default => 'bugzilla-daemon'

how about

"The email address of the Bugzilla mail daemon.  Some email systems require
this to be a valid email address."


currently the patch doesn't fix upgraded installs, rendering the parameter
useless.  you should add code to Bugzilla::Config::UpdateParams() to change
existing parameters.

Comment 44

[:glob ✱]

> look like you forgot the messges send using the "maintainer" parameter as 
> from...

the big question:  why are emails sent from the whining system using maintainer
as the sender, while all other bugzilla emails don't?

Comment 45

[Cédric Caron]

(In reply to comment #43)
> currently the patch doesn't fix upgraded installs, rendering the parameter
> useless.  you should add code to Bugzilla::Config::UpdateParams() to change
> existing parameters.

with a code like this one to reset the e-mail messages ?

   if ( !exist $param{'mailfrom'} ) {
        delete $param{'passwordmail'};
        delete $param{'newchangedmail'};
        delete $param{'voteremovedmail'};
   }

Comment 46

[:glob ✱]

> with a code like this one to reset the e-mail messages ?
> 
>    if ( !exist $param{'mailfrom'} ) {
>         delete $param{'passwordmail'};
>         delete $param{'newchangedmail'};
>         delete $param{'voteremovedmail'};
>    }

no, that would reset any other modifications the admin may have made.

something like

  $param{'passwordmail'} =~ s/^From: bugzilla-daemon$/From: %mailfrom%/mi;
  $param{'passwordmail'} =~ s/\n\n/X-Bugzilla-Type: Bugzilla\n\n/;

that's off the top of my head, you'll have to test it.

Comment 47

[Cédric Caron]

Attachment: Patch v.5

update code added

Comment 48

[Marc Schumann [:Wurblzap]]

Comment on attachment 177090 [details] [diff] [review]
Patch v.5

This breaks test 9 because of the word "Bugzilla" appearing in templates. We
need to say [% terms.Bugzilla %] in templates. Alternatively, because we imho
want "Bugzilla" here even if somebody customized variables.none.tmpl, we might
go the way of
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/template/en/default/sea﷒0﷓ and use "B[%#%]ugzilla" or similar. Opinions?

(In reply to comment #44)
> the big question:  why are emails sent from the whining system using
> maintainer as the sender, while all other bugzilla emails don't?

I agree that that seems awkward -- Cedric, can you please have whine.pl use
Param('mailfrom') in a new patch?

(In reply to comment #39)
> Hmm, okay, I'll go for one address with the type header.  It'll break people,
> but hey, it's a full-version upgrade anyway. :)  

This won't break people because modifications to the sender address remain
intact.

(In reply to comment #41)
> since there's only one address now, how about fixing it in MessageToMTA
> (comment #23) ?

See comment 24 and comment 42 -- that'd reduce it to one address at all times,
removing the possibility to put something else than %mailfrom% into the mailing
params.

Comment 49

[Cédric Caron]

Attachment: Patch v.6

test 9 fixed, whine.pl modified...

Comment 50

[Marc Schumann [:Wurblzap]]

Comment on attachment 177126 [details] [diff] [review]
Patch v.6

This works well. Thank you Cedric :)

I'm sorry I didn't catch that in comment 48: I think password mails should have
X-Bugzilla-Type: Admin. This should imo be fixed on checkin (don't forget to
correct Config.pm, too), or in a new patch you can carry r+ forward to.

Comment 51

[Cédric Caron]

Attachment: Patch v.7

with passwordmail type set to Admin

Comment 52

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 177128 [details] [diff] [review]
Patch v.7

>+X-Bugzilla-Type: Bugzilla

"Bugzilla" is the wrong name for this value, since it conflates mail about bug
changes with the application as a whole.  This should be something like
"change" or "neworchanged".

Also, these values should be lower case per convention with similar sets of
values elsewhere in Bugzilla.  Capitalize proper nouns, like product names and
field titles; otherwise lower case, like keywords.

Comment 53

[Cédric Caron]

Which X-Bugzilla-Type value do I have to use for the folowing e-mail

parameter 'newchangedmail'
parameter 'voteremovedmail'

which are couretly using Bugzilla ?

Comment 54

[Cédric Caron]

(In reply to comment #52)
> Also, these values should be lower case per convention with similar sets of
> values elsewhere in Bugzilla.  Capitalize proper nouns, like product names 
and
> field titles; otherwise lower case, like keywords.

From ya mail I receive from Bugzille:

X-Bugzilla-Reason: AssignedTo CC
X-Bugzilla-Product: Bugzilla
X-Bugzilla-Component: Administration

How can I agree with you ;-)

Comment 55

[Myk Melez [:myk] [@mykmelez]]

> How can I agree with you ;-)

Easy.  The values of the product and component headers are proper nouns (the
names of the products and components).  Reason's values aren't proper nouns, but
its values all correspond to fields, so it usefully reuses their titles, which
are proper nouns.

The values of the type header, on the other hand, aren't proper nouns.  They
aren't nouns at all, in fact, but adjectives.  Consider the difference:

What product does this bug belong to?  It belongs to the Bugzilla product.
What kind of email is this?  It's an admin email.

Uses of key words elsewhere in Bugzilla agree.  For example, the Hardware and OS
fields contain capitalized proper nouns, and the Severity and Keywords (on b.m.o
anyway) fields contain lowercased modifiers.

Comment 56

[Cédric Caron]

Attachment: Patch v.8

Bugzilla type changes and all types in lower case.

Comment 57

[Dave Miller [:justdave]]

(In reply to comment #48)
> (In reply to comment #39)
> > Hmm, okay, I'll go for one address with the type header.  It'll break
> > people, but hey, it's a full-version upgrade anyway. :)  
> 
> This won't break people because modifications to the sender address remain
> intact.

It'll break end-users, not admins, because their existing mail filters will break.

>--- whine.pl	3 Mar 2005 07:19:09 -0000	1.10
>+++ whine.pl	11 Mar 2005 11:02:43 -0000
>@@ -102,11 +102,11 @@
> # Send whines from the maintainer address. It's not a good idea to use
> # the whine creator address because the admin can make more use of bounces and
> # other replies.
>-my $fromaddress = Param('maintainer');
>+my $fromaddress = Param('mailfrom');

You missed the comment above there where it says it uses the maintainer address.
 Make sure that gets fixed on checkin.

Comment 58

[Marc Schumann [:Wurblzap]]

Comment on attachment 177255 [details] [diff] [review]
Patch v.8

Granting r+ as per comment 57 and comparison with previous patch.

Comment 59

[Shane H. W. Travis]

I fixed the comment in whine.pl on checkin. 

Lotta work went into this patch - reviewers and patch author both. GJ everyone 
for staying on top if it and getting it done!

Checking in defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: 1.155; previous revision: 1.154
done
Checking in whine.pl;
/cvsroot/mozilla/webtools/bugzilla/whine.pl,v  <--  whine.pl
new revision: 1.11; previous revision: 1.10
done
Checking in Bugzilla/Config.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v  <--  Config.pm
new revision: 1.38; previous revision: 1.37
done
Checking in template/en/default/account/cancel-token.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/cancel-
token.txt.tmpl,v  <--  cancel-token.txt.tmpl
new revision: 1.7; previous revision: 1.6
done
Checking in template/en/default/account/email/change-new.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/change-
new.txt.tmpl,v  <--  change-new.txt.tmpl
new revision: 1.7; previous revision: 1.6
done
Checking in template/en/default/account/email/change-old.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/change-
old.txt.tmpl,v  <--  change-old.txt.tmpl
new revision: 1.8; previous revision: 1.7
done
Checking in template/en/default/account/password/forgotten-password.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/password/forgotte
n-password.txt.tmpl,v  <--  forgotten-password.txt.tmpl
new revision: 1.6; previous revision: 1.5
done
Checking in template/en/default/request/email.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/request/email.txt.tmpl,v 
 <--  email.txt.tmpl
new revision: 1.5; previous revision: 1.4
done
Checking in template/en/default/whine/multipart-mime.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/whine/multipart-
mime.txt.tmpl,v  <--  multipart-mime.txt.tmpl
new revision: 1.3; previous revision: 1.2
done

Comment 60

[Dave Miller [:justdave]]

This needs to get backed out, ASAP.  The parameter update code in this patch
wipes out the email template params on a new install.

Comment 61

[Frédéric Buclin]

Comment on attachment 177255 [details] [diff] [review]
Patch v.8

Per justdave's comment and per my own experience... :-/

Comment 62

[Jacob Steenhagen]

Attachment 177255 [details] [diff] has been backed out of the trunk.

Comment 63

[Cédric Caron]

(In reply to comment #60)
> This needs to get backed out, ASAP.  The parameter update code in this patch
> wipes out the email template params on a new install.

Oups...

How can I detect if this is an update or a new install ?

Comment 64

[Cédric Caron]

what about somthing like that

 if (!exists $param{'mailfrom'}) {
        if (exists $param{'passwordmail'}) {
            $param{'passwordmail'} =~ s/^From: bugzilla-daemon$/From: %
mailfrom%/mi;
            $param{'passwordmail'} =~ s/\n\n/\nX-Bugzilla-Type: admin\n\n/;
        }
        if (exists $param{'newchangedmail'}) {
            $param{'newchangedmail'} =~ s/^From: bugzilla-daemon$/From: %
mailfrom%/mi;
            $param{'newchangedmail'} =~ s/\n\n/\nX-Bugzilla-Type: 
newchanged\n\n/;
        }
        if (exists $param{'voteremovedmail'}) {
            $param{'voteremovedmail'} =~ s/^From: bugzilla-daemon$/From: %
mailfrom%/mi;
            $param{'voteremovedmail'} =~ s/\n\n/\nX-Bugzilla-Type: 
voteremoved\n\n/;
        }
        if (exists $param{'whinemail'}) {
            $param{'whinemail'} =~ s/^From: %maintainer%$/From: %mailfrom%/mi;
            $param{'whinemail'} =~ s/\n\n/\nX-Bugzilla-Type: whine\n\n/;
        }
    }

Comment 65

[Dave Miller [:justdave]]

I was kind of iffy about touching that to begin with, but didn't say anything
because I thought the regexp looked pretty safe... oops.  It's generally been
taboo to muck with the site's template params.  We usually relnote that kind of
stuff and advise people to make a copy of their existing param, click the reset
button next to the param to pick up the new defaults, then merge their
customized stuff back into it.

Comment 66

[Marc Schumann [:Wurblzap]]

I should've caught that :(

(In reply to comment #65)
So... Which way shall we go now -- Cedric's new update code or relnote?

Comment 67

[Dave Miller [:justdave]]

I'd say go with a relnote...  because if someone ever customizes their template
and removes this, it'll put it back next time they run checksetup.pl, which
wouldn't necessarily be a good thing.

Comment 68

[Marc Schumann [:Wurblzap]]

(In reply to comment #67)
> I'd say go with a relnote...  because if someone ever customizes their template
> and removes this, it'll put it back next time they run checksetup.pl, which
> wouldn't necessarily be a good thing.

The |if (!exists $param{'mailfrom'})| check would prevent that.
Still relnote?

Comment 69

[Stephen Lee]

This would still change the whinemails. Previously they had been coming from 
Param('maintainer'), which should be a valid email address. They would now 
attempt to come from Param('mailfrom') which definitely is not.

Result: whine.pl always dies after upgrade when previously it may have been 
working.


Any site which has ever had any of the From: addresses changed from the default 
will need to use the relnote route anyway, so IMHO it might as well use relnote 
for everybody.

Comment 70

[Cédric Caron]

Attachment: Patch v.9

patch without the update code

Comment 71

[Cédric Caron]

Attachment: Patch v.9 part 2

update code

Comment 72

[Marc Schumann [:Wurblzap]]

Comment on attachment 177852 [details] [diff] [review]
Patch v.9 part 2

Asking for second-review on the update part of the patch as per comment 67,
comment 68 and comment 69.

Comment 73

[Dave Miller [:justdave]]

*** Bug 257015 has been marked as a duplicate of this bug. ***

Comment 74

[Jacob Steenhagen]

*** Bug 289252 has been marked as a duplicate of this bug. ***

Comment 75

[Jacob Steenhagen]

The bug that was just duped against this one (bug 289252) describes a problem
for people who updated while this was checked in and have since updated again
after it was backed out. This only effects people who are using CVS versions,
but it would be nice to have fixed in our final release IMHO.

Comment 76

[Myk Melez [:myk] [@mykmelez]]

"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave

Comment 77

[Marc Schumann [:Wurblzap]]

*** Bug 293552 has been marked as a duplicate of this bug. ***

Comment 78

[Marc Schumann [:Wurblzap]]

This is *really* close to getting in (that's me thinking potential unrotting won't be too hard). Requesting blocking2.22.

Comment 79

[Dave Miller [:justdave]]

Sorry but this is very clearly a new feature, so it doesn't qualify for the branch.  You can already do this now, you just have to do it in several places.  All this would gain people is a little convenience.

Comment 80

[Frédéric Buclin]

*** Bug 320017 has been marked as a duplicate of this bug. ***

Comment 81

[Marc Schumann [:Wurblzap]]

*** Bug 337989 has been marked as a duplicate of this bug. ***

Comment 82

[Martijn Ras]

(In reply to comment #79)
> Sorry but this is very clearly a new feature, so it doesn't qualify for the
> branch.  You can already do this now, you just have to do it in several places.
>  All this would gain people is a little convenience.
> 
This would not simply be a little convenient, it's ridiculous to have to dive into the code and replace hardcoded default-addresses. If you make this a setting, with "bugzilla-daemon" being the default value. So you don't change anything for people for which this is fine, while really helping those people that, for whatever reason, can not use the default entry.

I sure won't like to having to patch in several places after every update and would really be helped if this was in the settings. In my situation i simply am not allowed to run an emailserver, use one specific mailserver and make do with existing accounts, in fact i should be glad i've been allowed to set up a Bugzilla at all.

Comment 83

[timeless]

wait a second. i use gmail, and i don't think i can filter on header. i also use a bunch of other broken apps which don't really like filtering on header. 

i also am not the admin of bmo or any other bugzilla i currently use, which means i don't control my own destiny. the claim that people who care about what the senders should be are in control of it is very bogus.

if you're going to do this, i expect to see howtos for the following email clients:
netscape 4
eudora
mail.app
seamonkey
thunderbird
microsoft internet mail and news
outlook express
outlook
gmail
yahoo mail
hotmail
pine
mutt
chandler
grendel

if you are unable to provide instructions for all of these mail clients then you should wait until you are able to. *grumble*

for the record:
Search results for:"X-Bugzilla-Reason: QAcontact"  Report SpamDelete
Refresh
1 - 8 of 8 

That's my gmail account. I can assure you I watch dozens of qa contacts. I should not be forced to figure out how to work around people messing up a working bugzilla installation.

Comment 84

[Kevin Benton]

I'm curious to see how justdave feels about this patch since it's not clear from the comments and there is a pending review for attachment 177852 [details] [diff] [review].

Comment 85

[Frédéric Buclin]

Comment on attachment 177852 [details] [diff] [review]
Patch v.9 part 2

Most email params have been converted to templates. This patch is no longer correct. The last remaining one is "newchangedmail".

Comment 86

[Frédéric Buclin]

Comment on attachment 177851 [details] [diff] [review]
Patch v.9

defparams.pl no longer exists. All params have been moved to Bugzilla/Config/*.pm.

Comment 87

[Cédric Caron]

This bugs Depends on bug 275636. But I can generate a new patch at any time.

Comment 88

[Olav Vitters]

*** Bug 344141 has been marked as a duplicate of this bug. ***

Comment 89

[miketosh]

Could a variable, like %login%, be used to force NEW/CHANGED emails to come from the account that submits the change?  AT least as a customizable option?

Comment 90

[Cédric Caron]

Attachment: Patch v.10

the last blocking bug is now fixed :-)

Comment 91

[Frédéric Buclin]

Comment on attachment 233637 [details] [diff] [review]
Patch v.10

>Index: Bugzilla/Config/Core.pm

>   {
>+   name => 'mailfrom',
>+   type => 't',
>+   default => 'bugzilla-daemon'
>+  },

Put email related stuff into MTA.pm and mta.html.tmpl. Else the patch looks good (at first glance).

Comment 92

[Cédric Caron]

Attachment: Patch v.11

Ready for V.12 ;-)

Comment 93

[Frédéric Buclin]

Comment on attachment 234522 [details] [diff] [review]
Patch v.11

Bitrot due to the checkin of bug 87795. email/password.txt.tmpl no longer exists and account/email/request-new.txt.tmpl is new. Sorry for that. :-/

Comment 94

[Cédric Caron]

Attachment: Patch V.12

The last one ?

Comment 95

[Cédric Caron]

Attachment: Patch V.13

No...

Comment 96

[Frédéric Buclin]

Comment on attachment 234625 [details] [diff] [review]
Patch V.13

>Index: Bugzilla/Config/MTA.pm

>   my @param_list = (
>   {
>+   name => 'mailfrom',
>+   type => 't',
>+   default => 'bugzilla-daemon'
>+  },
>+
>+  {
>    name => 'mail_delivery_method',

Nit: I think we should display mail_delivery_method first. This parameter is more important than mailfrom IMO.



>Index: template/en/default/admin/params/mta.html.tmpl

>+  mailfrom => "The email address of the Bugzilla mail daemon.  Some email systems " _
>+              "require this to be a valid email address.",

Bugzilla must be written $terms.Bugzilla.


>Index: template/en/default/email/newchangedmail.txt.tmpl

>+X-Bugzilla-Type: newchanged

Nit: we could find a type name which is a bit more meaningful. Why not [% terms.Bugs %]?


Also, you forgot to fix the "Form:" field in email/sudo.txt.tmpl.

Else your patch looks good and works correctly.

Comment 97

[Frédéric Buclin]

Cedric, could you update your patch asap? We freeze code for 3.0 in 2 weeks.

Comment 98

[Cédric Caron]

Attachment: Patch V.14

After some very buzy weeks imam back with a new version of this patch ;-)

I didn't change the X-Bugzilla-Type: in newchangedmail.txt.tmpl to terms.Bugs this value can contains caracters not allowed in a mail header.

I used admin for X-Bugzilla-Type in sudo.txt.tmpl but if somone have a beter idea ...

Comment 99

[Frédéric Buclin]

Comment on attachment 242662 [details] [diff] [review]
Patch V.14

putting this patch in my radar

Comment 100

[Frédéric Buclin]

Comment on attachment 242662 [details] [diff] [review]
Patch V.14

Works fine. r=LpSolit

Comment 101

[Frédéric Buclin]

Checking in whine.pl;
/cvsroot/mozilla/webtools/bugzilla/whine.pl,v  <--  whine.pl
new revision: 1.31; previous revision: 1.30
done
Checking in Bugzilla/Config/MTA.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/MTA.pm,v  <--  MTA.pm
new revision: 1.11; previous revision: 1.10
done
Checking in template/en/default/account/cancel-token.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/cancel-token.txt.tmpl,v  <--  cancel-token.txt.tmpl
new revision: 1.11; previous revision: 1.10
done
Checking in template/en/default/account/email/change-new.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/change-new.txt.tmpl,v  <--  change-new.txt.tmpl
new revision: 1.9; previous revision: 1.8
done
Checking in template/en/default/account/email/change-old.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/change-old.txt.tmpl,v  <--  change-old.txt.tmpl
new revision: 1.10; previous revision: 1.9
done
Checking in template/en/default/account/email/request-new.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/request-new.txt.tmpl,v  <--  request-new.txt.tmpl
new revision: 1.2; previous revision: 1.1
done
Checking in template/en/default/account/password/forgotten-password.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/password/forgotten-password.txt.tmpl,v  <--  forgotten-password.txt.tmpl
new revision: 1.8; previous revision: 1.7
done
Checking in template/en/default/admin/params/mta.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/mta.html.tmpl,v  <--  mta.html.tmpl
new revision: 1.7; previous revision: 1.6
done
Checking in template/en/default/email/newchangedmail.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/newchangedmail.txt.tmpl,v  <--  newchangedmail.txt.tmpl
new revision: 1.4; previous revision: 1.3
done
Checking in template/en/default/email/sudo.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/sudo.txt.tmpl,v  <--  sudo.txt.tmpl
new revision: 1.2; previous revision: 1.1
done
Checking in template/en/default/email/votes-removed.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/votes-removed.txt.tmpl,v  <--  votes-removed.txt.tmpl
new revision: 1.2; previous revision: 1.1
done
Checking in template/en/default/email/whine.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/whine.txt.tmpl,v  <--  whine.txt.tmpl
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/request/email.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/request/email.txt.tmpl,v  <--  email.txt.tmpl
new revision: 1.14; previous revision: 1.13
done

Comment 102

[Max Kanat-Alexander]

Added to the release notes as part of bug 349423.

Comment 103

[Sam Folk-Williams]

Attachment: docs patch

Attaching docs patch for this. Should apply cleanly to 3.0 and 3.2

Comment 104

[Frédéric Buclin]

Comment on attachment 303864 [details] [diff] [review]
docs patch

Looks good. r=LpSolit

Comment 105

[Frédéric Buclin]

tip:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.88; previous revision: 1.87
done

3.0.3:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.70.2.11; previous revision: 1.70.2.10
done