Jump to content

Misformed headers issue


BorisE

Recommended Posts

I've tried this with "forward as attachment" and also by pasting the "message source" into spamcop.

The message isn't processed, instead returning an error. The reason seems to be that typically 13 lines starting from the "From" line have a one-space indent. If I manually strip the indent the message is processed as normal.

Note I've added a "-" to the affected lines as otherwise the indent doesn't show. In the actual messages it appears to be a single space.

Return-path: <soroort[at]kinki-kids.com>
Envelope-to: *[at]*
Delivery-date: Tue, 30 Sep 2008 16:24:47 +0100
Received: from exprod5mx245.postini.com ([64.18.0.165] helo=psmtp.com)
	  by pih-sunmxcore18.plus.net with smtp (PlusNet MXCore v2.00) id 1Kkh5i-00043d-HE 
	  for *[at]*; Tue, 30 Sep 2008 16:24:47 +0100
Received: from source ([190.66.160.128]) by exprod5mx245.postini.com ([64.18.4.11]) with SMTP;
	Tue, 30 Sep 2008 08:24:43 PDT
Message-ID: <d16a019dba8a$6c957176$c3c32830[at]kinki-kids.com>
- From: "=?windows-1251?B?QWxhYSBDdW5uaW5naGFt?=" <soroort[at]kinki-kids.com>
- To: <*[at]*>
- Subject: =?windows-1251?B?Q2FuYWRpYW4gUGhhcm1hY3k6IFZpYWdyYSwgQ2lhbGlzIGFuZCBtb3JlLi4u?=
- Date: Tue, 30 Sep 3609 10:24:41 -0500
- MIME-Version: 1.0
- Content-Type: multipart/related;
- 		type="multipart/alternative";
- 		boundary=----=_NextPart_000_0023_9C_A07A0642.87D841D8
- X-Priority: 3
- X-MSMail-Priority: Normal
- X-Mailer: Microsoft Outlook Express 6.00.2900.2180
- X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
- X-pstn-neptune: 500/368/0.74/68
X-pstn-levels:	 (S: 0.00220/95.24863 CV:99.9999 )
X-pstn-settings: 1 (0.1500:0.1500) cv gt3 gt2 gt1 
X-pstn-addresses: from <soroort[at]kinki-kids.com> [115/5] 
X-pstn-neptune-cave-rslt: qtine
To:
X-pn-pstn: spam 1
X-PN-Virus-Filtered: by PlusNet MXCore (v4.00)
X-PN-spam-Filtered: by PlusNet MXCore (v4.00)
Subject: 

 This is a multi-part message in MIME format.

------=_NextPart_000_0023_9C_A07A0642.87D841D8
Content-type: multipart/alternative;
		boundary=----=_NextPart_001_0024_9C_A07A0642.87D841D8

------=_NextPart_001_0024_9C_A07A0642.87D841D8
Content-Type: text/plain;
		charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Link to comment
Share on other sites

I've tried this with "forward as attachment" and also by pasting the "message source" into spamcop.

The message isn't processed, instead returning an error. The reason seems to be that typically 13 lines starting from the "From" line have a one-space indent. If I manually strip the indent the message is processed as normal.

Much in contrast to the numerous How to asl a Good Question links provided, there is no mention of the tools in use, OS involved, how e-mail is received and/or handled, etc., etc., etc.

Not mentioned is whether plus.net has been queried about the issue.

In the actual messages it appears to be a single space.

Is this 'result' based on looking at the displayed/rendered e-mail or the inspection of the actual data bits?

Link to comment
Share on other sites

Much in contrast to the numerous How to asl a Good Question links provided, there is no mention of the tools in use, OS involved, how e-mail is received and/or handled, etc., etc., etc.

Not mentioned is whether plus.net has been queried about the issue.

Is this 'result' based on looking at the displayed/rendered e-mail or the inspection of the actual data bits?

Sorry, point taken.

OK, last time I queried Plusnet I got some vague answer about Exim. Didn't help me but I didn't push the issue. There's currently a really big problem with spam generally and I didn't want to be picky about stuff that was being diverted correctly anyway.

Apart from that the spam concerned is showing up in emails collected by Outlook Express via IMAP and on systems running Windows XP Home.

PN's webmail system is also showing similar behavior, though the indent is more substantial. The webmail service uses squirrelmail. Since it's not dependant on my computer I figure my OS and browser are irrelevant.

So, to narrow my question down: Really I'm wondering if Spamcop reporting is right to ignore the affected lines and thus reject the message?

