Jump to content

Error Message in Quick Data Report


csouter

Recommended Posts

Hi all,

I have just received two "SpamCop Quick Data Reports," the end sections of which are as follows:

Example #1:

Tracking message source:84.94.197.157: Cached whois for 84.94.197.157 : abuse[at]012.net.il

Using abuse net on abuse[at]012.net.il

abuse net 012.net.il = abuse[at]012.net.il

Using best contacts abuse[at]012.net.il

warning:Yum, this spam is fresh! Message is 1 hours old

84.94.197.157 not listed in dnsbl.njabl.org

84.94.197.157 not listed in dnsbl.njabl.org

84.94.197.157 not listed in cbl.abuseat.org

84.94.197.157 listed in dnsbl.sorbs.net ( 127.0.0.10 )

84.94.197.157 not listed in relays.ordb.org.

error:Can't send report: smtpEnvelope (2094556750.89be75ae[at]bounces.spamcop.net, abuse[at]012.net.il): smtpFrom: mail From 2094556750.89be75ae[at]bounces.spamcop.net: error (550 No expected reply from SMTP)May be saved for future reference:

http://www.spamcop.net/sc?id=z1188686644z1...101d183ad22db2z

Example #2:

Tracking message source:212.242.145.56: Cached whois for 212.242.145.56 : abuse[at]cybercity.dk

Using abuse net on abuse[at]cybercity.dk

abuse net cybercity.dk = abuse[at]cybercity.dk

Using best contacts abuse[at]cybercity.dk

warning:Yum, this spam is fresh! Message is 1 hours old

212.242.145.56 not listed in dnsbl.njabl.org

212.242.145.56 not listed in dnsbl.njabl.org

212.242.145.56 not listed in cbl.abuseat.org

212.242.145.56 not listed in dnsbl.sorbs.net

212.242.145.56 not listed in relays.ordb.org.

error:Can't send report: smtpEnvelope (2094211313.51c1051c[at]bounces.spamcop.net, abuse[at]cybercity.dk): smtpFrom: mail From 2094211313.51c1051c[at]bounces.spamcop.net: error (550 No expected reply from SMTP)May be saved for future reference:

http://www.spamcop.net/sc?id=z1188432391z6...0594c3e0301f30z

I'm just wondering if anyone can explain to me the meaning of (and, if possible, the reason for), the penultimate line in each of the above examples (i.e., the lines starting with "error:Can't send report:").

Thanks in advance.

Link to comment
Share on other sites

Hi, Chris!

<snip>

error:Can't send report: smtpEnvelope (2094211313.51c1051c[at]bounces.spamcop.net, abuse[at]cybercity.dk): smtpFrom: mail From 2094211313.51c1051c[at]bounces.spamcop.net: error (550 No expected reply from SMTP)May be saved for future reference:

http://www.spamcop.net/sc?id=z1188432391z6...0594c3e0301f30z

[/font]

I'm just wondering if anyone can explain to me the meaning of (and, if possible, the reason for), the penultimate line in each of the above examples (i.e., the lines starting with "error:Can't send report:").

Thanks in advance.

...Well, I don't know what a "Quick Data Report" is but -- odd, I don't get that at all and can't explain why you get different results than do I. For the second of your two tracking URLs, I see, in part:
Reports regarding this spam have already been sent:

Re: 212.242.145.56 (Administrator of network where email originates)

Reportid: 2094211313 To: abuse[at]cybercity.dk

If reported today, reports would be sent to:

Re: 212.242.145.56 (Administrator of network where email originates)

abuse[at]cybercity.dk

Re: 212.242.145.56 (Third party interested in email source)

spamcop[at]imaphost.com

Link to comment
Share on other sites

Hi, Chris!...Well, I don't know what a "Quick Data Report" is but -- odd, I don't get that at all and can't explain why you get different results than do I. For the second of your two tracking URLs, I see, in part:

I am seeing the reports have been sent for BOTH the links.

One question: Where is the following text coming from? That should not be part of the headers.

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

Link to comment
Share on other sites

error:Can't send report: smtpEnvelope (2094211313.51c1051c[at]bounces.spamcop.net, abuse[at]cybercity.dk): smtpFrom: mail From 2094211313.51c1051c[at]bounces.spamcop.net: error (550 No expected reply from SMTP)May be saved for future reference:

http://www.spamcop.net/sc?id=z1188432391z6...0594c3e0301f30z

I'm just wondering if anyone can explain to me the meaning of (and, if possible, the reason for), the penultimate line in each of the above examples (i.e., the lines starting with "error:Can't send report:").

The server providing SMTP servoce for the Reporting side of the house was not able to make contact with the targeted recipient's e-mail system/server. 5xx error generally indicating that no firther attempts will be tried to resend this e-mail.

Link to comment
Share on other sites

The server providing SMTP servoce for the Reporting side of the house was not able to make contact with the targeted recipient's e-mail system/server. 5xx error generally indicating that no firther attempts will be tried to resend this e-mail.

So, then, does this mean that the two reports in question have not actually been sent to the relevant ISPs?

Link to comment
Share on other sites

So, then, does this mean that the two reports in question have not actually been sent to the relevant ISPs?

