230182 - "User-Agent" header, in sent messages, should contain more information

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, enhancement, P1)

Description

[Alexander Skwar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.5) Gecko/20031007 Firebird/0.7

This bug is related to bug 227863. In 227863, "it was decided" to drop some
useful information from the User Agent string used when sending Mail/News.
Please re-add the following now missing data:

- OS
- Language

These data are useful for example for statistic tools to get information about
what a certain user is/might be using.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Karsten Düsterloh]

This main significance of a user-agent header like

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205
Thunderbird/0.4

lies in the version and OS information for debugging purposes. It's quite
important to get this information when "supporting" via email or newsgroups,
since certain problems may be platform-dependend - and end users tend to *not*
provide this info in their first messages...

Comment 2

[Simon Paquet [:sipaq]]

It would be good to have the OS and language information back. Not necessarily
for statistical purposes (that would be a side effect), but as Karsten said, it
is nice to have for support reasons.

And something like "Mozilla Thunderbird 0.5a (20040105/Win98/en-US)" would still
be much shorter than "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a)
Gecko/20040105 Thunderbird/0.5a" (47 characters vs 78 characters).

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

Mozilla Thunderbird 0.5a (Windows NT 5.1;en-US) Gecko/20040109

I feel "Gecko/YYYMMDD" very important here - it's a word anyone can choose to
recognize Gecko Engine based product

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I thought there was a check-in for additional OS info? Within an actual nightly
build I can't see it "Mozilla Thunderbird 0.5a (20040111)".

Comment 5

[Simon Paquet [:sipaq]]

Henrik, this information can't be found under Help -> About Mozilla Thunderbird.
Post a message to a test newsgroup and look at the message source.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Right, my failure... 

So what if we need further information about the client to give the right
support? I would prefer to see the whole (old) UA-String inside "Help | About"
like TB always sends by HTTP-Requests. In that combination we see an overview of
the affected system and could give best matched answers.

Comment 7

[Alexander Skwar]

I completely agree with Henrik. What's so bad at all about "User-Agent:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.6b) Gecko/20031205
Thunderbird/0.4" that it needed to be changed? I agree that it's not nicely
formatted, but that's all.

What about something like (based on my UA pasted above):

Mozilla Thunderbird 0.4 (Windows NT 5.1; de-DE; 20031205)

(This is basically the same Simon posted in comment #2).

I disagree with comment #3. In *Mail* User Agents or X-Mailer headers, Mozilla
is only used by Mozilla mail clients (ie. Mozilla-The-Suite and Thunderbird).
Thus, the string "Mozilla" is good enough to distinguish a Mozilla based MUA/NUA.

Comment 8

[Alexander Skwar]

Section 6.18 of
http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-12.txt suggest
that the User-Agent header should be:

      header              =/ User-Agent-header
      User-Agent-header   = "User-Agent" ":" SP User-Agent-content
                               *( ";" extension-parameter )
      User-Agent-content  = product *( CFWS product )
      product             = [CFWS] token [CFWS] [ "/" product-version ]
      product-version     = [CFWS] token [CFWS]

It also gives examples:

      User-Agent: tin/1.3-950621beta-PL0 (Unix)
      User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486))
      User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712)
      User-Agent: Microsoft-Internet-News/4.70.1161
      User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest")
      User-Agent: inn/1.7.2

A current Tb has:

User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040321)

That's clearly wrong wrt. usefor. In Usefor, it should be:

Mozilla Thunderbird/0.5+ (Windows; 20040321)

Also IMO the "20040321" could be seen as a "version" qualifier and should be
behind the "0.5+".

Yes, I DO know that Usefor isn't authorative and just a draft. Nonetheless,
there are some parts from verious drafts of usefor which are followed, and so
should this part.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Scott, could you give any comments please? 

The shortened version string raises confusions for supporters. New users whose
want to get help of our newsgroup paste this string: Mozilla Thunderbird 0.6+
(20040417). You can't see the OS und selected language. Every time we have to
reask for system information before we could give the correct answers. That's a
hassle. Please add these both entries and also take a look at comment 8 which
describes the suggestion how the UA should be build.

