UTF7 encode/decode problem?

[tcaud]

My email system has delivered two emails over the last two days that appear to either be incorrectly encoded or incorrectly decoded. SpamCop is unable to process them because the improper encoding/decoding does not reveal any IP addresses.

SpamCop report link: http://www.spamcop.net/sc?id=z1862658043z8...299b8b42bc261az

(I only kept one of the report links)

I am unable to verify how this email even arrived and was delivered to my mailbox. My initial thought is that the email was generated internally by a virus and just dropped in the Queue folder on my internal Exchange server. This could possibly(?) keep the Exchange server from properly stamping it with the internal IP addresses.

If this is not the case, then what methods can I use to "decode" the email properly to reveal the IP Address trail?

Also, is there a confiuration change that I need to make on my Exchange server to prevent this from happening again?

Thank you,

[Wazoo]

Exactly how did you decide that your combined queries in this post met the placement and definition of;

Suggested Tools and Applications

A Forum for pointing to those neat fixes and solutions that we've all been looking for. Free is great, open-source even better. Noting issues with Spyware/Adware would also be appreciated.

Moving to the Lounge area with this post, although wondering if a better destination might be;

Geek/Tech Things > Software Issues

A Forum for those things that just plain go wrong or don't work as advertised. Though one should probably go to the source, maybe while you're here, you'll connect with another poor soul that saw the light after performing the head-against-the-wall ritual?

[tcaud]

My apologies, the Suggeted Tools and Applications forum was not the forum that I thought that I was posting in. Thank you for moving it to the more appropriate forum.

[rconner]

SpamCop report link: http://www.spamcop.net/sc?id=z1862658043z8...299b8b42bc261az

(I only kept one of the report links)

Very puzzling. What you seem to have are headers that have been turned into MIME encoded words (the things between the "=?" and "?=" signs). I don't know where this was done or who did it.

E-mail headers are only supposed to contain ASCII text. You can shoe-horn non-ASCII into them using MIME EWs, but this is generally done only in subject lines or address nicknames where the content is not critical to mail transmission.

Using some private code I have stashed away, I did a try at decoding the first header line, and got this:

Received:  from mail1.mil-tec.com (+AFs-192.16
	8.8.254+AF0-) by Corpsrv4.MiltecCorp
	oration.local with Microsoft SMT
	PSVC(6.0.3790.3959)+ADs- Mon, 5 May 
	2008 17:00:24 -0500

I had to kludge because I did not have code to translate UTF-7, so I do not trust this decoding completely. There appear to be some goofy characters sprinkled throughout (the "+A..." business), maybe these are non-ASCII characters that snuck in to the header and escaped following UTF-7 rules.

My guess is that this mail is being mangled after receipt by your provider's MX mail host This is because all of the header lines are subjected to the same treatment. It could be that the MIME-declaration of UTF-7 within the message body could be partly responsible for the confusion -- I don't see much UTF-7 here in the U.S., so I don't know if it is very common elsewhere.

If I were you, I'd try to find out where and why this mail is getting clobbered in this fashion.

You might google something like "mime encoded word decoder" to see if there are any tools that can help you decode the headers properly.

-- rick

[tcaud]

Using some private code I have stashed away, I did a try at decoding the first header line, and got this:

Received:  from mail1.mil-tec.com (+AFs-192.16
	8.8.254+AF0-) by Corpsrv4.MiltecCorp
	oration.local with Microsoft SMT
	PSVC(6.0.3790.3959)+ADs- Mon, 5 May 
	2008 17:00:24 -0500

I had to kludge because I did not have code to translate UTF-7, so I do not trust this decoding completely. There appear to be some goofy characters sprinkled throughout (the "+A..." business), maybe these are non-ASCII characters that snuck in to the header and escaped following UTF-7 rules.

Rick, thanks for the input. The line that you did decode is basically accurate and shows receipt of the email by my internal server from my smtp server in the permiter network.

You might google something like "mime encoded word decoder" to see if there are any tools that can help you decode the headers properly.

I did a search as you suggested and found a few programs that would attempt to decode, but had much less luck than you did with your code and kludging. The most that I could get decoded was mail1.mil-tec.com and nothing else. I expanded my search a little to include UTF-7 and came across an email security site that contained some more information.

From www.securiteam.com

Inability to check UTF-7 content

Almost all MUA/Web client software supports UTF-7/UTF-8 encoding for text. Content filtering software may fail to strip dangerous content from UTF-7/UTF-8 encoded data.

For example:

The "<scri_pt>" tag in UTF-7 will show up as: <+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->.

