Jump to content

ISP filtering mail and marking Spam messages


robrub

Recommended Posts

Hi,

My ISP is filtering mails with SpamAssassin and mark spam messages with *****spam***** in the suject of the mail. It doesn't change the header of the message but adds spam filtering information to the end of the header and trunks the body of the message (leaves just a small part in text form).

I wonder if SpamCop will be able to "digest" these messages and if I should go on reporting these spam messages.

Best regards

Robby

Link to comment
Share on other sites

My ISP is filtering mails with SpamAssassin and mark spam messages with *****spam***** in the suject of the mail. It doesn't change the header of the message but adds spam filtering information to the end of the header and trunks the body of the message (leaves just a small part in text form).

I wonder if SpamCop will be able to "digest" these messages and if I should go on reporting these spam messages.

You should get an official ruling from deputies[at]spamcop.net. Please report back here any response you get.

The only part that might cause me problems with this (I am not an official at spamcop, so my guess is as good as anybodys) would be the trunking of the body. Spamcop wants to submit the entire spam message to the administrator. This could be considered modification of the spam.

Link to comment
Share on other sites

...I wonder if SpamCop will be able to "digest" these messages and if I should go on reporting these spam messages. ...
Hi Robby - the parser should be able to resolve the sending IP (unless the truncation interferes with mime boundaries which used to cause it problems (haven't heard any reports of that sort of problem recently though, maybe it can cope now). Of course any spamvertized links are likely to go with the truncation. Since the "feeding the BL" main function is not affected I wouldn't think that would matter much to you. If you quick/VER report the body content is not a factor in any event [sp corrected]. Suggest you try it, post a Ttracking URL here if you have any doubts.

You should get an official ruling from deputies[at]spamcop.net. Please report back here any response you get.

The only part that might cause me problems with this (I am not an official at spamcop, so my guess is as good as anybodys) would be the trunking of the body. Spamcop wants to submit the entire spam message to the administrator. This could be considered modification of the spam.

Truncation might be a factor but does quick reporting preserve the whole spam? Modifying the subject line is not an issue IMO - AT&T did that for years.

[added on edit - truncation - hang about, SpamCop does that itself even in "full reporting" - anything over 50k gets lopped with a "Truncated by Spamcop" notation added at the end. Maybe prudent to check with Deputies anyway but the evidence indicates to me there is not much risk. SpamCop "Full message" is not pristine forensic evidence in any event. The concern is reporter forgery and programmic alteration by the ISP doesn't come into it - except to muddy the waters a touch. IMO]

Link to comment
Share on other sites

My ISP is filtering mails with SpamAssassin and mark spam messages with *****spam***** in the suject of the mail. It doesn't change the header of the message but adds spam filtering information to the end of the header and trunks the body of the message (leaves just a small part in text form).

It sounds like you should be OK reporting those. As long as SpamAssassin is just adding informational headers and not changing the original spam headers to "localhost" info, SpamCop can find the true source of the spam.

The fact that your server is altering the body text is irrelevant. The only modifications SpamCop policy forbids is material alterations by the user after he gets the spam.

If you have any questions, send me email with the tracking URL from the top of the page when you process one of the spams and I'll be happy to take a look.

- Don D'Minion - SpamCop Admin - service[at]admin.spamcop.net

Link to comment
Share on other sites

The only modifications SpamCop policy forbids is material alterations by the user after he gets the spam.

That's not quite the "letter of the law" regarding material changes. Here's what's in the FAQ:

Do not make any material changes to spam before submitting or parsing which may cause SpamCop to find a link, address or URL it normally would not, by design, find.

So, some reasonable changes are actually allowed as long as they won't cause the reporting system to "find" links, etc. that it wouldn't by parsing the unmodified message.

This is a distinction *with* a difference. I frequently remove lines from the headers of messages that I report. The lines I remove were *not* present in the original email as it arrived at the server(s) accepting email for me. They are lines that, when reported back to the ISP (and possibly the spammer, if the ISP decides to pass the report along to them), would identify too much information about the filtering technology that's used by my email providers.

When this comes up in the forums, I post replies like this to make sure that my rights of self-protection (as well as those of other SC users) aren't restricted by an incomplete reading of the "Rules." Some users are skeptical about what I'm claiming, but it's there in plain English, and my "reading comprehension" scores on all those standardized tests I took as a youth were always off the charts. You can't convince me that those words in the FAQ mean anything else. :)

DT

Link to comment
Share on other sites

Just so there's no confusion... I don't like jailhouse lawyers sticking their nose in where it doesn't belong.

That's not quite the "letter of the law" regarding material changes. Here's what's in the FAQ:

So, some reasonable changes are actually allowed as long as they won't cause the reporting system to "find" links, etc. that it wouldn't by parsing the unmodified message.

Please note that my comment referred to changes made by the server software *before* the user gets the spam. If the ISP's SpamAssassin is adding headers, or adding, removing, or altering body text before delivering it to the user, then those alterations are OK under our rules. It's not something the user is doing to fool SpamCop.

This is a distinction *with* a difference. I frequently remove lines from the headers of messages that I report. The lines I remove were *not* present in the original email as it arrived at the server(s) accepting email for me. They are lines that, when reported back to the ISP (and possibly the spammer, if the ISP decides to pass the report along to them), would identify too much information about the filtering technology that's used by my email providers.

If you're removing filtering information that might reveal your identity, then you're OK under the rules.

If you're removing or altering your server's "Received" lines that show your network getting the spam from outside, then you're in for a rude awakening when I catch you.

When this comes up in the forums, I post replies like this to make sure that my rights of self-protection (as well as those of other SC users) aren't restricted by an incomplete reading of the "Rules." Some users are skeptical about what I'm claiming, but it's there in plain English, and my "reading comprehension" scores on all those standardized tests I took as a youth were always off the charts. You can't convince me that those words in the FAQ mean anything else. :)

Goody for you, but next time, make sure you have your facts straight first. You missed the fact that I was talking about server changes and not user changes. Your comments here were completely inappropriate.

- Don D'Minion - SpamCop Admin -

Link to comment
Share on other sites

Hi,

Thanks for your messages. I have sent a messgae to deputies. I'll post their answer when I get it.

spam Assassin filter modifies the subject of the message (adds *****spam***** ) and cuts the body of the initial message and adds the filtering information instead. The header information is intact (except the subject and the added "X-spam" lines). I have cut and pasted one message for you to see.

The paragraph with the "Previsualisation du contenu" is the only part that stays from the initial message. The rest of the initial message is cut off by SpamAssassin. The other paragraphs of the message are added by SpamAssassin for information.

From: - Mon Oct 23 15:51:54 2006

X-Account-Key: account1

X-UIDL: 1161610355.2503.mail1.privianet.com,S=4737

X-Mozilla-Status: 0000

X-Mozilla-Status2: 00000000

Return-Path: <adamb000apsf[at]btinternet.com>

Delivered-To: robert[at]rubinstayn.com

Received: (qmail 2480 invoked from network); 23 Oct 2006 13:32:34 -0000

Received: from mx1.privianet.com (85.233.194.121) by dns.privianet.com with SMTP; 23 Oct 2006 13:32:34 -0000

Received: (qmail 23060 invoked by uid 509); 23 Oct 2006 13:32:36 -0000

Received: from adamb000apsf[at]btinternet.com by priviamx1.privianet.com by uid 508 with qmail-scanner-1.22 (ClamAV 0.88.4/2014. SpamAssassin: 3.1.6. Clear:RC:0(58.77.156.114):SA:0(?/?):. Processed in 8.915933 secs); 23 Oct 2006 13:32:36 -0000

Received: from localhost by priviamx1.privianet.com with SpamAssassin (version 3.1.6); Mon, 23 Oct 2006 15:32:36 +0200

From: Maura <adamb000apsf[at]btinternet.com>

To: <robert[at]rubinstayn.com>

Subject: *****spam***** Shemale posing in stockings

Date: Mon, 23 Oct 2006 22:25:18 -0400

Message-Id: <1031150118.20061023222518[at]thcejx>

X-spam-Flag: YES

X-spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on priviamx1.privianet.com

X-spam-Status: Yes, score=25.9 required=5.0 tests=BAYES_80,HOT_NASTY,INFO_TLD, RCVD_ILLEGAL_IP,RCVD_IN_SORBS_WEB,RCVD_IN_XBL,RCVD_NUMERIC_HELO, URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=spam version=3.1.6

X-spam-Level: *************************

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="----------=_453CC474.DC78B70B"

Le logiciel anti-spam a identifie ce mail comme un spam potentiel.

Le message d'origine a ete attache a ce mail afin que vous puissiez

le lire (si ce n'est pas du spam)

Previsualisation du contenu : beauty black babe gets hard pussy fu**ed Babe sucks her

toes hot asian girl posing in red lingerie

<http://tvevisio.info/hums/jasmine.html...(*)> One boy

fu**ing two moms [...]

(*) I cut off the end of the URL so that I won"t be spammed if someone clicks on the link.

Details de l'analyse de contenu : (25.9 points, 5.0 requis)

pts regle description

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

0.3 RCVD_ILLEGAL_IP Received: contains illegal IP address

1.5 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO

0.2 HOT_NASTY BODY: Possible porn - Hot, Nasty, Wild, Young

1.3 INFO_TLD URI: Contains an URL in the INFO top-level domain

2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95%

[score: 0.8024]

1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server

[58.77.156.114 listed in dnsbl.sorbs.net]

3.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL

[58.77.156.114 listed in sbl-xbl.spamhaus.org]

1.6 URIBL_SBL Contains an URL listed in the SBL blocklist

[uRIs: tvevisio.info]

4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist

[uRIs: tvevisio.info]

2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist

[uRIs: tvevisio.info]

3.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist

[uRIs: tvevisio.info]

4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist

[uRIs: tvevisio.info]

[Hot link doused]

Link to comment
Share on other sites

I have sent a messgae to deputies. I'll post their answer when I get it.
Deputy has already expressed opinion you can report these. Since Don is the one who would mostly enforce the "material changes" provisions I suggest you are clear to submit. As said, post a tracking URL (cancel report) if you are in any doubt. A tracking URL would be FAR better than posting spam here - you don't want to do their "work" for them, do you? You understand you do not have to submit the report? You can cancel if you are worried about any aspect.
Link to comment
Share on other sites

you don't want to do their "work" for them, do you? You understand you do not have to submit the report? You can cancel if you are worried about any aspect.

Hi,

Thanks for your message. No, I don't want to do their job, I have 18000 spam per month, I have enought "SpamCop"ing them ;-) As for worry, I'm not worried. I just didn't want to mess up things. I have sent several "SpamAssassin"ed spam mails and they rarely come back with an error message (mainly, spam message body not found)

Best regards.

Robby

Link to comment
Share on other sites

Thanks Robby, if the deputies reply and add anything to the present understanding we would indeed appreciate you passing that on. Other than that, it sounds like you have things fairly much under control. The "message body not found" error often occurs because the blank line (CR LF) between headers and body has been lost. One work around is to paste those ones into the web-based entry boxes - the two-part Outlook/Eudora work-around.

Link to comment
Share on other sites

I don't like jailhouse lawyers sticking their nose in where it doesn't belong.

(snip)

...then you're in for a rude awakening when I catch you.

(snip)

Goody for you, but next time, make sure you have your facts straight first.

(snip)

Your comments here were completely inappropriate.

This was all uncalled for, undeserved, and besides, I was actually entirely correct and on topic. I've been receiving supportive PMs, wondering when I was going to blow my lid at this outrageous personal attack, but....I'm not. Sometimes it's enough to know beyond a shadow of a doubt that you're right and the other person......isn't.

DT

Link to comment
Share on other sites

This was all uncalled for, undeserved, and besides, I was actually entirely correct and on topic.

You basically told the user that I didn't know what I was talking about and then you proceeded to brag about how you're altering the headers and getting away with it.

Your post served no purpose other than to inflate your ego and dare me to take action against you for altering your spam.

That, sir, is absolutely unacceptable in my book.

- Don D'Minion - SpamCop Admin -

Link to comment
Share on other sites

Were you having a bad day, Don? The way I read David's post was to expand upon yours - yours answered the specific question posted, but did not cover any other aspects of 'material alteration'.

I realize that you have lawyers looking over your shoulder when you communicate with users and lawyers always don't want one to say more than is absolutely necessary to answer the question. However, we(tinw) in the forum are used to 'discussing' the issue at hand. It was Julian's opinion, at one time IIRC, that this kind of discussion was worthwhile.

Although there are various 'styles' among the regular posters to this forum, our aim is to be friendly and helpful. Unless the poster has an attitude, s/he generally recognizes that (sometimes it takes a few posts if they are very frustrated and angry especially at not being able to reach 'official' spamcop). ad hominem attacks and threats are not friendly and are discouraged by the regular posters.

I am sorry that your feelings were hurt, but no one here ever /intends/ to hurt someone's feelings until the OP demonstrates clearly that s/he is not willing to discuss anything, but wants to exchange insults.

Miss Betsy

Link to comment
Share on other sites

You basically told the user that I didn't know what I was talking about

No, that's not the way my post was intended, so if my wording led you to that conclusion, I apologize for writing in such a way as to make that a possible interpretation.

The way I read David's post was to expand upon yours

Yes, that was what I was trying to do, but perhaps not as well as I could have. My intent is to contine to protect the rights of reporters to omit things from the headers that are added by our receiving servers as part of the filtering process. The Barracuda appliance through which much of my mail passes adds a bunch of lines, which, if eventually given back to the spammer (which can happen when a report is sent, if the ISP is "black hat" or even "grey"), would show too much about what sort of spam protection is being used at my domains. Similarly, if I have mail forwarded from other receiving addresses to my SpamCop email account, I don't want that step being reported back to the ISPs because they don't need or deserve to know that. They only deserve the headers that lead up to the initial delivery to the first receiving server, because that's the point at which the spamming took place. I'm not removing or altering the Received headers that show the initial delivery from the outside.

I'm sorry that my intent wasn't clear enough, Don, and thanks for your participation in the Forum...although we "mere mortals" try to assist other users with their issues, it certainly helps to have someone official drop by and weigh in from time to time. :-)

Peace,

DT

Link to comment
Share on other sites

They only deserve the headers that lead up to the initial delivery to the first receiving server

David, When using spamcop to report your spam, it is not what the ISP's "deserve" that decides, it is spamcop's rules. I know how YOU interpret the rules. I happen to disagree with your strict reading of them, and have stated such in the past. My reading comprehension scores have always been at the top of the list as well, but sometimes, there is this little thing called intent. I read identifying information as "your name and/or email address". However, since Don is the "rule enforcer" for SpamCop, it really is his interpretation that matters.

I especially hope you do not send any reports to ISP's that require unmunged reports, as you will only hurt SpamCop's reputation if it is found that munged reports are accepted.

Whenever I feel the need to change the spam in any way, for any reason, I send manual reports.

P.S. I have started and stopped this reply several times. I did not want my silence to be interpreted as support for your position.

Link to comment
Share on other sites

My intent is to contine to protect the rights of reporters to omit things from the headers that are added by our receiving servers as part of the filtering process. The Barracuda appliance through which much of my mail passes adds a bunch of lines, which, if eventually given back to the spammer (which can happen when a report is sent, if the ISP is "black hat" or even "grey"), would show too much about what sort of spam protection is being used at my domains. Similarly, if I have mail forwarded from other receiving addresses to my SpamCop email account, I don't want that step being reported back to the ISPs because they don't need or deserve to know that. They only deserve the headers that lead up to the initial delivery to the first receiving server, because that's the point at which the spamming took place. I'm not removing or altering the Received headers that show the initial delivery from the outside.

David,

Like others I have sat mulling over how to contribute usefully to this thread.

I have wondered, many times, whether the editing of headers that you have espoused so well is fully compliant with the 'rules'. Certainly there is a logic to what you do. But your current explanation leaves me less certain that your approach is entirely correct (as defined by the rules).

Certainly your removal of the headers added by your Barracuda device seem to meet the conditions that Don outlined but my reading of the rules would leave me uneasy with the removal of the forwarding information as you have described it. In this respect only, I think the ice may be very thin where you are skating.

In the end, of course, it isn't our system so we have to play by those rules laid down by others and trust they are applied evenly and fairly.

Andrew

Link to comment
Share on other sites

Steven,

We can agree to disagree, I suppose, but you seem to be reading something into the rules that aren't there. Read the rules again (link is below this paragraph) and tell me why we shoudn't be allowed to remove the SpamAssassin lines from the headers of email before sending reports. They aren't put there by the delivering server...they're a filtering action done after the initial receipt of the message from the outside. If those lines get back to the spammers, they identify exactly which SA "tests" were triggered by their spam, and what the resulting SA "score" was, none of which has to do with the actual receipt of the message by the receiving mail server.

Similarly, once my initial server has accepted the message and then automatically forwards it to my SpamCop address, can you explain why that additional delivery action should be reported back to the ISP responsible for the transmission of the spam? Furthermore, the phrase "identifying information" doesn't appear anywhere in the FAQ about "material changes," which is here:

http://www.spamcop.net/fom-serve/cache/283.html

That phrase appears in the "Reporting preferences" screen regarding the automated munging that can be done by the reporting system as it transmits reports to ISPs. While you bring up what the phrase "identifying information" means, I submit that applying it to post-receipt header lines isn't the intent at all. The point is whether or not to deliver the raw "Received" lines or not, as well as whether the reporting system will also try to find and obscure other occurances of the "identifying information" in the body of the spam (such as embedded in URLs). I respect the rules, and their intent.

In clarifying what's not allowed, Don wrote:

If you're removing or altering your server's "Received" lines that show your network getting the spam from outside...

and I've never done that. My headers aren't "munged," Steven. I don't go into the headers and "x" out anything at all. I restore the headers back to the way they would appear at the point of delivery if I were allowing a "normal" delivery to occur, without post-acceptance filtering and/or forwarding. Lots of gunk can get added to the headers after actual receipt of a message by a server, and even your mail client and anti-virus software can get into the act and add even more lines, and absolutely none of that additional information is the business of the ISP (or the spammer).

Certainly your removal of the headers added by your Barracuda device seem to meet the conditions that Don outlined but my reading of the rules would leave me uneasy with the removal of the forwarding information as you have described it.

Andrew,

In my initial post describing what I do, I wrote:

The lines I remove were *not* present in the original email as it arrived at the server(s) accepting email for me.

After reading that post, Don's response included what I've quoted above. So, please explain, quoting the rules if necessary, how I might be "skating on thin ice."

DT

Link to comment
Share on other sites

After reading that post, Don's response included what I've quoted above. So, please explain, quoting the rules if necessary, how I might be "skating on thin ice."

Hi David!

I'm not looking to have an argument or fall out over this issue. I was careful to say that my reading of the rules led me to uncertainty over your interpretation. I'm certainly not declaring your interpretation incorrect but offering my tentative view.

I suppose the issue is at which point the message has been accepted. I work on the basis of the final point of arrival rather than several steps earlier where forwarding is applied. Which is why I noted that there is a logic to your approach but that we have to live by the rules applied by the service providers no matter how definitely we declare our personal interpretations.

But at the end of the day it isn't worth even a disagreement. It's a free service to which many cheerfully contribute through reports. If we were face-to-face I'd offer to buy a coffee and get to know you rather than spend ages debating the finer points in the rules. :D

Andrew

Link to comment
Share on other sites

I suppose the issue is at which point the message has been accepted. I work on the basis of the final point of arrival rather than several steps earlier where forwarding is applied.

That's something that we might be able to get a "ruling" on from a SC admin, which would be helfpful (and shouldn't transmit any "super secret" proprietary stuff to spammers or others, IMO).