Comment 10

[Karsten Düsterloh]

Attachment: simple information extension (lots of whitespace, please see -w diff)

Since the checkin of bug 227863, the community support of Thunderbird,
especially in case of localized versions, is badly hampered.

Before this fix, a mail or newsgroup posting contained this fully
qualified HTTP style user-agent:

> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
> Gecko/20031205 Thunderbird/0.4

The current format

> User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040418)

still does not provide sufficient data, because you can't
tell neither the exact OS nor language.

The original first "fix" in bug 227863 was justified with

| We should really use a more user friendly user agent

But who *are* the users this header needs be more friendly for?

As long as everything runs well, Joe User (mostly) won't care about that
header. *If* problems occur, Joe User might post to a Mozilla community
newsgroup or send some mail to a friendly Mozilla wizard, but usually
won't include any (sufficent) data. The old User-Agent header did that
for him, and no further to and fro was needed to get this information.
The relevant information here are:
- OS (as in "Windows NT 5.0", not just "Windows"; this may matter wrt to
graphic card drivers etc.)
- Language
- Thunderbird Version
We had a *very* long thread lately in de.comm.software.mozilla.*, the
German language Mozilla community newsgroup hierarchy, until it was
realized that the user was using a *localized* version of Thunderbird!

The second group of people making use of this header are the testers,
especially those of nightly builds. When discussing the latest bugs and
features (e.g. in de.comm.software.mozilla.nightly-builds), it's just a
necessity to know the above mentioned data and of course the:
- build date (which should be assumed to reflect vicinity to the source).

Summary:
This current new form of the User-Agent header is now more readable for those
who don't care about it anyway, but next to useless for those who depend upon
it.

My patch will alter the User-Agent like this:

Mozilla Thunderbird 0.6+ (Windows NT 5.0; en-US; 20040418)

(The file nsMsgCompUtils.cpp contains *lots* of inconsistent whitespace I
corrected also, please see the -w diff for the real minor changes in building
the User-Agent string!)

Comment 11

[Karsten Düsterloh]

Attachment: -w diff of attachment 146840

Same patch as attachment 146840 [details] [diff] [review], but diffed with -w.

Comment 12

[Karsten Düsterloh]

Comment on attachment 146840 [details] [diff] [review]
simple information extension (lots of whitespace, please see -w diff)

(please see -w diff for relevant changes when reviewing)

Comment 13

[Karsten Düsterloh]

Attachment: simple information extension; Usefor style

I forgot the "/" required by Usefor and I have been advised kindly not to touch
the (whole) whitespace mess. ;-)

Comment 14

[Karsten Düsterloh]

Comment on attachment 146844 [details] [diff] [review]
simple information extension; Usefor style

Please see comment #10 for a rationalization of this patch; the User-Agent
format is now Usefor compliant: Mozilla Thunderbird/0.6+ (Windows NT 5.0;
en-US; 20040418)

Comment 15

[David :Bienvenu]

Comment on attachment 146844 [details] [diff] [review]
simple information extension; Usefor style

Scott should review the proposed user agent change

Comment 16

[Alexander Skwar]

Scott, do you think the patch could be applied?

Comment 17

[Rafael Gattringer]

suggestion for the first UA part:

"Mozilla-Thunderbird/0.6"

(I don't know about the "+")


1. use a line between Mozilla and Thunderbird
source: http://asg.web.cmu.edu/rfc/rfc2616.html#sec-14.43
(eg. "CERN-LineMode") 

2. use a slash before the product version
source: http://asg.web.cmu.edu/rfc/rfc2616.html#sec-3.8
product         = token ["/" product-version]
also used in FireFox


Long term it would be great to have a consistent user agent for all the Mozilla
products.

Possible duplicate: http://bugzilla.mozilla.org/show_bug.cgi?id=242361

Comment 18

[Ben Bucksch (:BenB)]

Bug 242361 contains relevant syntactic information, some of it repeated in
comment 17.

Comment 19

[Karsten Düsterloh]

Since the User-Agent string relies upon the data in
mozilla/mail/base/locale/brand.properties (to be precise, it should rely upon
brandFullName, not brandShortName as it is currently in code and my patch - see
bug 240741), we have a problem here: the dash should of course *not* be part of
the brandFullName...

Comment 20

[Ben Bucksch (:BenB)]

s/ /-/g ?

Comment 21

[Karsten Düsterloh]

> s/ /-/g ?

Yeah, of course - but that's not "pretty". Maybe my view point is far too
mathematic to propose something like that. ;-)
But now that it's mentioned, I can use it without hiding... :)
I'll update my patch as soon as I have a current TB tree again.