Inability to check content marked as UTF-7/UTF-8

If a MUA or a Web client retrieves an UTF-7/UTF-8 encoded file, the attached file will be decoded, and not saved to disk.

The text "<+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->" will be decoded as "<scri_pt>" by Internet Explorer itself. However, if this UTF encoded text is included inside a file it will be saved without being decoded.

This may allow attackers to fool the software into thinking attached file should be decoded, when in fact it should not.

For example:

Content-Type: text/html;

charset=utf-7;

name="trojan.exe"

This header should not be decoded from utf-7 before checking its content, because it will be saved by Internet Explorer (or MUA) as is.

So it's possible that this is a malware attempt that works only through the webmail interface? I have already deleted the email so I will have to recreate the email from the text, headers and all.

Would you mind decoding some more of the headers - if it is not too much trouble. What ay help would be for you to see more accurate headers from a legitimate email.

The email notification I received informing me about your post contained the following headers:

Microsoft Mail Internet Headers Version 2.0

Received: from mail1.mil-tec.com ([192.168.8.254]) by Corpsrv4.MiltecCorporation.local with Microsoft SMTPSVC(6.0.3790.3959);

Tue, 6 May 2008 13:21:01 -0500

Received: from exchangeE250.miltec.com ([192.168.8.250]) by mail1.mil-tec.com with Microsoft SMTPSVC(6.0.3790.3959);

Tue, 6 May 2008 13:21:01 -0500

Received: from zeta.cesmail.net(64.88.168.67) by exchangeE250.miltec.com via csmap

id b206359a_1ba0_11dd_8d70_000347fa27c4_22852;

Tue, 06 May 2008 14:14:48 -0500 (CDT)

Received: from localhost (localhost [127.0.0.1])

by zeta.cesmail.net (Postfix) with SMTP id 64065DC8057

for <tcaudill[at]mil-tec.com>; Tue, 6 May 2008 14:21:00 -0400 (EDT)

Thank you,

[rconner]

Rick, thanks for the input. The line that you did decode is basically accurate and shows receipt of the email by my internal server from my smtp server in the permiter network.

[snip]

So it's possible that this is a malware attempt that works only through the webmail interface? I have already deleted the email so I will have to recreate the email from the text, headers and all.

Would you mind decoding some more of the headers - if it is not too much trouble. What ay help would be for you to see more accurate headers from a legitimate email.

The email notification I received informing me about your post contained the following headers:

Thank you,

Actually, the line I quoted is NOT accurate, it contains stray characters that would probably stop SpamCop (or other mail scanners) from parsing it.

On the evidence, I consider it rather unlikely that this is a "malware attempt" (at least not because of the munged headers). I think it is a case of the mail packet having been munged sometime between its receipt by your service and its passing-on to SpamCop. I think it may likely have been an innocent malfunction somewhere. It could be that the spammers did something that triggered the re-encoding by your service when it received the mail. If this message really did have headers that looked like that during delivery, it is hard for me to see how it could ever have been delivered. I'd suggest taking this up with your provider, perhaps they have some insight. I would also not rule out the behavior of your web browser or e-mail program with respect to UTF-7. It would appear from your tracker that the entire raw packet was treated as UTF-7 rather than ASCII. The relative rarity of UTF-7 messages might mean that you just suddenly found a bug somewhere.

There was a recent thread about other unicode characters somehow sneaking into headers. Maybe you might find something there that correlates.

I would rather not decode any more of your header, at least not in public, because it could reveal info that you might not want revealed. Also, I'd hate for you to take action based on what I consider to be a highly-suspect decoding. You are free to find your resources for this purpose. When you do, I'd offer a tip: replace the "utf-7" in these expressions with "iso-8859-1" (which is close enough to ASCII) and the EW decode shoud go well (although it will not be accurate, the UTF-7 escapes will still appear).

-- rick

[tcaud]

I understand and thank you.

I will continue to look for other items that will help me to decode this.

[rconner]

I will continue to look for other items that will help me to decode this.

RFC 2047 may be of help to you, if you can read RFCs.

-- rick

[Wazoo]

So it's possible that this is a malware attempt that works only through the webmail interface?

I started doing some research just after you made the Starting Post. However, real life got me involved again.

In general, searching or utf-7 does seem to bring up the primary usage as being a way to accomplish some cross-site-scripting (usually seen as XSS exploits) ... a way of palcing some uer-provided input data to a web-page/application that ends up being detrimental to folks that hit that web-page later. I don't recall stumbling across anything that suggested a 'good' reason to use utf-7 encoding. Well, not totally true;