It's a free service to which many cheerfully contribute through reports.

Yes, but if my procedure is ruled out, then I won't report any more spam through the reporting system, cheerfully or otherwise, because what I decide to have done with my messages after they are accepted by the MX for the domain on my email address should be private information, and so I'm trying to protect that right to privacy not only for myself, but for other users. Yes, I realize that I could choose the "mole" option, but that's less desireable, in that mole reporting only adds to some aggregate stats and doesn't result in notification of the ISPs. Yes, I could choose to manually report, but then I'd have to do all my munging by hand, which would be even *more* work than what I'm currently doing. I like things just the way they are and would like to help clarify things for you, Steven, and anyone else who has doubts about what I contend to be proper use of the system.

As for the offer of a cup of coffee, are you anywhere near Arizona? :-)

DT

Link to comment
Share on other sites

Steven,

We can agree to disagree, I suppose, but you seem to be reading something into the rules that aren't there.

I have read the rules many times and will quote where I thing you are crossing the line. It specifically mentions what you CAN do.

It is okay to munge your personal email address contained within links in the body of the spam, if SpamCop does not find and munge them, with one exception. If a report is going to an abuse desk that does not accept munged reports, you must not make even these minor changes to the spam.

They also specifically mention an exception "for those who know what they are doing" about decoding Base64 bodies.

