Jump to content
Sign in to follow this  
brantgurga

Received header order

Recommended Posts

Well, yes - IF similar is in the outer 'envelope' that the reporter uses to 'forward as attachment' to SC but which is stripped off by SC before developing the parse. We don't get to see that discarded stuff ordinarily (unless the 'stripping' goes awry which it almost never does under 'normal' circumstances). No reason to suppose it wouldn't be present though - but many unknowns in that statement.

I'm not suggesting that we would see it. I was suggesting that the X-Mailer: line in the outer header could be used to exclude submit or quick emails sent using OutLook, before the attachments even get to the parser.

I don't have Microsoft Office OutLook so I couldn't send myself an email so I could look at the header. So I looked at the emails I have received. I don't think it is to much of a stretch to assume other emails sent with OutLook would also have the X-Mailer line I quoted. We are talking about the mail client used by a reporter so I don't think we need to be concerned with forged headers.

Or am I missing something?

Share this post


Link to post
Share on other sites
There is no way that I know of to programatically do that -- if you have some suggestions we are certainly open to hearing them.

You are right. Not being a user I needed to check the details. How about this line?

X-Mailer: Microsoft Office Outlook, Build 11.0.6353

I found this in a received email. The full header

Here's my guess .... the parsing system e-mail submittal code chain now basically 'skips' over the e-mail's 'non-attachment' body content, rather following the MIME Boundary data to 'jump' to the meat of the submittal, et all, the 'enclosed' spam. This code was originally developed by Julian in the way, way-back days. For the most part, it is seen that this code has been in place and has worked just fine all these years.

What has been asked in light of this new restriction would be to insert another 'front-end' to that spam submitted by e-mail code section to actually check the header content of 'that' e-mail and then do a pass/fail/reject action if any evidence of Outlook or Exchange is seen. Though generally seen as not being too technical to code up, throwing it onto the production machines, adding yet more load to the Parsing & Reporting action/systems may actually cause some issues. What would seem to be the nasty part of the equation would be to find time for someone qualified/knowledgeable on Julian's wild code to make these changes/additions, compounded by the time and effort needed to create, test, and possible implement this new code section.

Of course, that's just me rambling on a bit.

Share this post


Link to post
Share on other sites
...Or am I missing something?
Nope, you've got it. Then as Wazoo says ... some more unknowns and issues, even if ... But yeah, I think you've found the key to programmic identification Lou.

Share this post


Link to post
Share on other sites
Nope, you've got it. Then as Wazoo says ... some more unknowns and issues, even if ... But yeah, I think you've found the key to programmic identification Lou.

My real concern is that without a way to reject OutLook submission, all reports are suspect. Not only can the spammer claim accusation by a garbled header, but the SCBL may not be valid.

As I typed that I realized that possibility of enough headers being jumbled the same way to get an IP listed is small (I guess). But all reports to ISPs could be questioned.

It seems to me that to retain SC credibility, time to design, code, test, install, etc. a preprocessor/front-end needs to be found.

Share this post


Link to post
Share on other sites

From the spamcop newsgroup, edited a bit;

Patto wrote:

>

> I think this is a very rare occurrence; I have been forwarding Outlook

> 2003 messages as attachments since - well, you guess it - and I have

> never had any problem with it.

I doubt that it is rare -- I suspect it is happening for all spam

forwarding for Outlook 2003 and 2007 *however* depending on how the

headers are scrambled the results of the parse may be more or less

accurate ...

And indeed it would be useful for anyone with outlook 2003/2007 posting

to this thread to do an imspection of the original headers as revealed

by looking at them in Outlook vs the headers once they are forwarded as

an attachment and report back ...

Ellen

SpamCop

Share this post


Link to post
Share on other sites
...the results of the parse may be more or less accurate ...

My point exactly, without knowing the source (OutLook or not) of the submission all spam reports are "more or less accurate." That is not the standard Julian established.

What can we expect an ISP to do when sent a more or less accurate report? Sure lets everyone off the hook. JMHO

Share this post


Link to post
Share on other sites
My point exactly, without knowing the source (OutLook or not) of the submission all spam reports are "more or less accurate." That is not the standard Julian established.

What can we expect an ISP to do when sent a more or less accurate report? Sure lets everyone off the hook. JMHO

let me rephrase that -- the results of the scrambling of Outlook forwarded as attachment submissions may result in the parser finding the wrong injection point.

Yes this is a big issue and yes we are working on figuring out how to handle this problem properly. Figuring out how to reliably locate the appropriate users and spams is complicated.

Ellen

Share this post


Link to post
Share on other sites

From a PM, some off-topic stuff, but ....

Hello, I just noticed your new post, http://forum.spamcop.net/forums/index.php?showtopic=10247 (to which, for some reason, I'm forbidden to add a comment)

Posting rights somewhat limited in the Announcements section, primarily to limit traffic there to just Announcements.

but isn't it old stuff? I thought that if you're using Outlook (not Outlook Express) you should only report using the "Outlook / Eudora workaround form" because other methods are unreliable with that mailer?

Per the 'Original/Official' FAQ referenced in that Announcement, there are third-party tools that have served in the past to 'handle' the e-mail submittal mode. There have been numerous suggested work-arounds that have been offered over the years that seemed to have worked (in the past) This 'new' restriction isn't yet talking to the web-form paste-it-in-the-box(es) .. yet.

Anyway, this is only idle curiosity on my part, since OT1H I use Seamonkey, whose "Forward as Attachment" is all right, but OTOH my ISP both (1) blocks me from accessing any SMTP server except its own

Sounds like the typical Port 25 blocking .... another e-mail server offering SMTP with authorization on alternate ports is also the typical work-around/scenario.

and (2) has a tendency to "drop on the floor" outgoing emails containing spam as attachment.

Topic at E-Mail spam submittals blocked by your ISP has a list of those folks .. are you talking about adding another ISP/Host?

Kudos for all the work you put into helping SC users! :)

And that I'll pass on to all the folks that help out in here. Much appreciated.

Share this post


Link to post
Share on other sites

Some data to show some of the issues:

Copy/paste from Exchange 6.5/Outlook 2003:

http://www.spamcop.net/sc?id=z2768729458zd...53eac50ece99d0z

Forward as attachment from Exchange 6.5/Outlook 2003:

http://www.spamcop.net/sc?id=z2768731487z3...abaac025082554z

In this example, the Received: headers have not changed order, but other headers have moved around, some were added and some were removed. Also, some long received: lines were wrapped (correctly).

Changes in the forward version is completely missing the following headers:

X-MimeOLE: Added

X-Server-Uuid: Removed

MIME-Version: Moved up above some Received: lines

Content-Class: Added

Subject: Moved up

Date: Moved up

X-MS-Has-Attach: Added

X-MS-TNEF-Correlator: Added

Thread-Topic: Added

Thread-Index: Added

User-Agent: Removed

X-WSS-ID: Removed

X-Content-Type: Likely converted from original Content-Type: by 2 part paste

boundary= changed, possibly by 2 part paste

Return-Path: Removed

X-OriginalArrivalTime: Removed

Content-Transfer-Encoding: Added

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×