UTF-7 introduced a system called Modified Base64. This data encoding scheme is used to encode the UTF-16 used as an intermediate format in UTF-7 into printable ASCII characters. 

It is a variant of the base64 used in MIME. UTF-7 was intended to allow use of unicode in e-mail without using a separate content transfer encoding. The main difference it has versus the MIME variant base64 is that it does not use the "=" symbol for padding, as that character tends to require a fair amount of escaping. Instead, it pads the octet bits with zeros. 

Modified Base64 is standardized as RFC 2152, A Mail-Safe Transformation Format of Unicode.

Of course, you just have to love this fantatstic scenario;

UTF-7 introduced a system called Modified Base64. This data encoding scheme is used to encode the UTF-16 used as an intermediate format in UTF-7 into printable ASCII characters.

In contrast to the massive list of applications that do not handle utf-7, IE naturally seems to want to go right ahead and decode this crap, which is why it's used for the exploits. OE seems to handle it OK also, primarily because it uses IE for rendering ... which again is why OE is/was so exploitable.

Not mentioned in your Starting Post, the fact that you snagged this via SpamCop.net WebMail application suggests why you saw everything as plain-text .. which is exactly by design. However, as rconner states, I have no idea how those headers got into that condition.

I am not sure of 'the question' to try to send upstream on this at present. Kind of wanting to wait to see if the source of this stuff can be identifed first ...??? Screw it, took the easy way out ... won't try to ask a specific question ...

From: "Wazoo"

To: "SpamCop Deputies"

Cc: "JT"

Subject: (probably modified) utf-7 encoding of header line data - parser doesn't decode

Date: Tue, 6 May 2008 20:35:23 -0500

Looking for input from you folks.

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

Tracking URL provided;

http://www.spamcop.net/sc?id=z1862658043z8...299b8b42bc261az

Issue 1: parser doesn't decode the utf-7 data

Issue 2: how the headers may have gotten to that condition

Issue 3: impact on filtering and handling by the WebMail application

[rconner]

I started doing some research just after you made the Starting Post. However, real life got me involved again.

Good questions for the deputies. The answers will be interesting no doubt.

I looked at tcaud's raw message source again, this time with Firefox, which will decode UTF-7 (although not the UTF-7 EW's in the headers). Nothing suspicious at a glance in the body of the message (just a block of HTML with some normal layout tags).

I am still scratching my head as to how SMTP headers get turned into UTF-7 Encoded Words (in Base64, yet).

-- rick

[Wazoo]

I looked at tcaud's raw message source again, this time with Firefox, which will decode UTF-7 (although not the UTF-7 EW's in the headers). Nothing suspicious at a glance in the body of the message (just a block of HTML with some normal layout tags).

I am still scratching my head as to how SMTP headers get turned into UTF-7 Encoded Words (in Base64, yet).

I'm thinking that those header lines are as described in my 'quoted' section about Modified Base-64. Can also point out that several Base-64 decoders I tried couldn't make any sense out of the data in those header lines, almost all complaining about the illegal characters I was trying to feed them.

Again, my research didn't answer any of this, as almost all descriptive stuff talked about the body contents. The majority of stuff I looked at dealt with the problems folks were having with so many applications that either broke or simply would not handle utf-7 stuff at all. Which, with all that type of traffic, also asks the same question you brought up, how coud this e-mail have navigated through the various Hosts ... which then indirectly also asks just when and how those lines may have been translated. I agree, at this point, I'm more than a bit lost.

[rconner]

I'm thinking that those header lines are as described in my 'quoted' section about Modified Base-64. Can also point out that several Base-64 decoders I tried couldn't make any sense out of the data in those header lines, almost all complaining about the illegal characters I was trying to feed them.

You need more than a UTF-7 decoder: you need a MIME Encoded-Word decoder. The routing lines (and other items) in the header somehow got rewritten as EWs.

Here's a subject line that has a couple of EWs in it:

=?ISO-8859-1?b?WW91IGg=?=ave been depre=?ISO-8859-1?b?c3NlZCBsYXRl?=ly!

The EW looks like "=?(charset)?(MIME-encoding)?(data)?="

Unraveling these is a two-step process: you first have to apply the correct MIME decode ("b" for base64, "q" for quoted-printable) to the data. Then, you have to render the data using the specified charset. In the cases above, you have to run base64 decode on the little chunks of data, and then have your browser (or whatever) render them in ISO-8859-1 glyphs (ISO-8859-1 = "Latin 1" ~= standard Windows 1252).

