X-Resolved-to not blanked out

[gggggg]

Fastmail uses the X-Resolved-to header to indicate he alias to which email was delivered. Spamcop is removing the X-Delivered-to contents. It also needs to remove the X-Resolved-to header contents when people as k for header munging.

Anyone have suggestions on how a user of Spamcop can do this?

If this can be turned on by a user, neither searching these forums nor Google turned up an answer for me.

Thanks

[Wazoo]

There are no 'user options' as you seem to be suggexting in the Parsimg & Reporting process.

Address munging is generally based on the contents of the To: line.

As repeatedly pointed out, when asking a question like this, real data would make it easy to actually discuss something. A Tracking URL would allow someone to take a look at your issue and see if there is an 'easy' answer or not.

[gggggg]

. . . .

Address munging is generally based on the contents of the To: line.

As repeatedly pointed out, when asking a question like this, real data would make it easy to actually discuss something. A Tracking URL would allow someone to take a look at your issue and see if there is an 'easy' answer or not.

Here are some headers Spamcop parsed today. The section in '[...]" on the X-Resolved-To header showed my email address. I manually removed it in this posting. Spamcop did remove the email addresses in X-Delivered-to and To.

Return-Path: <nyav[at]together.net>
Received: from compute2.internal (compute2.internal [10.202.2.42])
	 by store2m.internal (Cyrus v2.3.8-fmsvn12296) with LMTPA;
	 Sat, 21 Jul 2007 14:49:12 -0400
X-Sieve: CMU Sieve 2.3
Subject: {spam 07.7} Email
X-spam: spam
X-spam-score: 7.7
X-spam-hits: BAYES_99 3.5, FUZZY_OCR 0.000, RCVD_IN_PBL 0.905, RDNS_NONE 0.1,
  TVD_PDF_FINGER01 1, TVD_SPACE_RATIO 2.219, BAYES_USED user
X-spam-source: IP='196.219.213.109', Country='EG', FromHeader='net', MailFrom='net'
X-Attached: Email.pdf
X-Resolved-to: [my email was here, not removed my Spamcop, but removed by me for this forum]
X-Delivered-to: x
X-Mail-from: nyav[at]together.net
X-Remote-spam-greylist: Passed. Delay was 634 seconds.
Received: from host-196.219.109.213.tedata.net (unknown [196.219.213.109])
	by mx2.messagingengine.com (Postfix) with SMTP id 421711E02EC
	for <x>; Sat, 21 Jul 2007 14:48:20 -0400 (EDT)
Received: from rasu ([75.215.65.167])
	by host-196.219.109.213.tedata.net (8.13.3/8.13.3) with SMTP id l6M6lD9P061636;
	Sun, 22 Jul 2007 09:47:13 +0300
Message-ID: <46A2________0208[at]witcom.net>
Date: Sun, 22 Jul 2007 09:44:12 +0300
From: Sarah Steele <nyav[at]together.net>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: x
X-spam-orig-subject: Email
Content-Type: multipart/mixed;
 boundary="------------070201040801060001060405"

[Wazoo]

By not providing a Tracking URL and then munging the sample, there really isn't much to talk about 'here'

I'll toss ouit that the issue may be simply that it's an X-Line: that is generally ignored by the parser. In reality, yes, some X-Line: syntax items may have been coded into the parser to be recognized/handled, but ... that level of detail is only speculation based on seeing parse results.

I'd take it upstream and ask, but the conditions of the day don't suggest that this would gather any help.

I would suggest looking at Where to get Help and contact the Deputies .. the question I'm suggesting (again, based on unknown facts and details) would be ....

If some X-Lines are programmed in to be handled for the mung process, can "X-Resolved-to:" be added to that section of code? Noting that the Depiries do not actually do the coding, so the real question (if asked) would be the current mode of "opening up a ticket to engineering" and they'd have to wait for an answer.

A Tracking URL would help things immensely all around.

My e-mail ....

From: "Wazoo"

To: "SpamCop Deputies"

Subject: X-Resolved-to: line not munged during a parse

Date: Sat, 21 Jul 2007 21:18:41 -0500

http://forum.spamcop.net/forums/index.php?showtopic=8507

User identifies FastMail as using this line internally.

Question appears to be ....

If the X-Delivered-to: line gets munged, why doesn't the

X-Resolved-to: line also get handled the same way?

I conjecture that certain 'popular' X-Lines have been

explicitly embedded into the code, so this specific line

would be seen as a 'requested new feature' ....

User has been advised to contact you all directly on this,

ads he/she didn't want to provide actual data or a Tracking

URL in the Forum.

[gggggg]

A Tracking URL would help things immensely all around.

A tracking URL would have included my email address which is what I am trying to avoid.

Thank you for your help.

[SpamCopAdmin]

Spamcop is removing the X-Delivered-to contents. It also needs to remove the X-Resolved-to header contents when people ask for header munging.

I agree. I asked Engineering to add the "X-Resolved-to" header to the list of fields that automatically get their contents deleted.

Engineering's plate is full, so it could take a while for the change to be implemented.

- Don D'Minion - SpamCop Admin -

[gggggg]

I agree. I asked Engineering to add the "X-Resolved-to" header to the list of fields that automatically get their contents deleted.

Engineering's plate is full, so it could take a while for the change to be implemented.

Don,

Thank you. That is everything I asked for.

[gggggg]

I notice that if the X-Resolved-to header contains the same email address as X-Delivered-to it is turned into an "x." Or this happens randomly as I don't have much data.