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: [email protected]. 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 Return-Path: header).
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.governo.it, smtp.gouv.fr, or some other server, e.g. smtp.bundestag.de (the SMTP server of Angela's ISP), or some other server (smtp.buckingham.uk).
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 bundestag.de. If 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).