If you PM me, I can point you to a rather stunted decoder (that only works with Latin-1).

-- rick

[Wazoo]

You need more than a UTF-7 decoder: you need a MIME Encoded-Word decoder. The routing lines (and other items) in the header somehow got rewritten as EWs.

Unraveling these is a two-step process: you first have to apply the correct MIME decode ("b" for base64, "q" for quoted-printable) to the data. Then, you have to render the data using the specified charset. In the cases above, you have to run base64 decode on the little chunks of data, and then have your browser (or whatever) render them in ISO-8859-1 glyphs (ISO-8859-1 = "Latin 1" ~= standard Windows 1252).

Oh yeah, I glanced at/scrolled through a number of encoding/decoding sites, explanations, and manipulations. All the while wondering just why .. and of course just what the folks that came up with it really did for a living <g>

If you PM me, I can point you to a rather stunted decoder (that only works with Latin-1).

I actually did snag a few scripts and such. However, I need to fire up a full Linux system to play with those.

I've got Damn Small Linux booted on a Pentium II with little RAM, but ... lacks the power tools and languages needed for stuff like this. Other option would be to reboot this system into a Live-CD Ubuntu session, but .. I've got too much other stuff opened up right now that I need to finish up. ... Shoot! just remembered that I've got someone else's Vista laptop in the other room .... now, if it'll boot up into Ubuntu or not ....

//off topic// Where all these "just switch to Linux" folks when you need them? <g> Fiddled around with a Celeron machine the other day. Could get it to boot into Knoppix 4 with a bunch of boot-line exceptions, but nothing newer. Ubuntu live-CDs with versions from 4 though the current 8.04 wouldn't fly no matter how I tried to abuse them. Won't try to come up with all the other distros I tried with no real luck, some almost making it to a desktop before crashing. I was working with UNIX and XENIX back in the 80's, had experience with Sun (got called over to see if I could work around the problem the IBM guys were having with a newly delivered Sun mainframe ... first thing I discovered was that some lowlife had changed the root account to r00t ..loads of fun to try to work back through <g>) But all I see these days is that you have to be lucky enough to have a complete system with just the right chipsets, cards, and connected equipment available to make things such a simple 'switch' Noting that some of this is also impacting Vista users, the problems of drivers, drivers, and drivers ...

[tcaud]

I submitted the same initial information to the Intenet Storm Center for their input. Their inital assessment is that my Exchange server altered the headers. I disagree since it is only the two (so far) out of hundreds.

They deocded the headers (without translating the +A?? words) to show that the email in question originated from a host in Brazil: from 201008232124.user.veloxzone.com.br(201.8.232.124)

I believe that one of two possibilities may be happening here:

1. The server recieved the email from the host already encoded in this way, so it processed it the same way and passed it on. If this is true, wouldn't that be a bad thing?

2. Our anti-virus solution encoutered an error (hiccup?) during processing and altered the headers of the email in this fashion prior to release. However, since there is more than one internal server which scans the email, while it could have been the last one to touch the email, I think that #1 is more likely since it has only occurred twice so far.

I appreciate all of the input.

[tcaud]

By the way, just to make sure I'm not misunderstood, I don't expect SpamCop to alter their processing in any way to handle this kind of situation.

Gotta run now, my webmaster account is getting deluged with misdirected bounces. I'll be submitting them all to SpamCop!!

[tcaud]

Received two more this morning, however, they came in the form of the misdirected bounces.

The tracking URLs are:

http://www.spamcop.net/sc?id=z1865911724zb...6430b6f3d3c907z

http://www.spamcop.net/sc?id=z1865911754z3...65976b30f2f7f4z

However, in the message options on my client, the internet headers are displayed correctly and not encoded in the same way that the processed email is shown in the tracking reports. The previously reported emails showed the same encoded headers when viewed on the client.

This leads me to believe that the email is originating from the source with the non-standard encoding.

I have saved the two emails reported above in my client for further review should either of you wish to view them.

[Wazoo]

However, in the message options on my client, the internet headers are displayed correctly and not encoded in the same way that the processed email is shown in the tracking reports. The previously reported emails showed the same encoded headers when viewed on the client.

I'm not sure you've actually identified "your client" .. just noting that I did point out that OE/IE have tendencies to automatically adjust to read utf-7 stuff. FoireFox has a specific setting (no idea about Thunderbird)

This leads me to believe that the email is originating from the source with the non-standard encoding.

Would not argue. Recall numerous places where it was mentioned that replacing 7-bit servers with 8-bit servers was one thing that held up utf-8, Base-64, and a few other things involved with e-mail transfers.

