Cybersecurity

Actually I thought about this myself lately... the reason you'd maybe want to change your ip is if your machine is on a multi-homed natted box and recieving mail from an internal LAN. Then it will report the internal address on the header, unless you do some more natting (madness in my eyes, since multiple NATS can be dodgy).

I don't want MR.Hacker to know the ip address of my internal machines ... do I .

Just change the macro in the sendmail.cf... oh and buy the Bat book just for extreme measure

Most of the time if you are doing NAT, its because your internal machines have addresses in the reserved ranges (ie 192.168.0.1, etc) -- in which case knowing this information does a hacker no good.

If your internal machines have real IP addresses, then this <I>might</I> be a reason to obscure the header information...personally I wouldn't go to the trouble. Would you start obscuring telnet/ftp/http session information too?

Thank you for so many ardent replies on this topic. In fact, at my side, it has no practical applications nor needs to spoof IP in email header. This question has been conceived for a long time and now been proposed to see the opinions from all side. Thanks again.

And, as if we hadn't kicked this dead whale down the beach long enough...

It may even be a violation of your ISP's Acceptable Use Policy to insert fake headers -- which probably means you lose your net connection if your ISP finds you doing this more than once. (They know that the only people who _really_ need to do this are spammers...).

An excerpt from the <A HREF="http://www.earthlink.net/about/policies/use/">Earthlink AUP</A>. (Earthlink is one of the largest ISP's in the US, so i figured its a decent example):

However, many people have Linux working at their homes as SMTP (sendmail) servers. We do not send mail through our ISP's server. We buy dial-up accounts just for getting Internet connections. Except for those Windows users, the rest (like Unix guys) prefer sending mails through their own **IX SMTP (sendmail) servers installed in their PCs.

So, mail header modification is now completely our own business and is not a violation of ISP policy.

But things are still hard. The recipients server anyhow knows the IP of the sender server and adds this portion into the email header when it receives a mail. The portion is like following,
--------------------------------------------
Received: from eddie_host.com([200.100.100.200]) by recipients_server.com (JetMail 2.5.3.0) with SMTP id jm03b8b2cb4; Mon, 27 Aug 2001 21:20:50 -0000
--------------------------------------------

What reports the IP of my sendmail server to the recipients server? Sendmail daemon? Does the recipients server resolve the IP form the network packets (Network Layer of OSI)? If we have to change something at the network layer to spoof the IP, I would like to give up.

Exactly. Whether or not you use the ISP's mail server is irrelevant. You are using their dial-up (or broadband) connection, and are therefore bound by their AUP.

Yes. At some point the sending machine has to contact a recipient machine to send the message. Whether or not you have inserted your own fake headers at this point is irrelevant. When you make a connection to the recipient the recipient appends the connecting IP to the headers. You can hack your outgoing packets to include a fake source address if you like, but in that case you will have to use SMTP blind -- i.e. sending without ever seeing the responses to your commands.

You need access to raw sockets, which generally means root privileges. Unfortunately its not that hard to do. See nmap for example.

It is not a just a matter of spoofing the sending IP. SMTP is based on TCP which is connection oriented. The exploit most commonly used is when one or more intermediate SMTP relays are used to relay the mail combined with dirty tricks in the SMTP protocol exchange.

I agree with PxT that there are not too many defensible scenarios to send anonymous email or mask the originating machine. The potential for abuse may far outweigh the benefit for good.