Those are the only things it mentions you can change, and that is how I have always interpreted and applied it. The intent of the rule (from my reading) was to allow for additional munging of ones name and email address because the parser does not always do a great job of that. It was not to remove what the ISP does not need to see. Some ISP's use these reports as legal evidence against the spammers (though I have heard less of that in the last few years). That legal evidence of your report should be AS YOU RECEIVED IT, not the receiving system, IMHO. It is YOU making the report (complaint), not your system.

Link to comment
Share on other sites

Steven,

Your interpretation of the rule seems quite conservative, and requires reading between the lines, or at least applying them more generally than written. First, for those who are less familiar with this, here's the entire FAQ:

Material changes to spam

SpamCop does what it does and doesn't do for a reason. Do not make any material changes to spam before submitting or parsing which may cause SpamCop to find a link, address or URL it normally would not, by design, find.

SpamCop does not generate reports for From: or Reply To: addresses. Do not add these within the body of the spam to cause a report for these to be generated.

SpamCop does not decode java scri_pt because it does not have its own java scri_pt interpreter. Unless you can properly decode the java scri_pt, even what you see may not be correct. Do not make any changes to the spam to cause SpamCop to report addresses, links or URLs that are contained within the java scri_pt, decoded or not.

It is okay to munge your personal email address contained within links in the body of the spam, if SpamCop does not find and munge them, with one exception. If a report is going to an abuse desk that does not accept munged reports, you must not make even these minor changes to the spam.

