Can Received: fields be spoofed? - Page 2
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Can Received: fields be spoofed?

  1. #11
    AO's MMA Fanatic! Computernerd22's Avatar
    Join Date
    Mar 2003
    Miami, FL
    The IP cannot be forged, the attacker can however use a proxy to connect to a mailserver and thus his IP won't be visible to you
    I agree with el-half on this. I know from personal experience (no I'm not a spammer) you can send Anonymous e-mail if you use this method. Use an anonymous proxy server to surf then net find a system thats running smtp server (simple mail transfer protocol) on port 25. Use the telnet client to bring up a shell prompt on the remote system then issue smtp commands to the SMTP server to make spoof *e-mail*. This is Very simple. A simple google search proves this:

    As far SMTP being secure. Nope not in my opionion. 70% of SMTP servers out there allows anonymous access to the SMTP server. Large security hole.

  2. #12
    Join Date
    Mar 2004
    jonathans_daddy, So what you're saying is, that a malicious user can add as many Received: fields as they want to an email and even attach valid IP's to make it seem like the email did indeed go through mail servers that it never did?.
    Yes, but some servers (like mine) will refuse to accept the message if there are too many (&gt;25 if memory serves) recieved headers because it assumes the message is bouncing back and forth between a couple of misconfigured servers.

    Is it possible that a malicious user who received an email from my company at some point, to expand the full valid path in the email header, then use any old random mail server, forge in the appropriate Received: fields (that they copied from a valid email my company sent) with valid IP's and mail servers and create an email that for all practical purposes, will appear to have come from within my network?
    Yes. Would you like a demonstration? What's your email address?

    It would seem that if that is indeed the case, the only way to determine if an email originated from within my network would be to actually monitor all outgoing emails (which we currently do) and tracing emails through server transactions, would be utterly pointless.
    Log files work well for determiing whether a message truly came from within your network.

    **note - I just thought about something else. Don't the mail servers keep records of transactions? Wouldn't it be possible to take an email, even with Received fields that made it appear as though it came from within my network and compare it to some database on the actual mail server itself? I know most (if not all) mail servers attach an ID number to the transaction. no?
    If your mail server keeps such a database, then yes. Mine doesn't so I use the logfiles.

  3. #13
    Join Date
    Mar 2004
    That's probably what it is, but what if it isn't? If I'm correct, smtp doesn't have any authentication built in, so wouldn't it be pretty easy to do what ShagDevil is talking about?
    As long as you don't expect an answer back, can't you just spoof all the headers, including the IP?
    Most SMTP doesn't require authentication, but if you're worried about people abusing your mail server you should require authentication for anyone claiming to be from your domain and not connecting from one of your IP addresses. This can be accomplished in a couple of ways... POP before SMTP (user must check his mail before he/she can send) or setting up SMTP AUTH (

    And yes, you can spoof all the headers *except* the ones that your mail server adds to the message when it receives it. That's how you can know which computer out there delivered it to you. Other than that, everything else is suspect.

  4. #14
    AO Ancient: Team Leader
    Join Date
    Oct 2002

    Log files don't just help you with email.....

    Log files are the final defense for the adminstrator that is bothered about security, period.

    It might seem like a high overhead to log _every_ last connection you can to your network and set the most verbose logging of every service you provide but it isn't anything like the overhead of looking at 500 workstations and wondering which ones _might_ be compromised....

    Of course, you also have to be able to interpret them.......


    Ladies and Gentlemen, please return to your normal programming...

  5. #15
    Some Assembly Required ShagDevil's Avatar
    Join Date
    Nov 2002
    New Jersey
    Well, I appreciate all the help and attention you guys have offered. It seems the ultimate solution in this case is to keep the log files of all our emails up to date, amongst other things. I can honesty admit that although we have been keeping logs of our emails, I haven't paid much attention to them until now.
    tsk tsk on me

    Maybe in the future, we can implement some kind of PGP but, right now, it's just not feasible for us to take on a task of that magnitude(we have a crap load of clients on our exchange server database). I'm also not very familiar with PGP and I don't want to go start screwing around with it until I can catch up on some reading first.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

 Security News


       Security Trends


           Buying Guides