Jump to content

New: Invalid timezone in BT/Yahoo headers


Recommended Posts

Starting today, BT/Yahoo servers are reporting a "timezone" of 퍍 (that's ampersand, crosshatch, five, four, zero, nine, three, semicolon), which causes SpamCop to report that the messages are "minus six hours old".

See for instance http://www.spamcop.net/sc?id=z1848308038zd...29b9692b0257a8z

Link to comment
Share on other sites

Starting today, BT/Yahoo servers are reporting a "timezone" of 퍍 (that's ampersand, crosshatch, five, four, zero, nine, three, semicolon), which causes SpamCop to report that the messages are "minus six hours old".

See for instance http://www.spamcop.net/sc?id=z1848308038zd...29b9692b0257a8z

No newsgroup traffic, no other posts here .. yet .... my look at the Tracking URL results in seeing;

Using best contacts abuse[at]telefonica.com.ar postmaster[at]telefonica.com.ar

Yum, this spam is fresh!

Message is 0 hours old

Apparently, you either hit a glitch or it has been 'fixed' already?

On the other hand, I have no idea what character that the sequence of characters and numbers is actually supposed to represent. There is no character-set defined in the headers that I see.

& # 54093; (spaces inserted so as to display here for me)

Does in fact show up in every spot that a Date/TimeStamp is places (three times in your example) .. yet only as a trailing HTML code (for example, see Character Entities in HTML & XHTML) .. so it is being used for some kind of marking flag for some reason, assumedly some kind of a non-text type of character ...????

'Actual' data seems to be provided at HTML Special Characters from 50001 to 55000 . but again, I obviously don't have the needed character-set installed on this system, as all I see is columns of screwed-up boxes ....

I have no idea how to justify BT/Yahoo's programming, but again, the SpamCop.net parser seems to have been 'adjusted' ...????

Link to comment
Share on other sites

No newsgroup traffic, no other posts here .. yet .... my look at the Tracking URL results in seeing;

Using best contacts abuse[at]telefonica.com.ar postmaster[at]telefonica.com.ar

Yum, this spam is fresh!

Message is 0 hours old

Apparently, you either hit a glitch or it has been 'fixed' already?

no, it's just that six hours have elapsed since then. Compare with the time when I started this topic: if I knew about that spam at the time, it could never still be "zero hours yum-fresh".

On the other hand, I have no idea what character that the sequence of characters and numbers is actually supposed to represent. There is no character-set defined in the headers that I see.

& # 54093; (spaces inserted so as to display here for me)

Does in fact show up in every spot that a Date/TimeStamp is places (three times in your example) .. yet only as a trailing HTML code (for example, see Character Entities in HTML & XHTML) .. so it is being used for some kind of marking flag for some reason, assumedly some kind of a non-text type of character ...????

54093 decimal is D34D hex; and U+D34D falls in the range AC00-D7AF "Hangul Syllables" (i.e., the Korean national writing system), see them in PDF at http://www.unicode.org/charts/PDF/UAC00.pdf

[...]

I have no idea how to justify BT/Yahoo's programming, but again, the SpamCop.net parser seems to have been 'adjusted' ...????

That entity has no business being there, where a timezone code (such as +0200 for Central European Summer Time) ought to be. It looks like a BT/Yahoo bug, since I don't understand how a spammer could mess with Received headers (note, however, that the Date header, which a spammer can set, has the same bizarre entity).

Link to comment
Share on other sites

Ho, hoh: here's a similar symptom from a different ISP: http://www.spamcop.net/sc?id=z1849375030z2...68a345f01e50eaz

That might mean a bug in SeaMonkey instead (I'm using "trunk nightly" builds, i.e., the "bloody-red edge of development".) However, now that I check it, the source of my spam emails is OK (this one has timezones of -0400 which get translated to & #54125;) -- so the error must be either in SeaMonkey/browser or at SpamCop, after I paste the spam into the reporting form.

Sorry, take back the above: the two top Received-lines have the Korean glyph, one of them followed by (CEST), the other not, so the bug must be in SeaMonkey Mail/News.

Link to comment
Share on other sites

...Sorry, take back the above: the two top Received-lines have the Korean glyph, one of them followed by (CEST), the other not, so the bug must be in SeaMonkey Mail/News.
Seems so.

Apropos of nothing but (faintly) amusing, BabelFish says that Korean 퍍 character translates as "It will suck".

Link to comment
Share on other sites

Seems so.

Apropos of nothing but (faintly) amusing, BabelFish says that Korean í character translates as "It will suck".

:lol:

The error is in the View Source window: "Save As" gives an .eml file on disk without the Korean glyphs, see https://bugzilla.mozilla.org/show_bug.cgi?id=431787 -- AFAICT, the error starts wherever a header includes a plus sign (as in European timezones +0000 or +0200 but not in -0700 used by gmail.com) and propagates at least to the next space.

Link to comment
Share on other sites

The error is in the View Source window: "Save As" gives an .eml file on disk without the Korean glyphs, see https://bugzilla.mozilla.org/show_bug.cgi?id=431787 -- AFAICT, the error starts wherever a header includes a plus sign (as in European timezones +0000 or +0200 but not in -0700 used by gmail.com) and propagates at least to the next space.

You don't say, but is there an assumption that you snagged the next nightly download? I don't see anything in your identified version numbers that would seem to reflect a different version in use, but ... wondering how else to explain the "works now" scenario ....

Link to comment
Share on other sites

You don't say, but is there an assumption that you snagged the next nightly download? I don't see anything in your identified version numbers that would seem to reflect a different version in use, but ... wondering how else to explain the "works now" scenario ....

Once I was conscious of the problem, and of the fact that it never happened on "Save As", I checked the spam source before pasting it from the View Source into the SC web form: if there were Korean glyphs (twice) I used "save as", viewed the saved-as in gvim, and pasted from there.

But yes, I do install the next SeaMonkey trunk nightly every day around 13:00 UTC, and with the next build (today's) I didn't see the problem anymore. If it doesn't reappear tomorrow I guess I'll close that bug report WORKSFORME. My current version is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050201 SeaMonkey/2.0a1pre" where the 8 digits after "Gecko" are a datestamp in the form YYYYMMDDHH (for the US Pacific time zone, and referring IIUC to the start of the compilation process, which can take several hours).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...