Let's suppose that someone (Mario) wants to send an email to someone else (let's call him Nicolas). Nicolas' mailbox is filled by a unique server, let's say
smtp.gouv.fr (that's a fictitious example). So, whatever Mario does, the email will have to go through that server, transmitted with the SMTP protocol (the one with the 'RCPT' command). Mario would like the
From line to be:
From: firstname.lastname@example.org. Note that there are actually two "from" addresses: the one in the
From: header (which the recipient sees with his usual mail-reading application), and the one which is given through the
MAIL FROM SMTP command (the latter will appear in the
Now, although the email has to go through Nicolas' SMTP server, it may make a few hops. The normal mail-sending situation is that the sender uses the SMTP server of his ISP, and that server will talk to the destination SMTP server. Mario's ISP server is
smtp.governo.it. Mario can decide to do his telnet (or equivalent, but it always SMTP at the end) either to
smtp.gouv.fr, or some other server, e.g.
smtp.bundestag.de (the SMTP server of Angela's ISP), or some other server (
There are various things which can prevent Mario from doing so:
Mario's ISP may prevent any outgoing connection from his machine to any SMTP server (i.e. any TCP connection which targets port 25) except if the target machine is
smtp.governo.it. Many ISP do that, mainly to prevent zombie machine from spamming widely without any control.
smtp.governo.it may reject the attempt because the advertised "from" address is not an address ending with "
@governo.it". The server may enforce such a filter on the "
From:" header, or on the
MAIL FROM command, or on both. Some (not all) ISP apply such rules.
If Mario contacts
smtp.buckingham.uk, that server may reject the attempt because the mail is neither destined to an address in
buckingham.uk, or sent with a "from" address in "
@buckingham.uk". Servers which forward arbitrary emails from and to the outside are called "open relays" and are generally frowned upon, namely because spammers just love them.
If Mario contacts
smtp.bundestag.de, that server may also reject the attempt, although the mail is indeed advertised as being sent by Angela, because
smtp.bundestag.de knows that Angela would use a connection coming from one of the IP addresses which are indeed part of the network managed by
smtp.bundestag.de was not doing that, it would also be deemed an "open relay" (although less open than the previous instance, but partly open nonetheless).
If Mario finds a SMTP server (not
smtp.bundestag.de) which accepts to forward the email, or if Mario connects directly to
smtp.gouv.fr, then the attempt may still get rejected if the
bundestag.de domain uses SPF. SPF is a way for a domain to advertise, through the DNS, some mail-sending policies. Here,
bundestag.de would publish with SPF the information that normal emails sent from
@bundestag.de people should originate from
smtp.bundestag.de and nowhere else.
smtp.gouv.fr, upon seeing Mario's connection (or the connection from the gullible SMTP server that Mario found), may then look at the SPF records for
bundestag.de, and detect the anomaly. Of course, SPF is not used everywhere, and since it is DNS based it is vulnerable to coordinated DNS attacks ("DNS poisoning" and things like that).
Some big mail providers enforce arbitrary obscure limitations, which may have the same effect than SPF, but in an undocumented and sometimes officially denied way.
So the best bet for Mario would be to either connect with telnet to
smtp.gouv.fr (assuming that his ISP lets him do that, and that
bundestag.de does not use SPF, or that
smtp.gouv.fr disregards SPF information); or he could try to find some hackable or otherwise complacent machine somewhere in the
bundestag.de, and use it as an open relay to send the mail through
smtp.bundestag.de (which would have the added bonus of making all the headers "realistic", as if Angela had done it herself).