Jump to content

Advice about munging please


kenrob

Recommended Posts

G'day,

This is a big forum, I suspect this newbie's missed the answer!

I have a family domain and we use multiple email addresses. I'm concerned now because not all domain addresses are being munged before reports are sent. The Envelope-to field often contains up to eight addresses. More than half will be garbage, all are at my domain, but only one or two will be munged. So the bad guys will (sometimes) know who's complaining. (Memories of bad experiences during the Blue Frog demise.) What do I need to do for them all to be munged?

--

Regards

Ken

Link to comment
Share on other sites

My understanding is that address munging is a somewhat imprecise process.

The FAQ says you can manually munge your personal addresses before submitting spam to the parser provided the ISP that receives the report accepts munged headers. See: http://www.spamcop.net/fom-serve/cache/283.html

That said, many users will argue that munging headers makes no difference to the amount of spam received. Personally, I munge unless that ISP refuses munged reports in which case I allow the headers to go through complete.

Andrew

Link to comment
Share on other sites

The FAQ says you can manually munge your personal addresses before submitting spam to the parser provided the ISP that receives the report accepts munged headers.
This is what I'd recommend if you're concerned. It will mean that you can't forward spam to your reporting address, but will have to make use of the web-based reporting form instead.

Similarly, much of the mail I receive passes through several systems on its way to my PC, and so I often remove the extraneous Received lines and the "X-lines" added by some of my filters, because I'd rather that not fall into unfriendly hands. However, since I'm not making alterations that would alter the eventual reporting done after parsing, I contend that I'm abiding by the rules.

For anyone who cares, let me clarify....let's say that I have an address that I have automatically forwarded to my personal SC email account. I'd rather not tip off the report recipients (who may be grey or black hat) that I'm using an SC email account as a final filtering step, so I remove the topmost headers and the "X-SpamCop" lines further down as I'm pasting the raw source into the parsing form. Some of my mail also passes through a Barracuda firewall at my hosting site, and so I also remove explicit references to that technology from the headers, because that's entirely irrelevant to the ISP who receives the report and I sure don't want the spammer to know what filtering techniques I'm using. The end result is a message exactly as I would have received it on a mailbox at my domain, were I not using any special filtering techniques. I contend that's all that needs to go out in a spam report. Others may disagree, but I'm doing *nothing* that would change the behavior of the parser, when it comes to what it reports.

(on edit) Further supporting my practice, the FAQ that Andrew linked to states that we're not to make changes "which may cause SpamCop to find a link, address or URL it normally would not, by design, find." None of my changes would do that, so until the rules are re-written, I am, and anyone else is allowed to do what I've described in this post.

DT

Link to comment
Share on other sites

Just so things remain as 'set in stone' ..... for those that know exactly what they are doing, they may be able to "get away" with doing some things. The problem comes in that someone that does not know 'exactly what they are doing' are going to read things as posted here and decide that they are also going to remove things that "don't need to be in there" .... resulting in broken chain-tests, misidentified hand-offs, etc. .....

One 'rule of thumb' .. if you have to ask, you probably don't know enough yet to do it (correctly ... without getting caught doing it wrong) ....

For example, is the original posted actually trying to submit spam that has a header line titled Envelope-to ????? I'm guessing not, but ...???? I'm actually thinking that this is another one of those cases where some words were used that are not technically correct, some latitude used in making the assumption that it is "known" what was "meant" .. and conversation moved along .... for example, the "envelope" may have contained another 200 more unknown addresses, but what is actually being discussed is the data on a (forged) CC: line ... not necessarily the same item ....

I'd say we're back to wanting to see an example or two, again preferably via a Tracking URL .....

Link to comment
Share on other sites

for those that know exactly what they are doing, they may be able to "get away" with doing some things.

I *do* know exactly what I'm doing, but I'm not really "getting away" with anything. I'm obeying the rules in the FAQ, exactly as they've existed for a long time. On that FAQ page, there are a few specific examples of "dos and don'ts" but a very literal reading of the sentence at the top of the page:

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.