I have saved the two emails reported above in my client for further review should either of you wish to view them.

I am having some dialog with Ellen ... rather wishing that this would be handled 'here' rather than in the 'background'

[tcaud]

I'm not sure you've actually identified "your client" .. just noting that I did point out that OE/IE have tendencies to automatically adjust to read utf-7 stuff. FoireFox has a specific setting (no idea about Thunderbird)

The client is Outlook 2007. It may be that it will display them correctly due to its close integration with IE.

[tcaud]

Had another one as a misdirected bounce message today. I am paying a bit closer attention now to these.

The submission shows here: http://www.spamcop.net/sc?id=z1869570720z7...2273899fefff3bz

When I look at the headers in Outlook, I don't see the differently encoded items shown in the SpamCop report. the relevant part of the headers when viewed in Outlook is below:

Received: from hpsmtp-eml15.kpnxchange.com(213.75.38.115) by exchangeE250.miltec.com via csmap 
	 id 04ca0ad0_1d2d_11dd_9e08_000347fa27c4_23954;
	Thu, 08 May 2008 13:31:48 -0500 (CDT)
Received: from hpsmtp-eml31.kpnxchange.com ([213.75.38.86]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 8 May 2008 19:37:11 +0200
Received: from cpbrm-eml18.kpnsp.local ([195.121.247.250]) by hpsmtp-eml31.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 8 May 2008 19:37:11 +0200
Received: from cpsmtpb-eml01.kpnxchange.com ([10.94.53.250]) by cpbrm-eml18.kpnsp.local with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 8 May 2008 19:37:12 +0200
Received: from localhost ([10.94.53.250]) by cpsmtpb-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 8 May 2008 19:37:11 +0200
From: postmaster[at]kpnxchange.com
To: webmaster[at]mil-tec.com
Date: Thu, 8 May 2008 19:37:11 +0200
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="9B095B5ADSN=_01C8B0B54793D66F000B733ACPEXBE?EML09.kpn"
X-DSNContext: 7ce717b1 - 1158 - 00000002 - 00000000
Message-ID: <aDPB24U1f00670f53[at]CPEXBE-EML09.kpnsp.local>
Subject: Delivery Status Notification (Failure)
Return-Path: <>
X-OriginalArrivalTime: 08 May 2008 17:37:11.0596 (UTC) FILETIME=[25842EC0:01C8B132]

--9B095B5ADSN=_01C8B0B54793D66F000B733ACPEXBE?EML09.kpn
Content-Type: text/plain; charset=unicode-1-1-utf-7

--9B095B5ADSN=_01C8B0B54793D66F000B733ACPEXBE?EML09.kpn
Content-Type: message/delivery-status

--9B095B5ADSN=_01C8B0B54793D66F000B733ACPEXBE?EML09.kpn
Content-Type: text/rfc822-headers


--9B095B5ADSN=_01C8B0B54793D66F000B733ACPEXBE?EML09.kpn--

So, now I am back to the question of is it my server/AV mangling this upon forwarding/submission?

Or, am I viewing the headers of the bounce message and SpamCop is stripping the bounce message in order to attempt to find the source of the spam? I am not sure of the process SpamCop takes when submitting/parsing a misdirected bounce.

[StevenUnderwood]

So, now I am back to the question of is it my server/AV mangling this upon forwarding/submission?

Or, am I viewing the headers of the bounce message and SpamCop is stripping the bounce message in order to attempt to find the source of the spam? I am not sure of the process SpamCop takes when submitting/parsing a misdirected bounce.

If you see what is in the code box before forwarding and what is in the report on the spamcop system, then it would seem to be your (or your ISP's) system that is corrupting the message.

SpamCop does not look at the attachments of the emails you forward, even for a bounce. Now, if the attachment from the bounce were somehow attached to your submission message, then spamcop would attempt to parse those. Have you looked at the headers in the attachment indicated by the: Content-Type: text/rfc822-headers? Do they look like your submission?

[Wazoo]

Had another one as a misdirected bounce message today. I am paying a bit closer attention now to these.

The submission shows here: http://www.spamcop.net/sc?id=z1869570720z7...2273899fefff3bz

When I look at the headers in Outlook, I don't see the differently encoded items shown in the SpamCop report. the relevant part of the headers when viewed in Outlook is below:

Unfortunately, more confusion factors added to the story. Your suggested Outlook view says;

From: postmaster[at]kpnxchange.com
To: webmaster[at]mil-tec.com
Date: Thu, 8 May 2008 19:37:11 +0200
Message-ID: <aDPB24U1f00670f53[at]CPEXBE-EML09.kpnsp.local>

However, your Tracking URL shows;

Date: Thu, 8 May 2008 12:38:09 -0500
Message-ID: <aDPB_________0f53[at]CPEXBE-EML09.kpnsp.local>
From: "System Administrator" <postmaster[at]mil-tec.com>
To: =?utf-7?B?TWlsdGVjK0FGOC1XZWJtYXN0ZXI=?= <x>

It doesn't appear that we are looking at the same data between these views. Tracking URL apparently being the DSN, the Outlook view apparently being the embedded copy of the wrongly addressed e-mail that caused the DSN. And having to note the long-standing issue of interactions between Outlook and an Exchange server (Note: I don't believe the version of this server has been identified) and the way things are handled between the two.

So, now I am back to the question of is it my server/AV mangling this upon forwarding/submission?

Or, am I viewing the headers of the bounce message and SpamCop is stripping the bounce message in order to attempt to find the source of the spam? I am not sure of the process SpamCop takes when submitting/parsing a misdirected bounce.

Where we are all at right now. Going upstream didn't help. A ticket to the programming/engineering staff isn't going to be opened up, as this is the only instance of this issue at this point. As seen in a prior post, I included the link to this Discussion, primarily to rule out the scenario that "Wazoo's words are confusing" .. this apparently didn't help. And now that you also brought up "the process" ....

1. I had been repeatedly asked how this spam e-mail was submitted. I repeatedly stated that I really didn't know. So, to answer that, would you explain step-by-step just how these are being handled. Yes, you've stated an Exchange serv is in the mix, you pointed to Outlook 2007. What's being asked is the actual step-by-step process being used.

2. Again, there are no me-too posts, nothing on this over in the newsgroups, so 'we' are laft to try to discover just where the utf-7 is actually coming from.

3. You state that these are but a few among the massive spam-spew you're currently receiving. However, the only thing that seems to poke its head out as being a constant is the mil-tec.com Domain name. These last are also common in that they are allegedly DSN responses from somewhere else.

4. Anti-virus has been brought up, but not identified. That several servers scan the incoming, it has to be assumed that this is a comercial/enterprise application. Have you talked to them yet? I don't see that you stated this thus far.

5. As you mention that several servers are involved, are all of them configured 'exactly' the same? Is there any data available that might point to one server alone?

5. Paid staff would appreciate feedback if 'we' get this figured out.

SpamCop does not look at the attachments of the emails you forward, even for a bounce.

Geeze, I hate the way that reads ... especially when compared to all the How to Forward as an Attachment instructions <g>

Now, if the attachment from the bounce were somehow attached to your submission message, then spamcop would attempt to parse those. Have you looked at the headers in the attachment indicated by the: Content-Type: text/rfc822-headers? Do they look like your submission?

Kind of headed to the same spot as my request for a ste-by-step description of the submittal process. Yet, probably not the main issue, based on the "only a few of them" end up like this situation. But again, have to start somewhere.

[StevenUnderwood]

Geeze, I hate the way that reads ... especially when compared to all the How to Forward as an Attachment instructions <g>

It does read badly.... what I meant...

You forward (as attachment) an email that has an attachment itself (headers of the bounce). That internal attachment will be shown as part of the message and those headers should not be parsed for source.

(Still confusing, but I think better)

[tcaud]

I will do my best to answer your questions.

1. I had been repeatedly asked how this spam e-mail was submitted. I repeatedly stated that I really didn't know. So, to answer that, would you explain step-by-step just how these are being handled. Yes, you've stated an Exchange serv is in the mix, you pointed to Outlook 2007. What's being asked is the actual step-by-step process being used.

I submit email to SpamCop for review primarily by forwarding the email as an attachment to my submit email address. On a few rare occasions, I will use the copy/paste method. The email above was one of 6 total attached emails submitted tot he submission email address.

Hardware/software below.

2. Again, there are no me-too posts, nothing on this over in the newsgroups, so 'we' are laft to try to discover just where the utf-7 is actually coming from.

I hate being unique!!

3. You state that these are but a few among the massive spam-spew you're currently receiving. However, the only thing that seems to poke its head out as being a constant is the mil-tec.com Domain name. These last are also common in that they are allegedly DSN responses from somewhere else.

Not to sound like an a** here, but the first part would be because that is the company email domain that I administer.

On the second part, yes, until this morning when I received another that was not a DSN message. That was because of my habit of submitting the spam via attachments and then permenantly deleting the originals before completing processing...a habit that has temporarily changed.

4. Anti-virus has been brought up, but not identified. That several servers scan the incoming, it has to be assumed that this is a comercial/enterprise application. Have you talked to them yet? I don't see that you stated this thus far.

5. As you mention that several servers are involved, are all of them configured 'exactly' the same? Is there any data available that might point to one server alone?

Without getting into too much detail: Incoming sent directly to our network via MX record, scanned by McAfee e250 appliance (hence the header), passed to an Exchange 2003 SP2 front-end, scanned again by McAfee GroupShield, passed to an Exchange 2003 SP2 back-end, scanned again by GS, put in mailbox, delivered to client (in my case, Outlook 2007 SP1) scanned by McAfee AV Enterprise ed.

Outgoing scanned at the same two Exchange servers and delivered out to the internet destination mx record directly from the front-end.

We do not use a smart-host or other intermediary mail server at the ISP, etc.

I think that covers everything...

5. Paid staff would appreciate feedback if 'we' get this figured out.

Good to know.

Latest email this morning:

From Outlook Message Options - Internet Headers:

Microsoft Mail Internet Headers Version 2.0
Received: from mail1.mil-tec.com ([192.168.8.254]) by Corpsrv4.MiltecCorporation.local with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 8 May 2008 16:27:01 -0500
Received: from exchangeE250.miltec.com ([192.168.8.250]) by mail1.mil-tec.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 8 May 2008 16:27:01 -0500
Received: from 137.red-81-35-120.dynamicip.rima-tde.net(81.35.120.137) by exchangeE250.miltec.com via csmap 
	 id fcd8c2ba_1d4c_11dd_955a_000347fa27c4_32242;
	Thu, 08 May 2008 17:20:39 -0500 (CDT)
Message-ID: <000e01c8b15a$a19dde70$09297784[at]Vista>
From: "Bonnie Marshall" <xmclarify[at]dekaroline.ru>
To: "Postmaster" <postmaster[at]mil-tec.com>
Subject: Proof is pleasant for you
Date: Thu, 8 May 2008 22:26:59 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
		boundary="----=_NextPart_000_000B_01C8B15A.A19DDE70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.0000
Return-Path: xmclarify[at]dekaroline.ru
X-OriginalArrivalTime: 08 May 2008 21:27:01.0814 (UTC) FILETIME=[41207560:01C8B152]

------=_NextPart_000_000B_01C8B15A.A19DDE70
Content-Type: text/plain;
		charset="UTF-7"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_000B_01C8B15A.A19DDE70
Content-Type: text/html;
		charset="UTF-7"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_000_000B_01C8B15A.A19DDE70--

SpamCop submission tracking link:

http://www.spamcop.net/sc?id=z1871540478zc...45a2b9b244f946z

The above email was submitted using the submission email address assigned to me. It was 1 of 25 attached emails in a single submission email. It is the only one in that group that had this issue. (I hope that wasn't too confusing.)

I, like you, am trying to find some common item with each email...as of yet, I have not contacted any manufacturer's support since I do not have any clue what may be causing this. There are no errors or warnings on either server or within the AV solution.

I also do not understand the differences shown between the Outlook Internet Headers view and the SC parsing.

As I was writing this, I received another one. Submitted via email as attachment, only one in this submission. Tracking link:

http://www.spamcop.net/sc?id=z1871752263zb...7e6bf1d288771cz

From Outlook:

Microsoft Mail Internet Headers Version 2.0
Received: from mail1.mil-tec.com ([192.168.8.254]) by Corpsrv4.MiltecCorporation.local with Microsoft SMTPSVC(6.0.3790.3959);
	 Fri, 9 May 2008 08:15:03 -0500
Received: from exchangeE250.miltec.com ([192.168.8.250]) by mail1.mil-tec.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Fri, 9 May 2008 08:15:03 -0500
Received: from unknown(189.72.29.101) by exchangeE250.miltec.com via csmap 
	 id 6c009256_1dd1_11dd_921d_000347fa27c4_9080;
	Fri, 09 May 2008 09:08:39 -0500 (CDT)
Message-ID: <001a01c8b1bd$8b622720$00faf3a4[at]MAQ4>
From: "Alexandra Holland" <jisunshine[at]dangly.co.uk>
To: "Extranet" <extranet[at]mil-tec.com>
Subject: You do not want to their stores
Date: Fri, 9 May 2008 10:15:02 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
		boundary="----=_NextPart_000_0017_01C8B1BD.8B622720"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.1409
Return-Path: jisunshine[at]dangly.co.uk
X-OriginalArrivalTime: 09 May 2008 13:15:03.0349 (UTC) FILETIME=[B129E650:01C8B1D6]

------=_NextPart_000_0017_01C8B1BD.8B622720
Content-Type: text/plain;
		charset="UTF-7"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0017_01C8B1BD.8B622720
Content-Type: text/html;
		charset="UTF-7"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_000_0017_01C8B1BD.8B622720--

The common thing between these two (besides my submission path and email domain) is that Outlook is showing charset="UTF-7" When I saw that in the headers on Outlook, I thought we might see this one have the same issue.

I haven't noticed if any other UTF-7 emails demonstrate this problem. I will be watching closely for that now.

Sorry for the long post.

[Telarin]

I run an Exchange 2003 SP2 server, and have never had this happen on any of the many thousands of emails I have submitted from Outlook 2003, so I think we can probably safely eliminated Exchange as the source of the headache. That leaves the various anti-virus products, as well as Outlook 2007 as our primary suspects for header mangling culprits.

Outlook generally doesn't play with headers, so I think it is unlikely, though not impossible, that it is the problem. That leaves the anti-virus products as our remaining likely suspects. We already know that they play with the headers, because they insert their own header lines into the email. I am wondering if one of them is "fixing" the headers for you by translating them to the "UTF-7" specified in the email, and then outlook is translating it back so it appears "correct" when viewed in outlook, but is not correct when forwarded as it is forwarded in the UTF-7 that made it to your inbox.

One test you might try is finding one of these problem email that you have submitted before, and try resubmitting it using the web page submission form. I am guessing that since you will be submitting the headers as translated by Outlook, rather than the original UTF-7 mangled headers, it will work, however, I would like you to try it just to be sure.

[Wazoo]

I submit email to SpamCop for review primarily by forwarding the email as an attachment to my submit email address. On a few rare occasions, I will use the copy/paste method. The email above was one of 6 total attached emails submitted tot he submission email address.

Ah yes, but the step-by-step was bypassed here. Submitting spam from Outlook has been a long-standing issue. For example, please see Outlook applications, Utils to show the source of email in Outlook .. just the most current Discussion about this specific issue, also based on just what version of Outlook are involved. As seen there, a number of ways are documented to try to successfully submit a spam via e-mail/Outlook.

Not to sound like an a** here, but the first part would be because that is the company email domain that I administer.

That's my status, position, title, whatever. <g> But again, the only data I have to go on is what's presented in the posts here, thus what seems to possibly be stupid questions, some ignorant statements, etc.

Without getting into too much detail: Incoming sent directly to our network via MX record, scanned by McAfee e250 appliance (hence the header), passed to an Exchange 2003 SP2 front-end, scanned again by McAfee GroupShield, passed to an Exchange 2003 SP2 back-end, scanned again by GS, put in mailbox, delivered to client (in my case, Outlook 2007 SP1) scanned by McAfee AV Enterprise ed.

Thanks for that, although .. gads .. what a combination and wicked path ...

Good to know.

Hmmm, that wasn't my reaction <g>

The above email was submitted using the submission email address assigned to me. It was 1 of 25 attached emails in a single submission email. It is the only one in that group that had this issue. (I hope that wasn't too confusing.)

Not confusing .. but there's still the question as to how these things were 'added as an attachment" ..??

I, like you, am trying to find some common item with each email...as of yet, I have not contacted any manufacturer's support since I do not have any clue what may be causing this. There are no errors or warnings on either server or within the AV solution.

Not sure I can see anything that would be a trigger for an error actually.

I also do not understand the differences shown between the Outlook Internet Headers view and the SC parsing.

Again, I believe it's due to Outlook (in conhunction with IE) actually doing that (unwanted) translation for you. The catch seems to be that the Outlook generated e-mail is sending the submittal out as it actually seems to exist.

The common thing between these two (besides my submission path and email domain) is that Outlook is showing charset="UTF-7" When I saw that in the headers on Outlook, I thought we might see this one have the same issue.

I believe you are referencing the Boundary defintions in that remark. We don't really care about the body contents at this point. It's the 'converted' header lines that are cauing the problem.

The closest thing to a definition in the headers is Content-Type: multipart/alternative;boundary="----_=_NextPart_003_01C8B1D6.B0F4A580" ... but that should not directly impact the header data .. only stating that the body has several 'sections' ... what application that might decide to look at the body content and then decide to return and 'translate' the header data is simply beyond me at present. I'm with Will, the most obvious target would seem to be an application that adds data to the headers, which in this case does seem to point to one of the anti-virus tools.