Q:SPAM/Why do people say it's "difficult" to forge an IP address?

[ic]

I keep seing this on the net, people saying that it is difficult to forge an IP address? Of what- the sender's PC, or do they really mean the IP address of an smtp server that the spammer used?

I know that it is extremely simple to configure your own PC with a static ip- just pick an IP address in a public address range and you have just forged an IP address that does not belong to you.

I know that the email headers should allow for tracing back to the smtp server, and they should show the forged IP address, but would they definitely include the IP address allocated by ISP to spammer?

[Perdition]

It isn't easy to forge an IP address but not impossible. You can configure your machine with a "public" IP but this won't help you one bit as you are still assigned an IP addresses by your ISP ;)

In order to spoof an IP address you need to modify the source address of every packet sent to the SMTP server, basically bending the rules of TCP/IP. The server will send ACK packets to the spoofed address so you will not receive them however your machine can just keep sending packets as if it had received the ACK. This is tricky to get right and you need a good connection for this to work as if any packets need to be resent your machine will not be notified of them and the server will drop the connection.

The above only applies to the spammers actual machine. Unless they have control over the SMTP servers along the rest of the path they cannot spoof those addresses.

[ic]

I realise the acks would probably only be sent to the host that is the *real* owner of the spoofed IP address.

I still don't understand why a spammer can't just statically assign the IP address they intended to spoof- from what you are saying, mail clients like Outlook, OE etc will look for an ISP DHCP assigned IP to place in the mail headers, or is that done by the smtp server? :confused:

I'm just trying to get my head around this at the moment, and it is quite a few years since I went on a TCP/IP course...besides I never investigated smtp & pop3 at the raw data level.

[Perdition]

Headers are updated by the SMTP server. If you look at the headers in your mails you will see multiple "Received from" entries. Even if the spammer inserts fake header information the original information will still exist and allow one to trace back to the originating SMTP server.

[ic]

I remember trying to find info a while ago on w3.org / w3c.org about pop3 & smtp, and I may as well have been reading about DES3 bcos I got clobbered with acronyms & stuff, perhaps I will give it another try.

So the mail client (Outlook or whatever User Agent) doesn't generate any header info?, it just sends a block of data according to whatever the smtp protocol specifies?, presumably including the sender's email address, subject, date & time stamp, recipent(s), message data- potentially blocked together with attachments, as well as any UA specific info.

The smtp server generates the complete email header then? & adds its own Received from using the IP address it (thinks it) recieved all the packets from- specified in the packets as per IProtocol.

The smtp server connects to each of the mail servers specified in MX records for each recipient's domain, and sends the message as per standard TCP/IP, or is there a server-to-server protocol, maybe smtp again?

Then intermediary (if any) and destination mail servers add their own Received froms, until each copy of the message is delivered to each recipient's mailbox.

So, the method of spoofing an IP address that is most likely to succeed, is presumably to try and spoof an IP address in the same range allocated by the spammer's own ISP? That way it looks like it came from another user & they get cracked-down-on by the ISP (not telkom ofcourse)? Presumably the way to stop that, would be for the ISP to add some info that allows the authenticated user to be traced? Naturally it would be better to keep the message as small as possible to avoid problems with packet loss bcos the acks wouldn't be sent to the actual sender?

[privet]

[QUOTE=ic]I remember trying to find info a while ago on w3.org / w3c.org about pop3 & smtp, and I may as well have been reading about DES3 bcos I got clobbered with acronyms & stuff, perhaps I will give it another try.
[QUOTE]

You can find the specifications for POP3 and SMTP here:
http://www.faqs.org/rfcs/rfc821.html
http://www.faqs.org/rfcs/rfc1939.html

[Perdition]

So the mail client (Outlook or whatever User Agent) doesn't generate any header info?, it just sends a block of data according to whatever the smtp protocol specifies?, presumably including the sender's email address, subject, date & time stamp, recipent(s), message data- potentially blocked together with attachments, as well as any UA specific info.

Correct. At this point the sender could change the "From" address to anything they like (often done by spammers), however the SMTP server will still register the sender's IP address. This is why spammers employ malware to hijack people's machines as it becomes almost impossible to track the spammer (unless said user keeps firewall logs).


The smtp server generates the complete email header then? & adds its own Received from using the IP address it (thinks it) recieved all the packets from- specified in the packets as per IProtocol.

Correct


The smtp server connects to each of the mail servers specified in MX records for each recipient's domain, and sends the message as per standard TCP/IP, or is there a server-to-server protocol, maybe smtp again?


Correct. Technically it uses both protocols. SMTP is the Application layer protocol whereas TCP/IP is the Transport and Network layer protocol.