Based on so many folks in the past getting upset at me providing a 'technical' answer to a question like this, somehow gathering that I'm calling them stupid, I'm not going to repeat the data already provided.

Link to comment
Share on other sites

So, then, does this mean that the two reports in question have not actually been sent to the relevant ISPs?
Seems like it, doesn't it? - hard to interpret any other way. Yet the tracked reports say they've been sent and no doubt your report history says the same. I can't imagine SC doesn't routinely handle 5xx rejections. Maybe the error message is new and the "reports sent" has always meant "reporting attempted"? I don't know.

Someone in the newgroups commented that the processing of quick reports or the messages relating to them had changed recently. The context was in relation to spam without a body (which shouldn't be a problem with quick reporting). Your spam has a problem with the body too (confusingly signified by "error: couldn't parse head" but you know the headers have already been parsed successfully). That message is caused by the final "deletion" line presumably inserted by your JunkSpy application - which would also encompass the answer to

One question: Where is the following text coming from? That should not be part of the headers.

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

The parser isn't designed to specifically handle those extra lines. Maybe they have nothing to do with anything but until some other user replicates your error:Can't send report: the possibility has stay open. Or until a Deputy with better knowledge comes by.
Link to comment
Share on other sites

Seems like it, doesn't it? - hard to interpret any other way. Yet the tracked reports say they've been sent and no doubt your report history says the same. I can't imagine SC doesn't routinely handle 5xx rejections. Maybe the error message is new and the "reports sent" has always meant "reporting attempted"? I don't know.

Parsing & Reporting system sits here --->

<---- SMTP system is over there .....

Parsing & Reorting systems "handed it off" to the SMTP server, thus "it was sent out" as far as the Reporting database is concerned.

Similar scenario without the 'error' is "ISP refuses reports" so copy went to /dev/null .. still counts as "Sent" in the database ....

Yes, it's obvious that the codebase is not written to totally handle the "error" condiition ... at least as far as showing status to us users ... one would like to thing that there was a 'bounce/rejection' noted, which will then show up eventually in the "sent/bounced - so now /dev/null'd" textual display, but ... not involved with that code ...

Link to comment
Share on other sites

Seems like it, doesn't it? - hard to interpret any other way. Yet the tracked reports say they've been sent and no doubt your report history says the same. I can't imagine SC doesn't routinely handle 5xx rejections. Maybe the error message is new and the "reports sent" has always meant "reporting attempted"? I don't know.

Someone in the newgroups commented that the processing of quick reports or the messages relating to them had changed recently. The context was in relation to spam without a body (which shouldn't be a problem with quick reporting). Your spam has a problem with the body too (confusingly signified by "error: couldn't parse head" but you know the headers have already been parsed successfully). That message is caused by the final "deletion" line presumably inserted by your JunkSpy application - which would also encompass the answer to The parser isn't designed to specifically handle those extra lines. Maybe they have nothing to do with anything but until some other user replicates your error:Can't send report: the possibility has stay open. Or until a Deputy with better knowledge comes by.

I'm not sure where that line comes from. I've seen it before, in the parsing screen and also when I have clicked "View entire message..." in the manual reporting screen. I think I'll send an email to JunkSpy Support and ask them whether or not JunkSpy inserts it. Any reply I get, I'll post here (or, at least, the gist of it). It never occurred to me that JunkSpy might be inserting it. Also, I have just had a quick look at an old Gmail spam that I reported a couple of days ago, and I notice that the line isn't there. (Gmail messages don't pass through the JunkSpy filter. JunkSpy only deals with messages that I download from my ISP. I have to report all Gmail spam manually by the copy-and-paste method). You have to set your mail client to use the loopback interface for email retrieval, (i.e., your client thinks that your mail server's name is "localhost," or "127.0.0.1" or whatever else you might happen to call your computer). JunkSpy then retrieves the email from the real server at your ISP, filters it and flags all the junk by inserting "JunkEmail:" into the message subject line. It also inserts a few other things at the end of the original headers. (Also, my ISP, Exetel (the best ISP in Australia), is now also using IronPort filtering on its servers. This inserts "[spam]" into the subject line as well. So far, the IronPort filtering has not given a single false positive). After flagging and delivering the message, JunkSpy is set to forward the offending message to SpamCop for reporting. Depending on whether or not I am able to be in front of my computer, I set JunkSpy to deliver to the "quick.xxxx" reporting address or the "submit.xxxx" reporting address. If it's forwarding to the "submit.xxxx" address, I then just sit back and wait for SpamCop to send the "SpamCop has accepted..." message. Otherwise, I wait for the "Quick Data Report" message to arrive at some later time.

Actually, I have never before seen the error I described in my OP, and the two examples I posted there are the only ones I have ever seen. (That doesn't mean that there may not be others. I don't read every single Quick Data Report that SpamCop sends back - I just do a quick check to see to whom the message was reported). At any rate, I have only seen the "can't send report" error twice, but I have reported thousands of spams over the last couple of years and never noticed it before. For that reason, I don't think the "Message was detected for deletion..." line has anything to do with the problem, as I have seen that line many times before when I clicked on "View entire message...." in the reporting screen. Who knows? Maybe we'll never see the error again... I seem to remember some other strange reporting error that I posted in here quite a few months back, maybe even a year ago. It only occurred once, I never saw another one, and no-one here could find any explanation as to why it happened. Now, I can't even remember what it was about!

Also, I think Steve (turetzsr) said something to the effect that he didn't know what a "Quick Data Report" was. A "Quick Data Report" is what you get back from SpamCop after a message has been "Quick Reported" (i.e., you have used "Quick" reporting). You can turn them on or off in your reporting preferences. If you've never done "Quick Reporting," you've probably never seen one. I seem to remember that you get them by default if you report spam from SpamCop WebMail.

I actually got into Don D'Minion's bad books for a while because I had forgotten to add certain keywords from the reports into my JunkSpy whitelist. :blush: JunkSpy started reporting the reports, and then the SpamCop "Bad Report" error messages! Boy, did I get into trouble! As we say in Australia, I think Don was just about ready to "have my guts for garters..." Anyway, it's all fixed, now. :D

Anyway, thanks to everyone for all your input. I always appreciate very much how everyone here is always so willing to help on even the most trivial problem (such as this one, hehe)... You are really a great bunch!

Link to comment
Share on other sites

I'm not sure where that line comes from. I've seen it before, in the parsing screen and also when I have clicked "View entire message..." in the manual reporting screen. ...
Wherever it comes from, it's the bottom line that causes the error: couldn't parse head in the two examples you posted.

All to do with MIME boundaries. When the header contains (say)

boundary="----=_NextPart_000_0008_01C73456.7BE140A0"

as part of the "Content-type:" then the end of the message must be designated by

------=_NextPart_000_0008_01C73456.7BE140A0--

(as declared, with extra leading & trailing dashes) - nothing else. If there is anything else, the parser goes into its "oops" routine, signified by a parse message of 1

Finding links in message body

Parsing text part

error: couldn't parse head

Message body parser requires full, accurate copy of message

Yours have the last line of

------------------------ End of deleted message ----------------------

1The terminology "couldn't parse head" is obscure in such a case but perhaps makes more sense in other cases which generate the same message - essentially being when the demarkation of the message parts is absent or otherwise not standard. Even so, error: couldn't parse body would be a little more helpful in many/most cases and to more users, IMO.

Not that any of that should matter for a quick report which supposedly doesn't look at the body ...

Link to comment
Share on other sites

Wherever it comes from, it's the bottom line that causes the error: couldn't parse head in the two examples you posted.

All to do with MIME boundaries. When the header contains (say)

boundary="----=_NextPart_000_0008_01C73456.7BE140A0"

as part of the "Content-type:" then the end of the message must be designated by

------=_NextPart_000_0008_01C73456.7BE140A0--

(as declared, with extra leading & trailing dashes) - nothing else. If there is anything else, the parser goes into its "oops" routine, signified by a parse message of 1

Finding links in message body

Parsing text part

error: couldn't parse head

Message body parser requires full, accurate copy of message

Yours have the last line of

------------------------ End of deleted message ----------------------

1The terminology "couldn't parse head" is obscure in such a case but perhaps makes more sense in other cases which generate the same message - essentially being when the demarkation of the message parts is absent or otherwise not standard. Even so, error: couldn't parse body would be a little more helpful in many/most cases and to more users, IMO.

Not that any of that should matter for a quick report which supposedly doesn't look at the body ...

We seem to be talking about two different errors, here. In my OP, I was referring to the can't send report error, not the couldn't parse head error. I wasn't concerned about that, as long as the source of the message was able to be found. I was much more concerned that the report may not have been sent to the abuse desk of the appropriate ISP.

I must defer to your superior knowledge on the couldn't parse head error, but it still doesn't explain why I have only seen two occurrences of the can't send report error out of thousands of spams I have successfully reported over the last couple of years, and those errors have only occurred in the last few days.

Incidentally, the lines to which you are referring were not included in my OP. You would have had to visit the tracking URL to see them. I didn't include them, because I didn't think they were relevant to the can't send report error, even though they might well be relevant to the couldn't parse head error.

As far as I am able to ascertain, nothing that JunkSpy inserts into my reported spams has ever caused an error that would prevent SpamCop from sending a report.

Nevertheless, as I said in my previous post, I'll write to JunkSpy Support and find out whether or not JunkSpy inserts the lines to which you are referring. When they get back to me, (usually on the next working day in California), I'll get back to you with the results of my enquiries.

Link to comment
Share on other sites

We seem to be talking about two different errors, here. In my OP, I was referring to the can't send report error, not the couldn't parse head error. I wasn't concerned about that, as long as the source of the message was able to be found. I was much more concerned that the report may not have been sent to the abuse desk of the appropriate ISP. ...
Yep, talking about both - sorry to wander (maybe) OT and confuse you, etc and yes, *this* one can only be seen in your tracking URLs, not in the text of your post.

Your "real" error message remains an abiding mystery which may or may not prove to be something "controllable" - I'm tending to think a momentary glitch myself, akin to the other inexplicable error you mentioned, but we just don't know at this stage. Do wrist watches stop working when you wear them? :P

Link to comment
Share on other sites

I haven't written to JunkSpy Support yet, but the following is the source of a message I received in my mailbox at my ISP in the early hours of this morning. This source was copied from SeaMonkey Mail, pasted into a text file, and the nonsense text, HTML code and GIF binary code snipped out. As you can see, the lines about the message being detected for deletion are nowhere to be seen. The last 10 lines in the header were added by JunkSpy and by Avast! Antivirus. Also, the subject line has had JunkEmail: added to it by JunkSpy and [spam] added to it by my ISP's IronPort filtering.

From - Thu Jan 11 08:00:19 2007

X-Account-Key: account2

X-UIDL: 00000142457f7052

X-Mozilla-Status: 0001

X-Mozilla-Status2: 00000000

X-Mozilla-Keys:

Return-path: <August[at]estructurasalba.e.telefonica.net>

Envelope-to: <x>

Delivery-date: Thu, 11 Jan 2007 01:10:23 +1100

Received: from [10.0.0.25] (helo=soapberry.exetel.com.au)

by chestnut.exetel.com.au with esmtp (Exim 4.63)

(envelope-from <August[at]estructurasalba.e.telefonica.net>)

id 1H4e9n-0005JS-1V

for <x>; Thu, 11 Jan 2007 01:10:23 +1100

Received: from 60.0.233.220.exetel.com.au ([220.233.0.60] helo=mscip01.mailscan.net.au)

by soapberry.exetel.com.au with esmtp (Exim 4.63)

(envelope-from <August[at]estructurasalba.e.telefonica.net>)

id 1H4e9m-0002Jm-TO

for <x>; Thu, 11 Jan 2007 01:10:22 +1100

Received: from adsl-6-32-117.tys.bellsouth.net ([65.6.32.117])

by mscip01.mailscan.net.au with ESMTP; 11 Jan 2007 01:10:21 +1100

X-IronPort-Anti-spam-Filtered: true

X-IronPort-Anti-spam-Result: AlD4AIaCpEVBBiB1NWdsb2JhbACCToNi

Subject: JunkEmail: [spam] offshore

X-IronPort-AV: i="4.13,167,1167570000";

d="gif'147?scan'147,208,217,147"; a="8802563:sNHT61983804"

Received: from ABUUW (unknown [118.170.52.37])

by estructurasalba.e.telefonica.net with ESMTP id EF2554394A3A

for <<x>>; Wed, 10 Jan 2007 09:10:49 -0500 (GMT)

Message-ID: <000f01c734c1$1038aa30$00000000[at]PC988720711140>

From: "helpful yes" <August[at]estructurasalba.e.telefonica.net>

To: <x>

Date: Wed, 10 Jan 2007 09:10:20 -0500

MIME-Version: 1.0

Content-Type: multipart/related;

type="multipart/alternative";

boundary="----=_NextPart_000_000B_01C73497.2762A230"

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-Filtered: Yes

X-Junkmail: Yes

X-JunkSpy-Clue: Found 0$00000000[at] in message Header

X-JunkSpy-Detector: For more information see "Junk Mailers" detector.

X-JunkSpy-Comment: If this message has incorrectly been identified as junk, please forward to notjunk[at]junkspy.com

X-JunkSpy-Filtered: Yes

X-JunkSpy-Junkmail: Yes

X-JunkEmail: Yes

X-JunkSpy-Signature: 310_20070108_0

X-Antivirus: avast! (VPS 0702-0, 2007-01-09), Inbound message

X-Antivirus-Status: Clean

------=_NextPart_000_000B_01C73497.2762A230

Content-Type: multipart/alternative;

boundary="----=_NextPart_001_000C_01C73497.2762A230"

------=_NextPart_001_000C_01C73497.2762A230

Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

<Nonsense Text Snipped>

------=_NextPart_001_000C_01C73497.2762A230

Content-Type: text/html;

charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=3DContent-Type content=3D"text/html; =

charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>

<STYLE></STYLE>

</HEAD>

<BODY bgColor=3D#ffffff>

<HTML Body Content Snipped>

</BODY></HTML>

------=_NextPart_001_000C_01C73497.2762A230--

------=_NextPart_000_000B_01C73497.2762A230

Content-Type: image/gif;

name="ware.gif"

Content-Transfer-Encoding: base64

Content-ID: <000a01c734c1$1038aa30$00000000[at]PC988720711140>

<Binary GIF Code Snipped>

------=_NextPart_000_000B_01C73497.2762A230--

Now, if you visit the following URL:

http://www.spamcop.net/sc?id=z1189079738zd...0978e752392cadz

you can see the "message detected for deletion" lines.

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

<Message content>

------------------------ End of deleted message ----------------------

The only stuff I snipped out of the above message source was the actual content within the boundaries of the different sections of the message. (Purely to save space).

Now, I really don't know how they got there! They are not in the source of the message as it was delivered to SeaMonkey by JunkSpy. BTW, JunkSpy forwards the message to SpamCop as a separate process, i.e., the forwarded message doesn't show up in my SeaMonkey "Sent Mail" folder. SeaMonkey Mail's filters are set to forward any messages with JunkEmail: or [spam] in the subject line to KnujOn, another spam reporting organisation, of which some of you may have heard.

So, apart from the snipped content, how does my message source compare with what SpamCop shows at the URL given above?

It's a real mystery, isn't it?

Link to comment
Share on other sites

Certainly got me stumped Chris. I didn't get any Google hits on the "following message ..." phrase either (should be one now/soon but just pointing to your post).

Well, I still haven't written to JunkSpy Support, but, after having performed a little experiment, I am now starting to think that JunkSpy is adding the lines in question.

I actually did something that we aren't supposed to do: I lodged a DUPLICATE spam REPORT! Tsk, tsk... <Sheepish Grin>...

I had to go out for about an hour and I've just returned home. Because I had to go out, I set JunkSpy to forward junk to my quick.xxxx address. Sure enough, I haven't received a single spam in over 8 hours, and then, as soon as I go out, I get one!

Now, when I got back, I saw the spam (the usual Rx junk with a GIF), and checked SpamCop to see whether or not the report had been made yet. It had. And, it showed the "...message for deletion..." lines.

So, I got SeaMonkey Mail to "View Message Source," then did the old copy-and-paste trick into the SpamCop manual reporting box, clicked on "Process spam," waited for the message to be parsed, checked all the boxes for all the intended report recipients and then clicked on "Send spam Report(s) Now."

Then I went to the "Past Reports" tab, clicked on "View recent reports..." and looked at the report I had just made. The "...message for deletion..." lines weren't there.

Here is the URL for the automatically-generated report:

http://www.spamcop.net/sc?id=z1189603569zc...80453a0a6d4104z

Now, here is the URL for the manually-generated copied-and-pasted-into-the-dialog-box report:

http://www.spamcop.net/sc?id=z1189606499zd...e15744695ae8aaz

I now think that JunkSpy might be adding the "...message for deletion..." lines when it forwards the message to SpamCop, but not when it flags the message as "JunkEmail:" and delivers it to my inbox. So, when I copy-and-paste the spam source, the SpamCop parser doesn't see those added lines, and therefore there is no "can't parse header" error message.

I'm now going to try another experiment (I think I might change my name to Frankenstein, hehe)! I'll change my settings so that JunkSpy will automatically forward messages to KnujOn instead of SpamCop. (JunkSpy will forward the junk to ONE extra address only.) Then, I'll change my SeaMonkey Mail settings so that the junk will be automatically forwarded to SpamCop instead of KnujOn. (It won't be easy doing this, because the current version of SeaMonkey crashes when I try to edit an existing filter. I'll have to delete the JunkSpy filter and re-create it). :( If the "...message for deletion..." lines are in the message for KnujOn, it won't matter: KnujOn don't need headers at all, so it doesn't matter if they're mangled. KnujOn is looking for the links contained within the messages themselves.

If the "...message for deletion..." lines are missing from future reports, then we'll know where the blame lies, and I'll be able to let the JunkSpy developers know about it. Maybe they'll fix it, maybe they won't. After all, JunkSpy was produced at a time when the prevailing attitude was simply to filter spam out and delete it. The upsurge of interest in reporting spam before deleting it is, to my knowledge anyway, comparatively recent.

Actually, I did ask them once before, whether or not it would be possible to have JunkSpy forward the spams to more than one reporting address, and the reply was that they didn't want users to run the risk of being banned by their own ISPs for spamming, which could happen if the spam were forwarded to too many different addresses simultaneously. That's their point-of-view, and I have to respect that. More and more ISPs all over the world, but certainly in the US and Australia, are banning users, or at least, blocking them from sending spam, by filtering outgoing messages at their SMTP servers. This amounts to censorship of internet communications, but that's another issue...

I actually got blocked by my own ISP once, when I accidentally reported a message from my SpamCop WebMail "sent-mail" folder, instead of reporting the original. The block lasted for 3 hours from when I filled in a web form certifying that my computer had not been compromised by spam-sending malware. During those 3 hours, I was completely unable to access the internet, except to go the the web form. Anyway, it was my own stupid fault for clicking on the wrong message for reporting, and I actually appreciated Exetel's action. Exetel's action was quick (about 6 hours after the report would have been sent) and it made me think very carefully about the consequences of carelessness. I only wish more ISPs, especially those outside Australia, would do the same.

Exetel is very serious about the issue, because other Australian ISPs have already been successfully prosecuted for allowing spam to be sent from their servers. The Australian Federal Government has passed quite strong anti-spam legislation; unlike the US CAN-spam Act, the Australian law has teeth! ISPs can be held responsible along with their users!

Anyway, enough rambling on. I'll let you know the result of my new experiment once I get it up and running.

I'll get back to you some time tomorrow.

Link to comment
Share on other sites

... I actually did something that we aren't supposed to do: I lodged a DUPLICATE spam REPORT! Tsk, tsk... <Sheepish Grin>...
Um, I think you could have cancelled the second one - the cancelled report has all the essential data.
... I'm now going to try another experiment (I think I might change my name to Frankenstein, hehe)!
Put ... the candle ... back!
Exetel is very serious about the issue, because other Australian ISPs have already been successfully prosecuted for allowing spam to be sent from their servers.
I didn't know that. The Oz spam Act specifically absolves ISPs ("the provider") but I've always though that was thin ice if they could be shown to "have knowledge" of their users' activities - even unsubstantiated complaints (because the ISP has the ability to substantiate or refute any well-documented complaint). But IANAL and it seemed a bit too rational to be thinking that way - anyway, it is well known that any bureaucracy will host a "vigilance committee" dedicated to the elimination of any vestige of competency. Are you saying the ACMA vigilance committee has actually eliminated itself before completing its function? How dysfunctional!
Link to comment
Share on other sites

<snip>

Also, I think Steve (turetzsr) said something to the effect that he didn't know what a "Quick Data Report" was. A "Quick Data Report" is what you get back from SpamCop after a message has been "Quick Reported" (i.e., you have used "Quick" reporting). You can turn them on or off in your reporting preferences. If you've never done "Quick Reporting," you've probably never seen one.

<snip>

...Exactly so! Thanks for the explanation, Chris. :) <g>
Link to comment
Share on other sites

error:Can't send report: smtpEnvelope (2094556750.89be75ae[at]bounces.spamcop.net, abuse[at]012.net.il): smtpFrom: mail From 2094556750.89be75ae[at]bounces.spamcop.net: error (550 No expected reply from SMTP)
The technical answer to your question is no, the reports were not sent.

The "Quick data report" tells the tale.

Our outbound servers don't use any fancy mail software. They make one try to deliver the email and then move on to the next one.

The act of handing off the spam report to the mail system ends the process for SpamCop. It has done it's job and the report is considered to have been sent as far as the stats and report history are concerned. The reports were charged against the source IP for blocking purposes.

I don't think abuse[at]012.net.il ever gets any mail. They write to me occasionally and my replies always bounce. I flagged their address as bouncing so we won't even try to send reports to them anymore. That will prevent future confusion.

X-Postfix-Sender: rfc822; service[at]admin.spamcop.net

Arrival-Date: Thu, 11 Jan 2007 12:38:08 -0700 (MST)

<abuse[at]012.net.il>: Host or domain name not found. Name service error for

name=012.net.il type=A: Host found but no data record of requested type

>- error:Can't send report: ... abuse[at]cybercity.dk)

I think that one was just a temporary glitch. It's working OK now.

- Don D'Minion - SpamCop Admin -

I don't know what a "Quick Data Report" is
If you want to send me your login username, I'll be happy to set you up with "quick" reporting.

- Don D'Minion - SpamCop Admin -

service[at]admin.spamcop.net

I don't have any idea why my replies all get bundled together like this.

Link to comment
Share on other sites

One question: Where is the following text coming from? That should not be part of the headers.

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

You can ignore that. Various mail clients and spam/virus checkers put all sorts of odd comments above the headers.

As long as there isn't a blank line at the end of the comments, they become part of the headers and the parse ignores them.

No harm, no foul.

- Don -

Or why this post wasn't bundled with the other two. All very strange.

Link to comment
Share on other sites

<snip>
I don't know what a "Quick Data Report" is
If you want to send me your login username, I'll be happy to set you up with "quick" reporting.

- Don D'Minion - SpamCop Admin -

service[at]admin.spamcop.net

...No, thank you, Don. I consider it too great a risk of reporting my provider (employer) -- they've made a few changes in the incoming e-mail server and hand-off servers in the past few years that has me extremely gun-shy, as I would have reported them as the source of spam (and may even have inadvertently done so once) if I had not been watching the parse results carefully.

<snip>

I don't have any idea why my replies all get bundled together like this.

<snip>

Or why this post wasn't bundled with the other two. All very strange.

...It's a feature of the Forum software. If you post more than once during a certain (short) period of time and no one posts between any two of your posts, they get concatenated.

...There's another forum thread or two that discusses this in a bit more detail but I doubt my ability to find them quickly....

Link to comment
Share on other sites

Hi, all!

As promised, I wrote to JunkSpy Support, with the following results:

=========================================================================

(Slightly) edited excerpt from message to JunkSpy Support:

---------------------------------------------------------

I have noticed that some extra lines have been added to the

original source of messages forwarded by JunkSpy to SpamCop.

At the beginning of the forwarded message, the following lines

are inserted (not including the lines of stars):

*************************************************************************

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

At the end of the forwarded message, the following line is inserted:

------------------------ End of deleted message ----------------------

*************************************************************************

Are you able to confirm whether or not JunkSpy is adding these lines to

the forwarded messages?

(Slightly) edited excerpt from JunkSpy Support's reply:

------------------------------------------------------

Junk Spy does add that information to any message it forwards, in

part to help assure the recipient that this isn't just real spam that

your machine is sending out intentionally.

There is no way to turn off that addition (or change the text of it)

in the current version.

=========================================================================

So, to those of you who suspected that JunkSpy might be inserting the lines

in question: Well done!

For the last two days, (after Steven Underwood first brought those lines to

my notice), my automatic forwarding arrangement between SeaMonkey Mail and

JunkSpy has been reversed. I now have JunkSpy forward all flagged spam to

KnujOn, whilst SeaMonkey Mail is now forwarding all flagged spam to SpamCop.

So far, the SpamCop "can't parse header..." error has not returned.

However, the "can't send report..." error occurred again today. Out of four

"Quick Data Reports" I have received so far today, only one has exhibited the

error.

The report content, (including the Tracking URL), is as follows:

From - Sat Jan 13 03:31:12 2007

X-Account-Key: account3

X-UIDL: 0000011f457f72a7

X-Mozilla-Status: 0001

X-Mozilla-Status2: 00000000

X-Mozilla-Keys:

Return-path: <user.<x>[at]bounces.spamcop.net>

Envelope-to: <x>

Delivery-date: Sat, 13 Jan 2007 03:26:41 +1100

Received: from [10.0.0.25] (helo=soapberry.exetel.com.au)

by chestnut.exetel.com.au with esmtp (Exim 4.63)

(envelope-from <user.<x>[at]bounces.spamcop.net>)

id 1H5PEn-0001f0-KL

for <x>; Sat, 13 Jan 2007 03:26:41 +1100

Received: from 60.0.233.220.exetel.com.au ([220.233.0.60] helo=mscip01.mailscan.net.au)

by soapberry.exetel.com.au with esmtp (Exim 4.63)

(envelope-from <user.<x>[at]bounces.spamcop.net>)

id 1H5PEn-0004yj-HS

for <x>; Sat, 13 Jan 2007 03:26:41 +1100

Received: from sc-smtp3-bulkmx.soma.ironport.com ([204.15.82.124])

by mscip01.mailscan.net.au with ESMTP; 13 Jan 2007 03:26:40 +1100

DomainKey-Signature: s=devnull; d=spamcop.net; c=nofws; q=dns; b=z3jvo5APVVgE0lNlzUKDtxHog1NcvZKHblbwc1atn3x90OH/AvFwXRO6FMEFCcr0DpX6DPBRt46vfXKSKjHL7PKKTK8v6IDmi3FDho2ql3fxudfkNFASFQkrEuKB/FoD;

Received: from sc-app6.spamcop.net ([204.15.82.25])

by sc-smtp3-bulkmx.soma.ironport.com with SMTP; 12 Jan 2007 08:25:57 -0800

From: SpamCop <spamcop[at]devnull.spamcop.net>

To: Christopher E. Souter <<x>>

Subject: [spamCop] Quick reporting data

Precedence: list

Message-ID: <qr45a7b695g2af0[at]msgid.spamcop.net>

Date: Fri, 12 Jan 2007 16:25:57 GMT

X-Mailer: http://www.spamcop.net/ v#612

SpamCop.net

Here are the results of your submission:

Processing spam: From: reginald[at]funeasy.biz

Subject: JunkEmail: [spam] Best love dr[at]gs at best store!

0: Received: from [10.0.0.25] (helo=soapberry.exetel.com.au) by chestnut.exetel.com.au with esmtp (Exim 4.63) (envelope-from <reginald[at]funeasy.biz>) id 1H5N6X-0004XT-UP for csouter[at]exemail.com.au; Sat, 13 Jan 2007 01:10:01 +1100

Internal handoff at exetel.com.au

1: Received: from 60.0.233.220.exetel.com.au ([220.233.0.60] helo=mscip01.mailscan.net.au) by soapberry.exetel.com.au with esmtp (Exim 4.63) (envelope-from <reginald[at]funeasy.biz>) id 1H5N6X-0003gJ-QD for csouter[at]exemail.com.au; Sat, 13 Jan 2007 01:10:01 +1100

Hostname verified: 60.0.233.220.exetel.com.au

exetel.com.au received mail from exetel.com.au ( 220.233.0.60 )

2: Received: from 84-217-95-243.tn.glocalnet.net (HELO friend) ([84.217.95.243]) by mscip01.mailscan.net.au with ESMTP; 13 Jan 2007 01:09:59 +1100

No unique hostname found for source: 84.217.95.243

exetel.com.au received mail from sending system 84.217.95.243

Tracking message source:84.217.95.243: Cached whois for 84.217.95.243 : abuse[at]utfors.se hostmaster[at]glocalnet.net

Using abuse net on abuse[at]utfors.se

abuse net utfors.se = abuse[at]utfors.se

Using abuse net on hostmaster[at]glocalnet.net

abuse net glocalnet.net = abuse[at]glocalnet.net, abuse[at]utfors.se

Using best contacts abuse[at]glocalnet.net abuse[at]utfors.se

warning:Yum, this spam is fresh! Message is 2 hours old

84.217.95.243 not listed in dnsbl.njabl.org

84.217.95.243 not listed in dnsbl.njabl.org

84.217.95.243 listed in cbl.abuseat.org ( 127.0.0.2 )

84.217.95.243 is an open proxy

error:Can't send report: smtpEnvelope (2097201076.2061eca5[at]bounces.spamcop.net, abuse[at]utfors.se): smtpFrom: mail From 2097201076.2061eca5[at]bounces.spamcop.net: error (550 No expected reply from SMTP)error:Can't send report: smtpEnvelope (2097201263.2c5d1ce4[at]bounces.spamcop.net, abuse[at]glocalnet.net): smtpFrom: mail From 2097201263.2c5d1ce4[at]bounces.spamcop.net: error (550 No expected reply from SMTP)May be saved for future reference:

http://www.spamcop.net/sc?id=z1190641371zd...76ef25db8dea23z

Now, when "Quick Reporting" is enabled, the only report(s) sent are to the abuse desk(s) of the network from which the message originated. When I receive the "Quick Data Report," I reopen the source of the original message, copy-and-paste it into the SpamCop dialog box, wait for the message to be parsed, uncheck the abuse addresses used in the "Quick Report," check all the other addresses to which I wish to send the report and then click on either "Send spam Report(s) Now" or "Cancel," depending on whether or not those "other" addresses actually exist.

Now, when I re-reported the message referred to in the above Tracking URL, I made sure that all the addresses were checked, (including the originating address), SpamCop returned a message to say that the reports had all been sent.

The mystery remains!

Link to comment
Share on other sites

...Someone in the newgroups commented that the processing of quick reports or the messages relating to them had changed recently. ...
Latest on that front, seems that is not so, there is no error for a quick report with no body (tracking URL supplied there with the "occular proof" and, as originally understood, the parser goes nowhere near any differentiated email body). Which means no error can occur from anything to do with body content when "QR"ing either. Don's response (above) didn't precisely address that - but did say not to be concerned.

For the sake of posterity, with others perhaps viewing parts of this topic without taking into account the primary context of quick reporting - for standard reporting I would not be so laid back about the effect of the inserted lines

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

and

------------------------ End of deleted message ----------------------

The last line (which is the only concern) will prevent parsing of the body and, in general, you routinely invoke error conditions at your peril ("regression testing" be damned I've seen too many unpredictable results elsewhere, stemming from error conditions - YMMV).

Link to comment
Share on other sites

Latest on that front, seems that is not so, there is no error for a quick report with no body (tracking URL supplied there with the "occular proof" and, as originally understood, the parser goes nowhere near any differentiated email body). Which means no error can occur from anything to do with body content when "QR"ing either. Don's response (above) didn't precisely address that - but did say not to be concerned.

For the sake of posterity, with others perhaps viewing parts of this topic without taking into account the primary context of quick reporting - for standard reporting I would not be so laid back about the effect of the inserted lines

The following message was detected for deletion.

------------------------ Beginning of deleted message -------------------

and

------------------------ End of deleted message ----------------------

The last line (which is the only concern) will prevent parsing of the body and, in general, you routinely invoke error conditions at your peril ("regression testing" be damned I've seen too many unpredictable results elsewhere, stemming from error conditions - YMMV).

I agree with you, but see my latest post above.

Link to comment
Share on other sites

... For the last two days, (after Steven Underwood first brought those lines to my notice), my automatic forwarding arrangement between SeaMonkey Mail and JunkSpy has been reversed. I now have JunkSpy forward all flagged spam to

KnujOn, whilst SeaMonkey Mail is now forwarding all flagged spam to SpamCop.

So far, the SpamCop "can't parse header..." error has not returned.

However, the "can't send report..." error occurred again today. Out of four

"Quick Data Reports" I have received so far today, only one has exhibited the

error. ...The mystery remains!

Hi Chris! Well, it is now established that the JunkSpy lines cause no problem at all for quick reporting. The intermittent "can't send report ....", as you have conclusively demonstrated, is not related and may just be a glitch. Are you just "unlucky at technology"? (beats being "unlucky at personal hygiene" I always say :D). I don't think so - maybe you are just more observant than most. Anyway, you've posted full details of the problem and if anyone has a more constructive view of the situation I am sure they will contribute it.

[Just to clarify, originally 2 separate posts, the first "above" Chris's last previous post, the next "after" it but concatenated automatically into the latter position by the BB "feature" relating to consecutive posts in a short time]

I agree with you, but see my latest post above.
Geez, what a slave driver! :D See my (later) post above (we could keep this up for a while).
Link to comment
Share on other sites

Hi Chris! Well, it is now established that the JunkSpy lines cause no problem at all for quick reporting. The intermittent "can't send report ....", as you have conclusively demonstrated, is not related and may just be a glitch. Are you just "unlucky at technology"? (beats being "unlucky at personal hygiene" I always say :D). I don't think so - maybe you are just more observant than most. Anyway, you've posted full details of the problem and if anyone has a more constructive view of the situation I am sure they will contribute it.

Geez, what a slave driver! :D See my (later) post above (we could keep this up for a while).

Who, may I know, is "lucky at technology?" (Or is that lucky[at]technology.com)? I've never been "unlucky at personal hygeine," (or even unlucky[at]personalhygeine.com), either, hehe! :D

I've really opened a can of worms, haven't I? I didn't really mean to. (Maybe da debil made me do it)!

But, I have to say, what I thought was a trivial error seems to have turned into a major investigation!

See my (later) post above (we could keep this up for a while).

We should really "get a life."

But, then again, maybe I think Wazoo is right - "What life?"

BTW, this post is even later than yours. :P

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...