Base64 Encoded spam - Many spammers are sending messages with Base64 encoded bodies. While SpamCop normally decodes and parses Base64 fine, it is possible for spammers to hide your address or other identifiable information within the encoded body.

For this reason, SpamCop has made an exception to the normal alteration rule for those who know what they are doing:

1. Use a Base64 decoding tool like http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/

2. Remove the encoded Base64 body and replace it with the decoded text

3. A disclaimer must be added to the top of the spam body. (Remember to leave a blank line between the last header line and your disclaimer):

"I have decoded the original Base64 spam body and munged personal details that were in that body. The original body has been replaced with this decoded text. I understand that you may consider this to be altered and not acceptable as evidence"

The opening paragraph clearly contains the "general rule," while the rest of the page gives *some* (obviously not all) specific examples. Those examples are two of what you should not do, and two which are OK to do. The one you quoted is the first of the "OK" ones, but please look more closely at every clause contained in those two sentences. If you do, you should see that the "personal email address" being referred to is only that which is "contained within links in the body of the spam" and that the "these minor changes" in the next sentence refers specifically back to the issue of your email address being contained in links in the body. The sentence doesn't read:

If a report is going to an abuse desk that does not accept munged reports, you must not make any changes whatsoever to either the body or the headers of the spam.

Rather, the sentence, as written, prohibits altering the links found in the body of the spam. You're reading it as if it said what I've presented in my modified, hypothetical version. If the sentence gets changed, then I'll be sure to obey it as it's published.

