Lking Posted April 7, 2009 Share Posted April 7, 2009 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? Link to comment Share on other sites More sharing options...
Wazoo Posted April 7, 2009 Share Posted April 7, 2009 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. Link to comment Share on other sites More sharing options...
Farelf Posted April 7, 2009 Share Posted April 7, 2009 ...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. Link to comment Share on other sites More sharing options...
Lking Posted April 7, 2009 Share Posted April 7, 2009 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. Link to comment Share on other sites More sharing options...
Wazoo Posted April 7, 2009 Share Posted April 7, 2009 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 Link to comment Share on other sites More sharing options...
Lking Posted April 7, 2009 Share Posted April 7, 2009 ...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 Link to comment Share on other sites More sharing options...
Ellen Posted April 7, 2009 Share Posted April 7, 2009 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 Link to comment Share on other sites More sharing options...
Wazoo Posted April 7, 2009 Share Posted April 7, 2009 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. Link to comment Share on other sites More sharing options...
StevenUnderwood Posted April 7, 2009 Share Posted April 7, 2009 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 Link to comment Share on other sites More sharing options...
brantgurga Posted April 7, 2009 Author Share Posted April 7, 2009 After looking through some Outlook knowledge base articles, it looks like this one is potentially related: http://support.microsoft.com/default.aspx/kb/907985 It talks about reordering and changing things in conjuction with custom message properties. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.