Jump to content

Spamcop parse problem/bug ?


Elrond

Recommended Posts

Hello,

Did some can check this report:

http://www.spamcop.net/sc?id=z2764939177z5...cbc14d45482003z

As you see the spammer add custom lines that broke spamcop validation.

--- cut ---

Return-Path: <misinterpretationg[at]markstratton.com>

Delivered-To: x

Received: (qmail 23459 invoked from network); 6 Apr 2009 14:31:20 -0000

Received: from unknown (HELO KUDMNJV) (201.38.97.38)

by ns1.bulsat.com with SMTP; 6 Apr 2009 14:31:21 -0000

MAIL FROM: <inevitablyof8[at]hvdregion.com>

RCPT TO: <x>

RCPT TO: <coml.nikolov[at]bulsat.com>

DATA

Received: from 201.38.97.38 by smtp.secureserver.net; Mon, 6 Apr 2009

11:33:14 -0300

Message-ID: <000d______________________a8c0[at]inevitablyof8>

--- end ---

My question is: Is this a bug of spamcop parse ?

Link to comment
Share on other sites

...

http://www.spamcop.net/sc?id=z2764939177z5...cbc14d45482003z

As you see the spammer add custom lines that broke spamcop validation.

My question is: Is this a bug of spamcop parse ?

Not a bug as such, no. The spam is 'non-compliant' with the standards for message structure in many places and it is accepted that the SC parser requires messages to be more compliant than many mail applications/clients. See http://forum.spamcop.net/forums/index.php?showtopic=10066 (the later parts) for some discussion on the exact-same type of mangled messages.
Link to comment
Share on other sites

My question is: Is this a bug of spamcop parse ?

No 'bug' in the parser, working as designed. Your issue is with exactly what you pointed out plus the blank line added above that content. Both result in the parser not seeing an actual, complete header. Rather than starting this all over again, please see http://forum.spamcop.net/forums/index.php?showtopic=10066 for a previous discussion about this same issue (though not including the extra blank line to my recollection.)

EDIT: OK, due to my connectivity issues, I only now see that Farelf beat me to it .. though happy that we agreed right down the line <g>

Link to comment
Share on other sites

Ok, it's seems this is issue that nobody guess that can happened and i actually want replay something like: Yep, the parse of the services is not good, this part:

MAIL FROM: <inevitablyof8[at]hvdregion.com>

RCPT TO: <x>

RCPT TO: <coml.nikolov[at]bulsat.com>

DATA

is a fake/custom data and service/scri_pt/bot/program that parse emails in spamcop side will skip these lines and because actually spamcop service only need the Received lines, this part of data that is not needed will be discarded in next patch of services and ppl will be free to report via email again spams like this one.

Basic that is :) cya and good luck. Case closed.

Link to comment
Share on other sites

is a fake/custom data and service/scri_pt/bot/program that parse emails in spamcop side will skip these lines and because actually spamcop service only need the Received lines, this part of data that is not needed will be discarded in next patch of services and ppl will be free to report via email again spams like this one.

Basic that is :) cya and good luck. Case closed.

??? No idea where you picked up on the data that you posted here. Maybe I don't understand the intended sarcasm?

The is no upcoming patch for this type of issue. As conjectured on the other Topic, these appears to be a (e=mail) server problem that would have to be fixed by that ISP/Host. However, the story changes just a little bit in your case because of the extra blank line inserted, probably as a part of whatever is screwed up on that server. No, one would not expect a header like this ever making its way through the parser.

Link to comment
Share on other sites

??? No idea where you picked up on the data that you posted here. Maybe I don't understand the intended sarcasm?

The is no upcoming patch for this type of issue. As conjectured on the other Topic, these appears to be a (e=mail) server problem that would have to be fixed by that ISP/Host. However, the story changes just a little bit in your case because of the extra blank line inserted, probably as a part of whatever is screwed up on that server. No, one would not expect a header like this ever making its way through the parser.

Heh ... click on link, second click on "View entire message" ... wtf ... hahaha

You really expect some one to fix his broken server to can your "program" work ? Heh .. americans ... they always try to save the world haha ...

It's so simple solution if you only add a few lines to skip this part of data from email header that should not to be there and is not in any RFC.