Then intermediary (if any) and destination mail servers add their own Received froms, until each copy of the message is delivered to each recipient's mailbox.

You got it.


So, the method of spoofing an IP address that is most likely to succeed, is presumably to try and spoof an IP address in the same range allocated by the spammer's own ISP? That way it looks like it came from another user & they get cracked-down-on by the ISP (not telkom ofcourse)? Presumably the way to stop that, would be for the ISP to add some info that allows the authenticated user to be traced? Naturally it would be better to keep the message as small as possible to avoid problems with packet loss bcos the acks wouldn't be sent to the actual sender?

Yep that's the idea, however technologies such as Yahoo's Domain Keys and Microsoft's (not likely to happen) Sender ID will eventually make e-mail spoofing a lot harder (in theory). The idea is to validate the authenticity of the sender's domain and if there is a problem it doesn't deliver the mail.

[ic]

Ok, thanks, in the meantime I searched w3.org using what google had indexed, found a link to http://cr.yp.to/smtp.html, but kinda glazed over. Gonna look at Privet's urls.

On M$ SenderID, I had a look at that a few weeks back, and it is IMO an overcomplicated version of Sender Policy Framework (http://spf.pobox.com/), basically M$ have fully incorporated SPF into SenderID, but just added some unecessary complexity.

I remember seeing somewhere that Yahoo announced initial support for SenderID, and then later rejected it, they decided to implement SPF on its own instead.

For anyone else reading this, SPF allows a mail server to check if an email was sent from a list of smtp servers that the domain admin specifies in the domain's DNS zone file, if the email was sent via an unlisted smtp server it can assume the sender's email address was spoofed and not deliver the email to the recipient. An SPF record is just a bit of text, and there are utils out there that will create it for you. The only glitch is that not enough domain registrars allow you to enter an SPF record into your domain's zone file. No-IP.com apparently does support SPF, but I haven't tried it yet.

The other hitch with SPF is that it requires the receiving mail server to support SPF, and do a DNS lookup to retrieve the SPF record (if there is one), allegedly there is minimal additional traffic involved in doing this- caching of DNS credentials or something...

[Mercury]

On M$ SenderID, I had a look at that a few weeks back, and it is IMO an overcomplicated version of Sender Policy Framework (http://spf.pobox.com/), basically M$ have fully incorporated SPF into SenderID, but just added some unecessary complexity.


Not to mention some patent issues that work to exclude open source distributors. See http://www.openspf.org/OpenSPF_community_position_v101.html

[ic]

Well I wasn't even aware of openspf.org, thanks for the url Mercury. Sadly M$ are trying their old tactic of asserting themselves onto the world.

Does anyone know if W3C have any involvement in fighting spam & SPF?

The only problem with W3C, IMO is that it takes ages to reach recommendation status (mainly due to the egos of M$ & others), but SPF as it stands is a very good first step, so even if W3C do jump on the bandwagon there should be an effective solution in place.

[Mean_Monster]

That is why it is so hard to stop a spammer on ADSL. Everyday his IP changes and you can only ask the ISP to trace the user. The IP is the only way to know where the junk came from in the first place.

[stoke]

We've designed a little util that sits in front of the POP server.
i.e. It listerns on port 110, and it behaves like the POP server would, the original POP server is reassigned a new port number.
It accepts the incoming mail header and evaluates the from address. If the from address is on an unknown domain, or not on the accepted list, it sends an email to the sender's "from emailaddress", asking the sender to simply reply to the email. While it waits for the reply, the conversation is held in a lock state, and the sender will timeout.
The usual spammers will never reply, thus are removed as a problem, and - they are basically being spammed straight back - he he he.
Anyways, it will only go into production next year, but I really want to make it free, and start the fight against spammers.
Those spammers that do reply have in effect identified themselves and can be dealt with effectively.

[ic]

Very interesting stoke.

It really is time to fight back- somehow force isp's to properly identify spammers using their network and cancel spammer contracts- obviously there has to be 100% certainty and what I've just said is somewhat simplistic.

What concerns me the most is spoofing of email addresses in the domains that I administer, it gives the companies a really bad image- because recipients don't realise that our email addresses have been spoofed. The only time we know our email addresses have being spoofed is when we get failed delivery reports. The only redeeming point is that it's unlikely that spam spoofing our email addresses is going to be sent to existing clients.

[stoke]

Yea - spoofed email addr's are a complete nightmare. We've added "[companyname]" to the end of the subject of every sent email (At the SMTP Server side) and have instructed our clients (in our policy wording at the bottom of the email) that if the subject does not contain that appendage then the email should be discarded. The clients of course don't take any notice of this, but any complaints from the clients are easily squashed, because the proof that it's not from us is quite visible, but you still have to do damage control.