Windows – How to setup your own smtp mail server in windows xp

One possible reason is that the sender might simply be unable to reach the recipient's mail server directly.

In the early days of email & SMTP, you had more than just Internet – you had Bitnet; UUCPnet/Usenet; Berknet; MILNET; DECnet; etc. all using incompatible protocols. A domain like sri-unix.uucp might not have had an IP address in DNS – only a MX record pointing to a gateway (a SMTP server that also had UUCP links).

These days, a similar situation is with communications between IPv4-only and IPv6-only hosts (even though the latter are somewhat rare).

Besides, the networks weren't exactly reliable (and still aren't) – you wouldn't want to stare at a "Recipient's mail server is unreachable, please wait" for half an hour, when you could just give the message to a sendmail running 24/7 on the same computer that you were composing the message on, and continue with work.

Bonus: some really weird "From:" addresses I've seen on OldUse.Net:

• UCBVAX.@MIT-MC.@rand-relay.ARPA.goldfarb.UCF-CS@RAND-RELAY

• farber%udel-eecis1.udeecis@udel-ee@sri-unix.UUCP

• notes@CSvax:Pucc-H:pur-phy.UUCP

• utzoo!linus!security!genrad!decvax!harpo!floyd!whuxlb!pyuxll!abnjh!u1100a!pyuxn!pyuxi!mhuxm!mhuxd!mhuxa!houxm!hocda!spanky!burl!akgua!emory!sb6!sb1!ll1!otuxa!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!mcewan

It is technically possible to send an email directly to the recipient's SMTP server from your computer.

Looking at it from a historical basis, if the remote SMTP server is down, you want a system to automatically handle it and keep retrying it— hence you have an SMTP server. Similarly, in the old days, not all mail servers were connected all the time—long distance links were expensive, so mail would be queued and sent when a link was established.

Moving on to where Internet is cheap, it's still useful to have mechanisms to retry sending email if a server is unavailable, and it's not ideal for this functionality to be written into the MUA (Mail user agent/end user mail program). These functions fit into an MTA (Mail server/SMTP server).

But it gets worse—spammers. Most emails (way more than 80%) are spam. So mail providers do whatever they can to reduce this problem—and a large number of techniques make assumptions about the way email is delivered—the following are important considerations:

1. Greylisting: Some providers will automatically drop a mail connection if the sender and recipient have not communicated before, and expect them to try a second time—because spammers often don't, while an SMTP server is always supposed to. This reduces spam volumes by about 80%. It sucks to have to do this though.

2. Reputation: It is a lot more likely that someone sending email through a reputable, known SMTP server is legit than a fly-by-night server. To get a feel for reputation, providers do a number of things:

   1. Block dynamic / client addresses (Not 100%, but large chunks of the Internet have been mapped out).

   2. Look that reverse DNS matches forward DNS: Not very hard to do, but shows some level of accountability and knowledge of best practices—and something a lot of client address blocks don't have.

   3. Reputation: When communicating with other SMTP servers, a lot of providers keep track of the amount of spam and volumes of email sent and can reduce the amount of spam by limiting connections and keeping an eye on these parameters. (There are lots of ways this is done, not all of them obvious, but which require a known sender).

   4. SPF and DKIM: These mechanisms tie DNS resources to the domain name to make forging mail harder, and would be difficult (but not necessarily impossible to deploy if the mail program (MUA) is responsible for outgoing mail. (Added to make this answer more complete as it's already been accepted. Credit for it should go to posters below as it slipped my mind, but is, nonetheless, very valid)

There are probably other minor concerns, but these would be the major ones.