Link to comment
Share on other sites

You really expect some one to fix his broken server to can your "program" work ?

Certainly not if no one lets them know about the issue. Only discussed here is why the Parser didn't like the content. Not discussed here is what happens to other applications, utilities, actions that can occur with other tools, servers, processes, etc. There's a reason so much work goes into the RFCs that lay down and define the rules.

Heh .. americans ... they always try to save the world haha ...

No idea why race, creed, ethnicities, etc. would be a part of this Discussion. BTW: not all folks 'here' .. even specific to the Discussion ... are 'american' ....

It's so simple solution if you only add a few lines to skip this part of data from email header that should not to be there and is not in any RFC.

Yet, the reasons those checks are in place are to insure that the Reporter hasn't screwed things up in his/her submittal. Your 'simple' fix is actually next to impossible to accomplish if one wants to "fix" all the variations of all the possibilities of all the things that can go wrong with even a simple cut/paste action. One person solved his 'error' problem by simply making his display window a few pixels wider, which changed where the line-wraps occurred on screen, which then allowed the "copy" function to pass correct data.

Remarks as seen in your last tend to make this look like Lounge Rant material. This is a Help Forum, you made a query, answers were provided, you want make off-the-wall remarks .... not the way things work here.

Link to comment
Share on other sites

It's so simple solution if you only add a few lines to skip this part of data from email header that should not to be there and is not in any RFC.

The parser was design to handle RFC compliant email headers. Sure it may seem simple to step over the blank line, but where does that leave you? That blank line normally indicates the end of the header.

If you step over the "end" what other lines of code do you need to handle what ever you find?

If you disregard this part of the standard, what other parts of the standard do you suggest not be followed?

I see you would have liked a different answer. When the cop tells me I can't park in a no parking zone, I would like a different answer too.

Link to comment
Share on other sites

Wazoo: You are angry ? This remember me in my early years when linux and bsd systems just become popular and i speak with one of dev. of one un*x system in sf mailing list and point him that it's very easy ppls to obtain root on system he decline two months this to be true in mailing list when other ppl from mailing list also told him and he finally replay: why i to care about that exploit, do you know how many other exploits have on this version ... Any way, don't skip one problem just because of some personal reasons. Don't think that spammers does not read forums, tomorrow all spammer servers will be configured to use this problem.

And im not guilty when i register me as mail admin i can't use web services for spam report and i should register a new account for that and to remember both two passwords.

Lking: True, but as we see

Return-Path: <misinterpretationg[at]markstratton.com>

Delivered-To: x

Received: (qmail 23459 invoked from network); 6 Apr 2009 14:31:20 -0000

Received: from unknown (HELO KUDMNJV) (201.38.97.38)

by ns1.bulsat.com with SMTP; 6 Apr 2009 14:31:21 -0000

MAIL FROM: <inevitablyof8[at]hvdregion.com>

RCPT TO: <x>

RCPT TO: <coml.nikolov[at]bulsat.com>

DATA

Received: from 201.38.97.38 by smtp.secureserver.net; Mon, 6 Apr 2009 11:33:14 -0300

Message-ID: <000d______________________a8c0[at]inevitablyof8>

From: "Cecil Saldana" <inevitablyof8[at]hvdregion.com>

To: <x>

Subject: You will feel your manhood in the air.

Date: Mon, 6 Apr 2009 11:33:14 -0300

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="----=_NextPart_000_0006_01C9B6C4.9E94FFE0"

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

That is the whole header the bad part is :

MAIL FROM: <inevitablyof8[at]hvdregion.com>

RCPT TO: <x>

RCPT TO: <coml.nikolov[at]bulsat.com>

DATA

Parser can skip these lines but this can be used also as adding fake header can be identified as point system but even if idea is not be developed the first few lines is still have information about the real spammer and his last host that email is arrived:

Return-Path: <misinterpretationg[at]markstratton.com>

Delivered-To: x

Received: (qmail 23459 invoked from network); 6 Apr 2009 14:31:20 -0000

Received: from unknown (HELO KUDMNJV) (201.38.97.38)

by ns1.bulsat.com with SMTP; 6 Apr 2009 14:31:21 -0000

Last part of the email header can be safety discarded and parser to continue with looking href parts.