As for your interpretation of the significance of reporting as received, including subsequent forwarding headers, I think that Don's message earlier in this topic spoke to that issue when he wrote:

...removing or altering your server's "Received" lines that show your network getting the spam from outside...

Let's say that I've got two Yahoo email addresses, one that I read on the Yahoo! website and one that I have the SpamCop Email Service pick up for me using the "popgate" function. I receive the same spam at both addresses, and report them both. In both cases, the message was sent to and originally received at a Yahoo.com email address. The SpamCop system comes by every so often and then collects mail that has already been received at one of my Yahoo.com accounts. Requiring that the extra header lines relating to that subsequent collection of the messages be included in any subsequent spam reporting is nonsensical. The spammer delivered both messages to my Yahoo accounts.

An automatic forwarding arrangement is almost the same. The message is initially received at the server that accepts it on my behalf. In fact, I lease the server (I host domains on a VPS - a virtual private server), and I make my reports on the spam as they appeared upon arrival at that server.

DT

Link to comment
Share on other sites

Again, this is your opinion.

Whenever I use someone else's system (SpamCop's in this case), I am very cautious about how I use it. I make NO changes that are not specifically spelled out as allowable. The changes you seem to be making are NOT specifically allowed. Their server, their rules. I think you are pushing the limits of those rules. Again, Don's opinion is the only one that really matters here. Am have spoken my thoughts and will stop now.