If it really is a consequence of my system then I can see that the correct action is to throw away the affected line, thus leaving the header incomplete and preventing further processing. Can't expect the system to change because of one non-paying user and I'll just sort them into a block and delete them.

I thought it was more likely to be a general thing.

As to looking at the data bits I don't know if OE sanitises incoming email, I looked at a saved email in xvi32 (hex editor) and its a space but whether that's what came off the server or not I don't know.

Link to comment
Share on other sites

First point...

Why is the system: pih-sunmxcore18.plus.net apparently rewriting some of the headers and placing the " - " in front of them?

All of those appear to be valid headers which SpamCop uses for various reasons. Get the plus.net system to stop modifying headers and your problem will likely go away.

Link to comment
Share on other sites

So, to narrow my question down: Really I'm wondering if Spamcop reporting is right to ignore the affected lines and thus reject the message?
...Taking your question literally, I believe the answer is, "yes, by definition, the SpamCop parser can do whatever the SpamCop owners want it to do, since it's their tool." If you are asking whether the SpamCop parser is doing what its owners intend, that would be a question about which we fellow users here can only make a guess. Mine would be that, yes, because the SpamCop parser rejects any headers that violate RFCs for e-mail.

Why is the system: pih-sunmxcore18.plus.net apparently rewriting some of the headers and placing the " - " in front of them?
...Steven, do you mean placing a space in front of them? IIUC, the OP placed the " - " there:
Note I've added a "-" to the affected lines as otherwise the indent doesn't show. In the actual messages it appears to be a single space.
Link to comment
Share on other sites

First point...

Why is the system: pih-sunmxcore18.plus.net apparently rewriting some of the headers and placing the " - " in front of them?

All of those appear to be valid headers which SpamCop uses for various reasons. Get the plus.net system to stop modifying headers and your problem will likely go away.

The "-" was simply so I could indicate the affected part, otherwise the message board appeared to display the entire message left-justified, hiding the extra character.

I can't say with authority that the extra character was a space, only that by the time the message reached my mail client, was saved to disk and loaded into xvi32 it had become a space.

I've only seen the spaces on a limited subset of messages, as far as I am aware always spam. My feeling is its the same two spam sources or one source with two templates, though I don't have facts to back up that.

Do you think it is pih-sunmxcore18.plus.net rewriting the headers or could the header have been sent deliberately misformed?

Link to comment
Share on other sites

Strange. All your examples seem to show that these were received by postini first.

Why would the first "X-pstn-" line be indented, the remainder not indented?

Why is the "To:" line (embedded within the "X-pstn-" lines) be blank?

Are you really using a postini e-mail account ot is this a forwarded/handled e-mail from your actual Host's e-mail server?

How close is any of this (postini) header data sequence to any of your 'good' e-mail?

Has postini been contacted about this?

Link to comment
Share on other sites

Strange. All your examples seem to show that these were received by postini first.

Usually, all of your mail through Postini will go through Postini because in a normal configuration, you would set the MX record for your domain to the postini servers.

Here is a sample of headers from a spam message sent to my server: http://www.spamcop.net/sc?id=z2294601859zd...6494c9eaefb1c1z

For accounts with filtering enabled, the headers always look the same:

X-pstn-neptune: 2/2/1.00/96

X-pstn-levels: (S:20.85539/99.90000 CV:99.9999 R:95.9108 P:95.9108 M:95.5423 C:98.6951 )

X-pstn-settings: 3 (1.0000:1.0000) s cv gt3 gt2 gt1 r p m c

X-pstn-addresses: from <solutioninfo[at]esker.com> [db-null]

It looks to me like PlusNet is performing some additional processing of the message, using the Postini information:

X-pstn-neptune-cave-rslt: qtine

To:

X-pn-pstn: spam 1

X-PN-Virus-Filtered: by PlusNet MXCore (v4.00)

X-PN-spam-Filtered: by PlusNet MXCore (v4.00)

Subject:

Perhaps, they have some process in place to grab the quarantined Postini messages and forward them to the OP with the additional processing and that is introducing the header spacing. That is how I would read the X-pstn-neptune-cave-rslt: qtine line.

Link to comment
Share on other sites

The consensus here is that the indents are being put in by your mail client, or possibly by the POP server you get the mail from.

It also looks like the problem has gone away. You seem to be successfully reporting spam again.

No, its still there for roughly one in ten I'd say. Right now though its easiest for me to just delete them, and only report the rest that have regular headers. I won't waste my time and your bandwidth on a message that I know will be rejected.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...