Are github`s IP Addresses changed

As stated by many others, IP headers are trivial to forge, as long as one doesn't care about receiving a response. This is why it is mostly seen with UDP, as TCP requires a 3-way handshake. One notable exception is the SYN flood, which uses TCP and attempts to tie up resources on a receiving host; again, as the replies are discarded, the source address does not matter.

A particularly nasty side-effect of the ability of attackers to spoof source addresses is a backscatter attack. There is an excellent description here, but briefly, it is the inverse of a traditional DDoS attack:

1. Gain control of a botnet.
2. Configure all your nodes to use the same source IP address for malicious packets. This IP address will be your eventual victim.
3. Send packets from all of your controlled nodes to various addresses across the internet, targeting ports that generally are not open, or connecting to valid ports (TCP/80) claiming to be part of an already existing transaction.

In either of the cases mentioned in (3), many hosts will respond with an ICMP unreachable or a TCP reset, targeted at the source address of the malicious packet. The attacker now has potentially thousands of uncompromised machines on the network performing a DDoS attack on his/her chosen victim, all through the use of a spoofed source IP address.

In terms of mitigation, this risk is really one that only ISPs (and particularly ISPs providing customer access, rather than transit) can address. There are two main methods of doing this:

1. Ingress filtering - ensuring packets coming in to your network are sourced from address ranges that live on the far side of the incoming interface. Many router vendors implement features such as unicast reverse path forwarding, which use the router's routing and forwarding tables to verify that the next hop of the source address of an incoming packet is the incoming interface. This is best performed at the first layer 3 hop in the network (i.e. your default gateway.)

2. Egress filtering - ensuring that packets leaving your network only source from address ranges you own. This is the natural complement to ingress filtering, and is essentially part of being a 'good neighbor'; ensuring that even if your network is compromised by malicious traffic, that traffic is not forwarded to networks you peer with.

Both of these techniques are most effective and easily implemented when done so in 'edge' or 'access' networks, where clients interface with the provider. Implementing ingress/egress filtering above the access layer becomes more difficult, due to the complexities of multiple paths and asymmetric routing.

I have seen these techniques (particularly ingress filtering) used to great effect within an enterprise network. Perhaps someone with more service provider experience can give more insight into the challenges of deploying ingress/egress filtering on the internet at large. I imagine hardware/firmware support to be a big challenge, as well as being unable to force upstream providers in other countries to implement similar policies...

Your title says your email is being blocked by hotmail.com but in one of your comments to Stony's answer you state that your SMTP log shows "RCPT=OK" and "RECV=OK" when sending email to hotmail.com. That in and of itself should be telling you that your email is not being blocked. It's being accepted by hotmail.com and is most likely being filtered after being accepted. there's a difference between an email being blocked/rejected and being filtered after being accepted.

You state that you can't telnet to port 25 of mail.hotmail.com. That's because mail.hotmail.com is not an MX for hotmail.com. A quick nslookup shows the following MX records for hotmail.com: mx1.hotmail.com, mx2.hotmail.com, mx3.hotmail.com, and mx4.hotmail.com.

You state that you can't ping hotmail.com but you can ping gmail.com. It's irrelevant whether or not you can ping hotmail.com or any other server, name, web site, etc. The ping tool doesn't test the availability of a service (web, email, etc). The fact that you can't ping hotmail.com only means that the hosts that hotmail.com resolve to don't respond to pings or that a firewall is blocking those pings. It's totally irrelevant to the problem. In addition, pinging hotmail.com has nothing to do with the MX records for hotmail.com. Hotmail.com is the domain name and pinging hotmail.com is pinging the A records configured for that domain name. When you ping gmail.com you're pinging the A record for that domain name, you're not pinging the MX records for gmail.com.

Have a look at the Hotmail Postmaster page here to see if there's anything you need to look in to:

http://mail.live.com/mail/troubleshooting.aspx