Comment 22

[Ben Bucksch (:BenB)]

heh, funny that you call it "mathematic", but I usually wouldn't propose
something like this. But in this case, it seems merely that spaces are not
allowed (because spaces are token delimiters) and "-" seems to be the normal
replacement.

It's not a good solution, and I don't see one that could be inferred from the
brandFullName. What, if brandFullName is "AOL (Optimized Version)" or whatever?
Apart from the forbidden brackets, you may want to send another string as
product identifer than what you show to the user, so the only "right" solution I
see is to use a new entity in brand.properties.

Comment 23

[Ben Bucksch (:BenB)]

hm, brand.properties is localizable. What about a case like in Seamonkey or if
AOL decides to ship it and call it "AOL Mail", and then localizes the "Mail"?
The UA string should be fixed for a product, no matter the locale, so you can't
use mozilla/mail/base/locale/brand.properties anyways.

Comment 24

[Karsten Düsterloh]

> What about a case like in Seamonkey or if AOL decides to ship it and call it
> "AOL Mail", and then localizes the "Mail"?

If we introduce a new property like "brandUserAgentName", it should clearly be
marked as non-*local*izable (and get a comment about how to construct it).

We should, however, have this string in exactly *one* location so that every
part of Mozilla/TB/whatever that needs it can get it easily. 
So I think that brand.properties is still the place to put it in.

Comment 25

[Adam Guthrie]

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

Comment 26

[Scott MacGregor]

Comment on attachment 146844 [details] [diff] [review]
simple information extension; Usefor style

We've shipped with the current UA since December of 2003 and I'm still happy with it and am not keen on changing it. I recognize that not everyone is happy with that :)

Comment 27

[Alexander Skwar]

Yes, it is broken since 2003-12. But what was the actual reason for this change? Where's the gain in that unneccessary shart UA? And why don't you want to revert your error?

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #26)
> We've shipped with the current UA since December of 2003 and I'm still happy
> with it and am not keen on changing it. I recognize that not everyone is happy
> with that :)

Why not? It's cool short! I like the bug reports of people whose don't know much about Thunderbird and their system. So you have to ask twice or more to get the full information you need to start any qa work. That's not frustrating, no definetely not. But due to this reason I stopped working on such bugs since a long time (was it nearly 2003-12?). So no need to bother, you are on the right way...

Comment 29

[Alexander Skwar]