Link to comment
Share on other sites

"for those who know what they are doing"

This discussion is getting way beyond the average new poster's expertise (at least judging from some recent posters including server admins!).

Conservative advice is always best concerning 'interpretation' because too many /don't/ know what they are doing. For instance, I would never dare to 'trim' out headers from those spam that are forwarded to me. I just add them to my mailhosts. But I do know enough that I probably could - without making 'material' changes. Since I am self taught and inexperienced (no server to administer), I don't have the confidence.

Don could have said what I have just said - that a conservative interpretation is best for most reporters. He didn't, but since those who regularly post in the forum are simply 'users' who want to share with those who have questions about spamcop, anyone reading this thread should remember 'my server, my rules' and unless you are positive you really know what you are doing, take the conservative path.

And remember that, in order to have a decent discussion, it is not wise to call someone a 'jailhouse lawyer' or similar ephithets. Instead it is likely to bring about 'troll baiting' or no answers at all.

Miss Betsy

Link to comment
Share on other sites

Similarly, if I have mail forwarded from other receiving addresses to my SpamCop email account, I don't want that step being reported back to the ISPs because they don't need or deserve to know that. They only deserve the headers that lead up to the initial delivery to the first receiving server, because that's the point at which the spamming took place. I'm not removing or altering the Received headers that show the initial delivery from the outside.

The bottom line is that removing "Received" lines from headers is not allowed under any circumstances. That specifically includes forwarding hops and internal hops.

I'm sorry, but that's the way it is and has to be. We can't have users, even experienced ones, working over the path of the spam before it's submitted. SpamCop's accuracy is at stake, and we're not taking any chances. We don't need or want altered spam.

And more importantly, we can't have the experienced users telling the novice users that they're altering the headers and making the novices think it's OK to do it. It's not OK, and nobody should be doing it.

- Don D'Minion - SpamCop Admin -

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...