Handling of Bugzilla emailsuffix parameter

1. Introduction

This document describes the emailsuffix feature in Bugzilla, and how this feature is supported in the P4DTI.

The intended readership is P4DTI development staff.

This document is not confidential.

2. Bugzilla's emailsuffix feature

This discussion applies to Bugzilla 2.14, 2.14.x, 2.16, and 2.16.x. No doubt the algorithm will change in future Bugzilla releases.

The help text for Bugzilla's emailregexp parameter says:

This defines the regexp to use for legal email addresses. The default tries to match fully qualified email addresses. Another popular value to put here is ^[^@]*$, which means "local usernames, no @ allowed.

The default value for emailregexp is ^[^@]*@[^@]*\\.[^@]*$.

The help text for the emailsuffix parameter says:

This is a string to append to any email addresses when actually sending mail to that address. It is useful if you have changed the emailregexp param to only allow local usernames, but you want the mail to be delivered to username@my.local.hostname.

The default value for emailsuffix is the empty string.

When logging in:

• The login name must match the emailregexp parameter (CGI.pl line 767).
• The login name must match the login_name field in the profiles table exactly (CGI.pl line 771).
• The emailsuffix parameter is not consulted.

When sending e-mail, a user's e-mail address is constructing by appending the emailsuffix parameter to the login name (for example, CGI.pl line 734). No check is made to see if login name already contains an "@", or if the resulting address makes sense according to [RFC 822].

3. Consquences of Bugzilla's design

There are bad consequences of this design:

• You can easily get into situations from which the administrator can't log in and so can't fix the problem. For example, setting emailregexp to something that doesn't match the administrator's login.
• You can't get Bugzilla into a state where everyone has usernames consisting only of the local part of their address unless you go into the database and change things by hand. This is because the administrator account is created when you install Bugzilla and at that point emailregexp still has its original value, requiring an "@" in the administrator's login name.
• If you have emailsuffix set, but some users still have their full e-mail address as their login name, then those users won't get e-mail because the constructed e-mail address will be wrong.
• If you decide later to turn off emailsuffix (perhaps because you've now got users from more than one domain), then people with local-part-only login names won't get e-mail. You'll have to go into the database and fix up all the login names.

But presumably Bugzilla administrators live with these problems somehow.

4. How the P4DTI supports the emailsuffix feature

To support the feature, we need to be able to read Bugzilla's emailsuffix parameter. Unfortunately, Bugzilla's server parameters are not stored in Bugzilla's database, but instead in the file data/params in the Bugzilla's installation. This file is possibly not available for reading by the P4DTI since it may be on a different machine.

So we patch Bugzilla to write its parameters to the table p4dti_bugzilla_parameters in the database whenever the parameters are edited [NB 2000-11-14].

This has the consquence that the Bugzilla administrator who installs the P4DTI (or upgrades from a version of P4DTI without this feature) needs to patch Bugzilla and run the editparams.cgi CGI script in order to force the table to be generated [RB 2000-08-10, 5.4.3].

The P4DTI's algorithm is then very simple. When we fetch e-mail addresses from the Bugzilla profiles table (in the function user_id_and_email_list in [NB 2000-11-21]), we append the emailsuffix parameter if we know it. The logic in the user translator is thus unaffected.

A. References

B. Document History

This document is copyright © 2001 Perforce Software, Inc. All rights reserved.

Redistribution and use of this document in any form, with or without modification, is permitted provided that redistributions of this document retain the above copyright notice, this condition and the following disclaimer.

This document is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this document, even if advised of the possibility of such damage.