(In reply to comment #28)
> (In reply to comment #26)
> > We've shipped with the current UA since December of 2003 and I'm still happy
> > with it and am not keen on changing it. I recognize that not everyone is happy
> > with that :)
> 
> Why not? It's cool short! I like the bug reports of people whose don't know
> much about Thunderbird and their system. So you have to ask twice or more to
> get the full information you need to start any qa work. That's not frustrating,
> no definetely not.

Yes, you are *ABSOLUTELY* right. Karsten also had this put quite nicely in his summary of comment #10:

Summary:
This current new form of the User-Agent header is now more readable for those
who don't care about it anyway, but next to useless for those who depend upon
it.

It is hard for me to put it any better than Karsten had written it in April 2004 - about 19 months ago!

Anyway, I'd still like to understand why the UA string had to be changed that way and why this malfunction cannot or "should not" be undone. Are there any reasons for this change? I mean - other than, that it now looks more ugly, than it did before?

Comment 30

[Magnus Melin [:mkmelin]]

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

Comment 31

[David E. Ross]

In any fix for this bug, please be sure the UA header appears on the [About > Thunderbird] window in a manner that can be marked and copied.  

By the way, the IETF link cited in comment #8 is now 404.  Is there another reference?  Has this become an RFC?  

Comment 32

[David E. Ross]

The cited link and section in comment #8 appears now to be <http://www.rfc-editor.org/internet-drafts/draft-ietf-usefor-usefor-11.txt> section 3.2.13.  

See also RFC 2616 at <ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt> section 14.43.  

Comment 33

[Ben Bucksch (:BenB)]

Note that the specific OS version (security bugs) and the language (ethnical group) may be sensitive. See bug 57555 and bug 55366.

Comment 34

[Karsten Düsterloh]

Taking off my radar.

Comment 35

[Przemyslaw Bialik]

(In reply to comment #26)
> We've shipped with the current UA since December of 2003 and I'm still happy
> with it and am not keen on changing it. I recognize that not everyone is happy
> with that :)
After ~2 years mscott is probably still happy with it ;) but if you want to have (for yourself or for the users you support) full UA string in TB then install Mnenhy extension - http://mnenhy.mozdev.org/ (fixed UA is only small part of it features).

Comment 37

[Serge Gautherie (:sgautherie)]