clearly allows my tweaks. The key portion is "which may cause" and I'm *not* "causing" so what I do is allowed, period.

DT

Link to comment
Share on other sites

I *do* know exactly what I'm doing, but I'm not really "getting away" with anything.

I believe you know that my response was not targetted towards 'you ''' rather all those other folks that may accidentally actually stumble into this Topic and base their next actions on the "it's OK to remove whole lines of stuff" because I "read it in the Forum" .....

Link to comment
Share on other sites

I believe you know that my response was not targetted towards 'you '...

Yes, but I wanted to make crystal clear that those of us doing this sort of thing aren't "getting away with it," but rather are using some advanced techniques for specific. legitimate reasons. In general, I'd avise others *not* to mess with the headers if they don't have a strong reason to do so. IOW, we're in agreement, and I'm simply putting this here for archival purposes. :-)

Peace,

DT

Link to comment
Share on other sites

for those that know exactly what they are doing, they may be able to "get away" with doing some things.
I *do* know exactly what I'm doing, but I'm not really "getting away" with anything. I'm obeying the rules in the FAQ, exactly as they've existed for a long time. On that FAQ page, there are a few specific examples of "dos and don'ts" but a very literal reading of the sentence at the top of the page:
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.
clearly allows my tweaks. The key portion is "which may cause" and I'm *not* "causing" so what I do is allowed, period.

DT

...FWIW, I agree with you but feel compelled to point out that what is relevant is not how we users interpret the rule but how TPTB (who, after all, are the ones who would enforce the penalties upon you) interpret the rule. Thus, I encourage you to contact the SpamCop Deputies to verify that they agree with you.
Link to comment
Share on other sites

what is relevant is not how we users interpret the rule

Good point, but if they don't want people doing what I'm doing, then the wording of the FAQ needs to change, because I'm abiding *exactly* by what it says. I'll go ahead and write to the Deputies when I get a chance. If they want to tighten it up, then they need to change the wording, and then I'll simply stop reporting, and the rest of you will not benefit from any sources I'd otherwise report.

DT

Link to comment
Share on other sites

Good point, but if they don't want people doing what I'm doing, then the wording of the FAQ needs to change, because I'm abiding *exactly* by what it says. I'll go ahead and write to the Deputies when I get a chance. If they want to tighten it up, then they need to change the wording, and then I'll simply stop reporting, and the rest of you will not benefit from any sources I'd otherwise report.

Are you reporting in order to put them on the scbl or to possibly give a heads up to a white hat (or some one in need of education)?

If the latter, you can manually report - even using the parser to find addresses for you.

IMHO, the problem of 'not-knowing-what-they-are-doing-reporters' is solved by the fact that they can be suspended or barred from reporting if they do it wrong so a change, or clarification, in rules is unlikely.

Miss Betsy

Link to comment
Share on other sites

... What do I need to do for them all to be munged?...
Glad we could sort you out about that, Ken. :D Actually, nothing in SC will do the job automatically AFAIK and there may be pitfalls to doing it manually because we may not be sure until we see it that what you would have in mind exactly complies with the "rules". Bit of a cleft stick, you can't post the tracking URL for one of the problem spam without making the unmunged addresses public. Maybe you could copy the (full) headers of one and post them here, manually changing the bits that worry you with something descriptive (like me [at] myDomain1.id.au, Charmain [at] myDomain1.id.au, me [at]myDomain2.com) and in a contrasting colour as exemplified? You would need to include the SC munging too, just leave it the way SC handles it (<x>, whatever).
Link to comment
Share on other sites

Are you reporting in order to put them on the scbl

Yes, and yet I want to limit the information that gets sent to the responsible parties for the IPs to only what is absolutely necessary. So I'm essentially paring the email down to what it would have looked like had it not passed through the two filtering servers after its initial arrival at the "front door," so to speak.

DT

Link to comment
Share on other sites