That is only basic idea of course, it's can be developed from developers team of spamcop

Link to comment
Share on other sites

...Elrond, please forgive me if I have failed to understand you but what you seem to be saying is that you want the SpamCop developers to "fix" their parser to match your ideal of what the parser should do. IMHO, you have things reversed. If you don't like the way the parser works, don't use it -- find another or write your own. The parser works the way it does for certain reasons, those reasons being determined by those who are kind enough to provide the tool for general use by those of us who find it helpful.

...Actually, even the statement I just made is too strong -- you may still use the parser on an edited version of the spam (edited as you wish, taking out the parts you want the parser to skip); you just can not use SpamCop's Submit feature to send the reporting e-mails but you may use the results to construct your own reporting e-mails to the abuse e-mail addresses offered by the parser results.

Link to comment
Share on other sites

Lking: True, but as we see...

That is the whole header the bad part is :

Elrond, excuse me for being redundant, but the end of the header is the first blank line so the header is:

Return-Path: &lt;misinterpretationg[at]markstratton.com&gt;
Delivered-To: x
Received: (qmail 23459 invoked from network); 6 Apr 2009 14:31:20 -0000
Received: from unknown (HELO KUDMNJV) (201.38.97.38)
by ns1.bulsat.com with SMTP; 6 Apr 2009 14:31:21 -0000

NOTE the blank line. Just like the parser identified "This header is incomplete."

The other lines starting with

MAIL FROM: &lt;inevitablyof8[at]hvdregion.com&gt;

are lines of the body that just happen to look like header lines. They are part of the body of the email because they are after the first blank line.

Sorry you don't like a parser that parses an email according to the standards, but I prefer the tool to work that way.

Link to comment
Share on other sites

Wazoo: You are angry ? ... Any way, don't skip one problem just because of some personal reasons.

I am only a volunteer support person. Your complaint would need to go to those paid to handle it .... starting with Don/Deputies .. who would have to then pass it upstream to the IronPort/Cisco staff that are now handling the software coding. As your request for help has in fact turned into a bit of a rant, this Topic is going to be moved to the Lounge area.

Don't think that spammers does not read forums, tomorrow all spammer servers will be configured to use this problem.

I'm just not sure how much access spammers might have on the mal servers involved. My feelings are that if the spam e-mail was actually constructed as shown, there would be many other delivery issues.

And im not guilty when i register me as mail admin i can't use web services for spam report and i should register a new account for that and to remember both two passwords.

I have no idea what you are actually saying .... but the small complaint about "two passwords" ... geeze, I honestly don't want to try to put a number on the passwords and account names I have to deal with. Thinking just for SpamCop.net, I'm dealing with at least nine different login data sets. A few dozen others that I do web maintanance for each requiring different login data sets, the numerous Foums, Lists, subscribed services, on and on .... none using the same login data set .... I can't afford a compromise at one place that would then allow entry to someplace else.

Parser can skip these lines but this can be used also as adding fake header can be identified as point system but even if idea is not be developed the first few lines is still have information about the real spammer and his last host that email is arrived:

Last part of the email header can be safety discarded and parser to continue with looking href parts.

That is only basic idea of course, it's can be developed from developers team of spamcop

And if domeone would fix the server involved, none of your suggested work-arounds would be necessary. Just noting that at present, there are three servers in the wourld identified as doing this crazy stuff .... two AT&T servers in Farelf's upstream and assumedly your ns1.bulsat.com (wondering why an e-mail server would be using a 'name server' badge?)

Link to comment
Share on other sites

Another consideration from the developer's point of view. Suppose the developer could fix the parser to check for additional header lines after the normal end of the header? How many additional lines should it check for? How does it distinguish a broken header line from an email that is discussing headers? There would be all those lines of code to find out if there are additional header lines. The spammer would have many more opportunities to 'trick' the parser.

The internet is still run on netiquette. Mail servers that do not use RFC compliant headers should be ignored. The server admins who are not using the correct headers should be the ones to whom complaints go. Spamcop parser is a tool that users can use to find out who should get reports. If the parser finds a non-compliant header, then the user should report it to the server admin who runs that server. They are the ones the spammer is exploiting.

Miss Betsy

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...