Jump to content

Spamcop Headers at third line


chriscapoccia

Recommended Posts

I think some spammer is gaming the system by putting spamcop headers early in the headers:

http://www.spamcop.net/sc?id=z818142446z62...;action=display

The reporting system complains about not being able to deterimine the source IP address.

I corrected the email to

http://www.spamcop.net/sc?id=z818143928...&action=display

and everything was able to be parsed correctly.

*MODERATOR* editied your second URL for general viewing

Link to comment
Share on other sites

I think some spammer is gaming the system by putting spamcop headers early in the headers:

34571[/snapback]

Again...the ONLY issue with this spam is the lack of a blank line between the headers and body. Where the x-* headers are does not matter as they are ignored by the parser completely. The error message you got explained it quite clearly:

SpamCop v 1.496 Copyright © 1998-2005, IronPort Systems, Inc. All rights reserved.

No blank line delineating headers from body - abort

If it were legal, the only thing you would need to do is put a blank line between:

Content-Transfer-Encoding: 7bit

$B!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~!y!~(B

Since this message was received directly from the sender (222.149.239.180) by mx53.cesmail.net it does seem their system, or spamcop, is generating the problem. Due to the lack of other complaints, it would still appear to be the sending end. 222.149.239.180 = p4180-ipbf710marunouchi.tokyo.ocn.ne.jp looks like a corrupt end user machine to me.

Link to comment
Share on other sites

I didn't realize that the missing line between body and header was causing the other errors.

Still, this is different from the other spams I've recieved that are missing that line. In those cases, the spamcop headers were at the very end of the message (at the first blank line). In this case they are near the beginning, so it seems like they were inserted by the sender.

Link to comment
Share on other sites

I didn’t realize that the missing line between body and header was causing the other errors.

Still, this is different from the other spams I’ve recieved that are missing that line. In those cases, the spamcop headers were at the very end of the message (at the first blank line). In this case they are near the beginning, so it seems like they were inserted by the sender.

34573[/snapback]

Then where are the ones added by spamcop when it received the message? You did pick that message up on the spamcop server, correct? If so, perhaps you should bring this up to JT (spamcop email admin). His contact info is in the FAQ.

In response to: <a href='http://forum.spamcop.net/forums/index.php?...indpost&p=33420' target='_blank'><a href=\"http://forum.spamcop.net/forums/index.php?...indpost&p=33420\" target=\"_blank\"><a href=\"http://forum.spamcop.net/forums/index.php?...indpost&p=33420\" target=\"_blank\"><a href="http://forum.spamcop.net/forums/index.php?...indpost&p=33420" target="_blank">http://forum.spamcop.net/forums/index.php?...indpost&p=33420</a></a></a></a> just last week

However, this spam seems to have a (poorly constructed) body with the blank line missing beneath the Content-Transfer-Encoding: 7bit when it reached spamcop (otherwise the x-spam* headers would be above that mess).  The headers make it impossible to determine (though highly unlikely) whether the first received line Received: from unknown (x) (43.51.244.789) by 0 is valid. 

It seems possible that spamcop received this message from the sending system (220.150.179.55) without the required blank line after the previous headers.

33431[/snapback]

Your problem in June 2004 is quite possibly the same (those are too old to view at this point): http://forum.spamcop.net/forums/index.php?...ost&p=10573

Link to comment
Share on other sites

I have to agree that there's no real sense of what went on with the example provided to my eyes .... just trying to recreate the sequence of events involved in conjuction with the displayed construct .... doesn't make much sense at all ... server handoff data is inserted "correctly" (i.e., above the previous server hand-off) ... yet theoretically "wrong" if one goes with the "blank line" existing 3 lines down from the top .... but then we move to the SpamAssassin stuff, which gets inserted "correctly" .. but it sees the "blank line" at the top and inserts that data "below the headers" (based on the blank line) ...

Now this would (tend to) indicate that the "blank line" was inserted by JT's server ... yet, if that was the case, why aren't there a zillion posts here (and in the newsgroups) about every e-mail coming into JT's servers having this issue. OK, we could start with that there is more than one server involved, so that might take the 'zillions' down to maybe a 'crapload' ... but even that traffic level doesn't exist ...

The next 'level' would have to center on things like timing, source, phase of the moon, solar flares, or even (heaven forbid) the actual spam construct ... the actual, real, untouched, raw spam would have to be looked at for that kind of analysis ... and JT has the only access to that level of detail. What I'm trying to suggest is that even Forwarding a copy to him might obscure/drop/change enough that the "real" issue couldn't be seen. The closest to the original item would be to actually look at it while still sitting in your InBox .... so if/when you try to conact JT about this, please provide enough identifying data that this specific item can be "found" ....

Link to comment
Share on other sites

I think all the blades are now putting those X-spam and X-SpamCop Header Lines at the top of the Header (as they see it), rather than at the bottom. I don't know when it started, and haven't had the time to research that yet. It shouldn't matter, anyway.

Link to comment
Share on other sites

You did pick that message up on the spamcop server, correct?

Yes. the first link (http://www.spamcop.net/sc?id=z818142446z62...;action=display) is the unmodified email that i recieved using the spamcop webmail interface. It showed up in my held mail just the way you see it.

34596[/snapback]

Yes .. maybe no .... what may be missing is some various contol-codes that are stripped (or at least not displayed) during the parsing process and then 'painting' the screen with the parse 'results' ..... carried further, control-codes stripped by the web-mail app process of "handling" the e-mail for that display ... as said, the "raw" data has to be looked at to rule this stuff out ...

Link to comment
Share on other sites

Yes .. maybe no .... what may be missing is some various contol-codes that are stripped (or at least not displayed) during the parsing process and then 'painting' the screen with the parse 'results' ..... carried further, control-codes stripped by the web-mail app process of "handling" the e-mail for that display ... as said, the "raw" data has to be looked at to rule this stuff out ...
I’m a little confused by your description of potential differences, but I went to my trash folder and looked at the message source for the email in question. They looked exactly the same except that in the copy in my trash, on the second line, “Delivered-To:” includes my email address.

…or are you talking about something different?

Link to comment
Share on other sites

I’m a little confused by your description of potential differences, but I went to my trash folder and looked at the message source for the email in question. They looked exactly the same except that in the copy in my trash, on the second line, “Delivered-To:” includes my email address.

…or are you talking about something different?

34603[/snapback]

Hi, Chris,

...IIUC, what Wazoo means is that what you are able to see in WebMail is not everything that is there -- some (presumably irrelevant to you, as a user but relevant to an analysis of what went wrong) stuff is filtered out before it gets to you. Thus, the reference that only JT can determine the problem and then only if he knows exactly where to look in your folders so he can find exactly the item to which you are referring.

Link to comment
Share on other sites

I think all the blades are now putting those X-spam and X-SpamCop Header Lines at the top of the Header (as they see it), rather than at the bottom.  I don't know when it started, and haven't had the time to research that yet.  It shouldn't matter, anyway.

34593[/snapback]

Also, this Tracking URL seems to indicate that spamassassin is being used before any IP lookups are checked (notice the blank IPA's checked: http://www.spamcop.net/sc?id=z818247767z79...02949f3ed66d5ez

X-SpamCop-Checked:

X-SpamCop-Disposition: Blocked SpamAssassin=9

Looking into the early spamassassin headers myself.

Edit: Looks like around 17 Oct 2005 00:00:00 -0000 give or take

Last message with SA on the bottom:

Received: (qmail 3212 invoked from network); 16 Oct 2005 17:19:08 -0000

Received: from unknown (HELO c60.cesmail.net) (192.168.1.105)

by blade6.cesmail.net with SMTP; 16 Oct 2005 17:19:08 -0000

First message with SA at the top:

Received: (qmail 29528 invoked from network); 17 Oct 2005 00:54:26 -0000

X-spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on blade3.cesmail.net

X-spam-Level: ****

X-spam-Status: hits=4.8 tests=MISSING_HB_SEP,MISSING_HEADERS,MISSING_SUBJECT,

MSGID_FROM_MTA_HEADER,TO_CC_NONE,UPPERCASE_50_75 version=3.1.0

Received: from unknown (HELO c60.cesmail.net) (192.168.1.105)

by blade3.cesmail.net with SMTP; 17 Oct 2005 00:54:26 -0000

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...