• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Microsoft IIS SMTP logging / mail tracking

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Microsoft IIS SMTP logging / mail tracking

    I must be getting desperate.

    We have a gateway Win 2003 cluster before passing emails to a SendMail box in a DMZ then going to outside world.

    We are finding some outbound emails some of the time are being delayed with a 4.4.7 notification to the sending user.

    Unix/DMZ folk say there is a delay on the message getting to DMZ but it isn't clearly in our queue. We check smtp logs (all options are ticked) but there is no unique message ID. There is such a volume of mail (several per hour from similar senders and to same recipients) that I'm finding it hard to work out which log entry belongs to which email.

    There are concurrent threads meaning that the usual EHLO, MAIL, RCPT, DATA, QUIT sequence isn't followed in the logs. I hope it is followed in practice. How do you follow these when there is no way to link the starting EHLO, MAIL, RCPT commands with their corresponding DATA, QUIT parts ?

    Here is an example where I'm working at Company.com



    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 EHLO - +DMZ.Unix.mail.server 250 0 244 17 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 MAIL - +From:<[email protected]> 250 0 48 46 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 34 31 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 EHLO - +DMZ.Unix.mail.server 250 0 244 17 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 MAIL - +From:<[email protected]> 250 0 50 47 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 24 21 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 35 32 16 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 32 29 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 34 31 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 38 35 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 EHLO - +DMZ.Unix.mail.server 250 0 244 17 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 MAIL - +From:<[email protected] .com> 250 0 84 96 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 RCPT - +To:<[email protected]> 250 0 35 32 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 DATA - +<[email protected] domain> 250 0 140 23341 266 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 QUIT - DMZ.Unix.mail.server 240 266 71 4 0 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 DATA - +<[email protected]> 250 0 127 27286 343 SMTP - - - -
    2009-12-06 23:00:09 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 QUIT - DMZ.Unix.mail.server 240 343 71 4 0 SMTP - - - -
    2009-12-06 23:00:10 201.1.1.55 DMZ.Unix.mail.server SMTPSVC1 GFI_smtp_server 10.108.1.80 0 QUIT - DMZ.Unix.mail.server 240 1313 71 4 0 SMTP - - - -



    Am I missing a trick here?
    Last edited by LegendsWear7; 8 December 2009, 17:15. Reason: more readable

    #2
    You ought to be looking at the sendmail logs on the DMZ server because the Windows Server log suggests success (SMTP codes 2XX).

    Consider:
    Have they installed a tarpit on the DMZ/sendmail?
    Are the forward and reverse DNS resolutions working for both machines?
    Has the sendmail machine been blacklisted by the spam houses?

    Comment


      #3
      you can use logparser for this sort of stuff

      http://www.microsoft.com/downloads/d...displaylang=en

      Log parser consists of three components, which are: 1) input engine, 2) SQL query engine, and 3) output engine. The input engine and output engines are truly incredible and, combined, make this tool shine. When investigating network intrusions, you are faced with analyzing logs from many sources, none of them being compatible with the other. Log parser can accept most any common log format and output it into one of many formats of your choosing. When you are done, you can combine all your disparate logs into one common format for analysis.

      At any point in the process you can subject your logs to a query so that you narrow down the data to that which is relevant. While many GUI tools are out there that provide filters, even those that allow the user to build custom filters can't compare with the power of writing a custom SQL query in Log Parser.

      As an intrusion investigator / forensic examiner, you are tasked with mastering many tools to get your work done. It would be nice if we only had to master a couple of tools, but such will never be the case. We can however, limit the number of tools we have to use if we make careful selections. Whenever you can use one tool that will handle multiple tasks instead for multiple tools for the same number of tasks, that should be your tool of choice. Log parser fits this criteria as it can process and query all the common logs formats and can address your file system and your registry as well, including those of remote systems.

      The best way to get to know this tool is to use it daily in the administration of your systems. You can create batch files to run your SQL queries against your logs, place them in your scheduler, and have critical log reports sitting on your desktop each day when you come to work. By getting to know this tool and its capabilities in this manner, you can apply those acquired skills to forensic applications of this tool. In the end, you'll have better management of your systems and have a forensic tool that you'll find new uses for with every case you process.
      From: http://128.175.24.251/forensics/logparser.htm
      Coffee's for closers

      Comment

      Working...
      X