(In reply to comment #36)
> *** Bug 426046 has been marked as a duplicate of this bug. ***

While the About dialog was mentioned in some previous comment(s),
let's not confuse the two issues:
keep this bug for what TB adds to its email headers,
keep bug 426046 for what it makes available in its About dialog.
(And this goes for the two previous duplicates too.)

Comment 38

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.

Comment 39

[Karsten Düsterloh]

Duping against 242361, since the patch there might even have a chance of being accepted...

Comment 40

[Przemyslaw Bialik]

(In reply to comment #39)
> Duping against 242361, since the patch there might even have a chance of being
> accepted...
Patch didn't add anything what has not been before (cosmetic changes) so it can't be a duplicate (bug is still valid). 

 -> Reopening

Comment 41

[David Ascher (:davida)]

I don't see a compelling reason not to be more informative, and I can imagine it'd make support easier, so my vote would be to accept the patch.  

Comment 42

[Mark Banner (:standard8)]

So this has been suggested elsewhere (bug 446367).

What I don't understand about the patch is why it doesn't just use the full user-agent string that Thunderbird already has (see currently nightly about dialog).

I think in fact that's what we should do, and as Karsten suggested in bug 446367 comment 1:

> Or you could just use the pHTTPHandler->GetUserAgent(userAgentString) call for
> Shredder builds...

(but I would make that all builds).

Comment 43

[Bryan Clark (DevTools PM) [:clarkbw]]

Lets get the patch cleaned up and move this in for b1

Comment 44

[Karsten Düsterloh]

(In reply to comment #43)
> Lets get the patch cleaned up and move this in for b1

I'm not working on this, I gave it back long ago. Whoever feels the patch is useful as a base for his/her work, please feel free to mutilate it until it fits in. ;-)

Comment 45

[Mark Banner (:standard8)]

Attachment: Just use the standard User-agent

Bryan wants to fix this bug, Magnus doesn't like the full UA (because its ugly), but here's my proposal for using the full UA anyway.

Reasons:

- We don't have to do any extra processing.
- We automatically pick up any general.useragent.extra prefs (e.g. lightning)
- Its the same as what we send for http, and therefore people know they can process it in the same way (if they really want to) - I'm thinking about people using this for support purposes.

The UA we currently get is:

- Thunderbird/version (note: always Thunderbird regardless of branding setting).
- Platform
- Full Build ID (not prefixed by Gecko)

The full UA will give us additional info:

- Mozilla/5.0 (although this is probably the one thing we don't need)
- Language
- OS/CPU
- Gecko version
- Correct name for Thunderbird (i.e. Shredder/Thunderbird)
- Any extras that are included in the preferences by extensions or the user.

Magnus, if you want to come up with another proposal, please do.

Comment 46

[Magnus Melin [:mkmelin]]

Well, seems to me the only missing (if you will) information is OS and language. Even the gecko id is in there implicitly.

I wouldn't mind just adding those, along the lines of Karsten's earlier patch. I can offer to make a patch if we can agree on what we want it to look like.

Re picking up general.useragent.extra prefs, I don't know why we would encourage extensions to put their name there just for the sake if it. Lightning does it but I got the impression that there wouldn't be so much of a Lightning extension in the future, just the lightning project, and a thunderbird (and possibly seamonkey later) where calendar is integrated.

The current format on trunk is e.g. "Thunderbird/3.0b1pre (X11; 20080825035820)"

I guess I propose we make that it read like e.g.
 "Thunderbird/3.0b1pre (X11; Linux i686; en-US; 20080825035820)"
 "Thunderbird/3.0b1pre (Windows; Windows NT 6.0; en-US; 20080825035820)"

Comment 47

[Mark Banner (:standard8)]

(In reply to comment #46)
> Well, seems to me the only missing (if you will) information is OS and
> language. Even the gecko id is in there implicitly.

I still think we should use the Shredder/Thunderbird name as well.

> Re picking up general.useragent.extra prefs, I don't know why we would
> encourage extensions to put their name there just for the sake if it. Lightning
> does it but I got the impression that there wouldn't be so much of a Lightning
> extension in the future, just the lightning project, and a thunderbird (and
> possibly seamonkey later) where calendar is integrated.

I'm not saying all extensions should do it, but I know a lot of extensions do, and I don't see why we should support something at http level and not support it in message headers where we are doing the same thing.

> The current format on trunk is e.g. "Thunderbird/3.0b1pre (X11;
> 20080825035820)"
> 
> I guess I propose we make that it read like e.g.
>  "Thunderbird/3.0b1pre (X11; Linux i686; en-US; 20080825035820)"
>  "Thunderbird/3.0b1pre (Windows; Windows NT 6.0; en-US; 20080825035820)"

I agree that's clearer than what we have in the full user-agent. I just don't see why we need the extra code to regenerate it in our own format.

However, I think its time we had some comments from the other main developers on this.

Comment 48

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 335503 [details] [diff] [review]
Just use the standard User-agent

I don't see a lot of value in having this be "neater".  It's only going to be used in a support context.  I suppose it's conceivable that people might be able to talk about a neater version more casually to a support person rather than doing a full copy-paste, but I'm not sure that's particularly desirable.  I suppose it's also the case that people doing software that handles email statistics might be forced to change their parsing code more than if we just added stuff here, but avoiding that doesn't feel like a particularly heavyweight benefit either. I'll cast my lot with code simplicity and matching user-agents between mail and http.  That said, I'd like clarkbw to weigh in here in case there's some bit of UE-reasoning that I've missed.

sr=dmose

Comment 49

[Bryan Clark (DevTools PM) [:clarkbw]]

I don't really see the user impact in sending a pretty string.  I understand how magnus wants a nice looking UA, but that seems like it's more about the rendering end where we display the string.  And I'd personally rather work on a string parser that allows us to display this header nicer than just text format (but that's just me).

Comment 50

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 335503 [details] [diff] [review]
Just use the standard User-agent

looks good to me

Comment 51

[Phil Ringnalda (:philor)]

Comment on attachment 335503 [details] [diff] [review]
Just use the standard User-agent

r=me to paint it blue, purely because it's less code that way. Magnus and I will probably be happier once we turn off .showUserAgent and stop seeing how many Mozilla people use Mail.app, anyway.

Comment 52

[Magnus Melin [:mkmelin]]

Beating a dead horse, but what is the value of *not* having a pretty string - it was implemented for a reason back in bug 227863 (mail-agents do have pretty U-As). The code simplicity argument doesn't buy us much as it's already implemented and not very likely to break. With lightning installed the row is long enough (130+ chars) to make the whole Thunderbird string go off screen at times:(

Comment 53

[Magnus Melin [:mkmelin]]

So this would actually also go against RFC 2822, line length "SHOULD be no more than 78 characters".

Comment 54

[Karsten Düsterloh]

(In reply to comment #52)
> Beating a dead horse, but what is the value of *not* having a pretty string -

A User-Agent header is not meant to be pretty but informative. Usually you don't display it, but check it for statistical or debugging purposes only. Only geeks like us care to see it. ;-)

(In reply to comment #53)
> So this would actually also go against RFC 2822, line length "SHOULD be no
> more than 78 characters".

That's quote abuse. :-P
RfC 2822 says: 
  "Each line of characters MUST be no more than 998 characters,
   and SHOULD be no more than 78 characters, excluding the CRLF."
And:
  "The more conservative 78 character recommendation is to accommodate
   the many implementations of user interfaces that display these
   messages which may truncate, or disastrously wrap, the display of
   more than 78 characters per line, in spite of the fact that such
   implementations are non-conformant to the intent of this
   specification (and that of [RFC2821] if they actually cause
   information to be lost)."

Comment 55

[Robert Kaiser]

(In reply to comment #48)
> I suppose it's also the case that people doing software that handles email
> statistics might be forced to change their parsing code more than if we just
> added stuff here, but avoiding that doesn't feel like a particularly
> heavyweight benefit either.

Well, as SeaMonkey and Mozilla suite have been sending the standard UA string (which we're turning to again now) all the time, and e.g. the Mnenhy extension AFAIK has set back Thunderbird to that string as well, I guess people might already have the parsing in place for this.

Comment 56

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #52)
> Beating a dead horse, but what is the value of *not* having a pretty string -
> it was implemented for a reason back in bug 227863 (mail-agents do have pretty
> U-As). The code simplicity argument doesn't buy us much as it's already
> implemented and not very likely to break.

It's less C++ code, so the attack surface is ever-so-slightly smaller, and there are ever-so-slightly fewer bytes in memory.  Having the HTTP and Mail User-Agent fields be different also seems to violate the principle of least surprise.  

That said, I don't think the arguments in either direction are all that compelling, and related to that, I don't think it's really all that important which way this goes, but we do need _a_ decision.  Given that we've reached agreement between the reviewers and ui-reviewer on this bug, I suggest not spending more time analyzing the exact result here.

Comment 57

[Mark Banner (:standard8)]

Checked in, changeset id: 214:03c93f598af6

Fixed.

Comment 58

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with:

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080830025944 Shredder/3.0b1pre

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080831032002 Shredder/3.0b1pre

Mark, is the fix something we could also have for Thunderbird 2?

Comment 59

[Mark Banner (:standard8)]

(In reply to comment #58)
> Mark, is the fix something we could also have for Thunderbird 2?

I don't think that is necessary. TB 2 is essentially frozen and this fix wouldn't benefit it or anyone currently expecting there to be the old UA string - I think its ok to change the format between major versions, but not between minor versions.

Comment 60

[Daniel Veditz [:dveditz]]

This doesn't seem like an appropriate branch change, certainly not a "blocker". Will let dmose/dascher rule on approving a patch though.

Comment 61

[David Ascher (:davida)]

I can't think of a compelling argument to change this in branch.

Comment 62

[Ben Bucksch (:BenB)]

Just FYI: SpamAssassin checks for malformed User-Agent specs and assigns the mail a higher spam-likeliness score, if such a forgery is found. However, their check seems to be no problem with this change:
header RATWARE_MOZ_MALFORMED	User-Agent =~ /Mozilla\/5\.0\d\d/
describe RATWARE_MOZ_MALFORMED	Bulk email fingerprint (Mozilla malformed) found
If I read this right, the "malformed" rule only triggers, if there's a "Mozilla/5.014" (i.e. digits instead of a space after the "5.0"), so no problem.

Comment 63

[Mark Banner (:standard8)]

I just checked in a change to remove the redundant addition of MOZ_APP_VERSION to DEFINES that was left when we did the patch (rs=Neil over irc):

http://hg.mozilla.org/comm-central/rev/9441142c94d4