HTML emails sometimes gives empty emails

RESOLVED FIXED

Status

()

defect
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mossop, Assigned: glob)

Tracking

Production
x86_64
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Posted file mail
I have HTML email enabled and generally it's working fine, however the email I received for bug 779422 comment 2 was just empty and showed up in gmail as a blank email with a "noname" attachment.

The message received is attached.
Assignee

Comment 1

7 years ago
thanks for filing this.

i've disabled html bugmail until we can sort out what the issue is.
Severity: normal → major
Assignee

Updated

7 years ago
No longer blocks: 775275
Depends on: 775275
Assignee

Comment 2

7 years ago
very odd.

philor received a blank bugmail for the component move on bug 785065 (@ 2012-08-23 07:50:50 PDT), but the bugmail for comment 4 was fine.  both changes were made by the same user, and neither contain unicode.

i'll get IT to check if both these actions where serviced by the same webhead.
Assignee: nobody → glob
Assignee

Comment 3

7 years ago
(In reply to Byron Jones ‹:glob› from comment #2)
> i'll get IT to check if both these actions where serviced by the same
> webhead.

they were not.  i have five more empty bugmail reports -- checking if they were also serviced by the same webhead.
Assignee

Comment 4

7 years ago
dkl and i worked through this issue yesterday -- the most likely suspect at this point is an extension (probably profanivore) accidentally clearing the email content.  what makes this confusing is the intermittent nature of this issue.

if you have a multipart message loaded into an Email::MIME object, $email->body returns the text between the header and the first mime boundary.  it's common to see a blurb like "your email client doesn't support mime" in this location; for bugzilla it's empty.  however $email->body_set replaces *all* mime parts with the text, not just the "pre-part body".  all the blank html email i collected were generated by people without editbugs, meaning profanivore would have kicked in, effectively executing $email->body_set(''), clearing the email.

what we can't explain is why it didn't happen for all email generated by someone without editbugs.

in order to diagnose this further, i've committed a change which adds an x-generated-by header to bugmail, as well as enabling html bugmail for dkl and myself only:

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.0/
modified Bugzilla/BugMail.pm
modified Bugzilla/Mailer.pm
Committed revision 8295.
Assignee

Comment 5

7 years ago
i've been a global watcher for a couple of hours and i'm yet to see an empty bugmail (previously i received 5 within the space of 30 minutes).

i've re-enabled html bugmail as an option.

removal of debugging code:

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.0/
modified Bugzilla/BugMail.pm
Committed revision 8303.

i've committed the x-generated-by header to bmo/4.2:

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.2/
modified Bugzilla/BugMail.pm
modified Bugzilla/Mailer.pm
Committed revision 8324.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.