... I want to limit the information that gets sent to the responsible parties for the IPs to only what is absolutely necessary. So I'm essentially paring the email down to what it would have looked like had it not passed through the two filtering servers after its initial arrival at the "front door," so to speak.
FWIW that sounds reasonable to me (and is likely to be pertinent to the OP's question too) - but whether the Deputies are able to condone it in general terms, or not, is indeterminate. If they regard such alteration as a "slipperly slope" I would not be surprised on the limited basis of past public feedback. If so, I have to say there is probably no need to be so restrictive.

The purpose of reporting is to allow the providers who wish to do so to identify the source of spam emanating from their networks (and hopefully to curtail it in consequence). That purpose is somewhat hindered when additional routing and X-header detail is added to the headers of the original message after it leaves their network. Not to mention the security concerns it may cause the reporters. We must recognize though that (some of) that additional detail is the effective "chain of custody" record of the message to assure the providers' abuse handlers that the complainant is the proper person to flag/allege network abuse. Just how often such rigor is required I could not say but I suspect that the white hat providers are not inclined to stand on ceremony and the black hat ones don't care anyhow. But then I'm not paying the bills - legal or otherwise.

Link to comment
Share on other sites

The whitehats need a completely unmunged - including all the additional header lines - email to satisfy their legal department if they take action against a customer, IIUC. I don't see why an added comment wouldn't suffice to the effect that a completely unmunged email will be provided on request with an affidavit if required for legal action . When NY went after some spammer years ago, they requested people to send by snail mail the spam together with an affidavit (notarized).

And the blackhats do use any and every email (including firewalls), if not for retaliation, to add to their lists. From what I have read, a lot of the money in spamming is in the buying and selling of lists.

Miss Betsy

Link to comment
Share on other sites

G'day folks,

Hmm, a topical topic! My goodness, what have I started?

OK - to reply to Wazoo, yes I did mean Envelope-to. Pasted below is a sample:

In this example, the first munged ady in 'Envelope-to' is a real address, the second is a garbage address containing part of a different real address, hence the "hex", the third is a garbage address.

So - is it possible to 'train' SC that anyhing at mydomain.com should be munged?

--

Regards

Ken

=====

Received: (qmail 24952 invoked by alias); 19 Sep 2006 08:40:09 -0000

Delivered-To: x

Received: (qmail 24935 invoked from network); 19 Sep 2006 08:40:08 -0000

Received: from eserver.athome (HELO localhost) (192.168.0.101)

by eserver.athome (192.168.0.101) with ESMTP; 19 Sep 2006 08:40:08 -0000

Envelope-to: x,

hex,

realaddress1[at]mydomain.com,

garbageaddress1[at]mydomain.com,

garbageaddress2[at]mydomain.com,

garbageaddress3[at]mydomain.com,

x,

realaddress2[at]mydomain.com

Delivery-date: Tue, 19 Sep 2006 01:38:02 -0700

Received: from pop.registerapi.com

by localhost with POP3 (fetchmail-5.9.0)

Tue, 19 Sep 2006 18:40:08 +1000 (EST)

Received: from [124.106.147.145] (helo=124.106.147.145.pldt.net)

by mx.mailix.net with esmtp (Exim 4.24-NH)

id 1GPb6t-0003e8-Kg; Tue, 19 Sep 2006 01:37:46 -0700

From: "Beulah Keen" <couch[at]strathisla.japan.sun.com>

To: <x>

Date: Tue, 19 Sep 2006 23:42:08 +0480

MIME-Version: 1.0

X-Priority: 3 (Normal)

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook, Build 10.0.2627

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Importance: Normal

Message-Id: <E1GP_________8-Kg[at]mx.mailix.net>

X-VS-Do-Not-Run: Yes

X-SA-Exim-Connect-IP: 124.106.147.145

X-SA-Exim-Mail-From: couch[at]strathisla.japan.sun.com

X-spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on spamd3.backend

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

X-spam-Status: No, score=9.9 required=10.0 tests=DATE_IN_FUTURE_06_12,

FORGED_MUA_OUTLOOK,HELO_DYNAMIC_SPLIT_IP,MSGID_FROM_MTA_ID,

RCVD_NUMERIC_HELO autolearn=no version=3.1.0

Subject: Hot Tuesday flat

Content-Type: text/plain;

charset="windows-1250"

Content-Transfer-Encoding: 7bit

X-SA-Exim-Version: 3.1 (built Thu Oct 23 13:26:47 PDT 2003)

X-SA-Exim-Scanned: Yes

Received-SPF: none (spfquery: domain of couch[at]strathisla.japan.sun.com does not designate permitted sender hosts) client-ip=124.106.147.145; envelope-from=couch[at]strathisla.japan.sun.com; helo=;

X-VS-Scanned: No; VscanRunCond expanded to false

X-Antivirus: avast! (VPS 0637-2, 09/15/2006), Inbound message

X-Antivirus-Status: Clean

=====

Link to comment
Share on other sites

OK - to reply to Wazoo, yes I did mean Envelope-to. Pasted below is a sample:

In this example, the first munged ady in 'Envelope-to' is a real address, the second is a garbage address containing part of a different real address, hence the "hex", the third is a garbage address.

So - is it possible to 'train' SC that anyhing at mydomain.com should be munged?

In a quick search of the RFC's, there is no "Envelope-to:" defined anywhere that I can fine. I did find "Envelope-from:" http://www.rfc-editor.org/rfc/rfc4408.txt This simply means the line might be ignored all together. Looking at your posted sample, I am seeing where the 2 non-highlighted x's munged but the rest were not? This would seem to indicate the line is looked at, however.

Link to comment
Share on other sites

I *do* know exactly what I'm doing, but I'm not really "getting away" with anything. I'm obeying the rules in the FAQ, exactly as they've existed for a long time. On that FAQ page, there are a few specific examples of "dos and don'ts" but a very literal reading of the sentence at the top of the page:clearly allows my tweaks. The key portion is "which may cause" and I'm *not* "causing" so what I do is allowed, period.

DT...FWIW, I agree with you but feel compelled to point out that what is relevant is not how we users interpret the rule but how TPTB (who, after all, are the ones who would enforce the penalties upon you) interpret the rule. Thus, I encourage you to contact the SpamCop Deputies to verify that they agree with you.

I wonder... since the "rule" says

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.

would it be sufficient to parse the spam both ways, with and without the so-called extraneous headers in question, and see if the results of the parse are in any way different? Cancel one, submit the other. If all reports and reporting addresses are the same for the two parses, then nothing was done to change what SpamCop found or did not find.

Link to comment
Share on other sites

... would it be sufficient to parse the spam both ways, with and without the so-called extraneous headers in question, and see if the results of the parse are in any way different? Cancel one, submit the other. If all reports and reporting addresses are the same for the two parses, then nothing was done to change what SpamCop found or did not find.
Only SC staff could say and I doubt if they would want to condone any alteration. The general view, I think, is if you have to change anything, send a manual report.

Munging though is a special case and has a some history of verging on tolerance ("if they know what they're doing" was the term a Deputy used once, IIRC) but strictly speaking that is limited to the body (leaving aside abuse desks requiring totally unmunged reports) - you have seen http://www.spamcop.net/fom-serve/cache/283.html.

FWIW, I don't advise for you to delete anything (taking the most cautious approach) - though whether deleted or munged, I can't see the highlighed data affecting the parse. It is not clear (to me at least) why the parser does not complete the job of munging that - apparently - it starts to do (you have yet to verify that point which was queried by StevenUnderwood) and that possibly is one avenue by which to advance the matter. But changes to the parser are not lightly undertaken and would usually have to be pressing in terms of affecting a number of reporters and/or the volume or quality of reports.

Another possibility is to contact the deputies - deputies[at]admin.spamcop.net - and put the case, as you have illustrated it, for manual munging in the "Envelope to:" field. The problem then is if there is no response (with the volume of messages handled that is a distinct possibility). Possibly (or at least morally) affording some defence against subsequent summary suspension though ;)

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...