I have started to write some code to send myself an email from my computer. During the testing phase I used my mail provider’s mail server address and sent myself an email from my own address without providing a username and password. I received it.
This leads me to think that anyone who knows my address could send an email that claims to be from me.
Is this bad?
Not necessarily. The SMTP server may be configured to only accept unauthenticated connections from your ISP’s network. Try running the same code from elsewhere (like a Starbucks wifi) and see if it still works.
It’s called spoofing, and it has ever been thus.
friedo come to think of it - I have in the past had issues using my mail accounts when I’ve been traveling. Problems that were solved by providing my account credentials. So it does seem like they allow unauthenticated usage from ips within their own network.
Still seems like others on the same network could spoof me but I won’t worry too much about that for now.
Yep, they sure can. It’s better to require everyone to use authenticated SMTP. But people are lazy and dumb. Still, only requiring auth from outside is not as bad as having a fully open relay.
They can also set things up so whenever you retrieve your own mail using a password, the server notes your IP address, and permits that IP address to send email for some time thereafter without any password.
That’s a separate issue. Anyone can send an email with your email address in the From line, without any access at all to any server you use. The From line, like the To line, is purely cosmetic, and doesn’t mean the email really came from there or is really going there. (That latter info is sent separately.)
Some spam filters may notice a discrepancy sometimes, usually by relying on some additional info on a domain (like an SPF record) that may or may not be available.
That’s correct – it’s BAD - anyone can send emails from any given email address and the email gets send and arrives. Depending on the receiving mail server the spoofed email arrives in your inbox or not.
It’s one of the method that spammers use and exploit.
Good old POP3.
Yep, when I was interning during college I wrote an app that did exactly this to test some stuff. It was surprising to me at the time that I could send mail to anyone with any from address I wanted. Of course, there was a rash of joking “You’re fired!” emails coming “from” the CEO to the other members of the QA department once I shared that app with my colleagues. Rolleyes all around.
Nothing to do with POP3 which is used to retrieve emails. The problem is with SMTP, used to send and transfer emails.
Back in the early days of the internet, connections were slow, point-to-point and often intermittent. So email servers (UUCP or SMTP) was designed to relay email via a bunch of intermediate servers. A client passed an email to the local server. That server used a table (or email address bangpath) to find the next-hop SMTP server on the route to the destination server, and passed it on. Each server in turn received the email, queued it, and passed it on till it got to it’s destination. With this design, SMTP servers had to relay indiscriminately, and there was an implied trust between SMTP servers. Email could also be slow, as it got queued and passed on at the servers discretion (sometimes days if a queue jammed up).
As the connectivity of the internet increased, SMTP servers increasingly were able to do away with intermediate servers, and emails would be transferred directly from source to destination. However, many of those servers continued to be configured to relay emails that were neither sourced from nor targeted to their home domain. These became known as open relays, and were increasingly being targeted by people with nefarious intent (email spammers and forgers). In 1994, I proved how open relay could be abused from outside our work network, and we convinced our email software provider to give us a configuration file that locked the server relay down to emails from our own domain. The software company (pretty big in the email world at the time) did not even understand why we would want to do so, but we did convince them.
Much later came SMTP client authentication (insecure on the wire) for internal clients and encrypted STMP with authentication which allows external relay for authenticated users, via secured connections. SMTP servers can also be configured to verify each other via a number of mechanisms.
Of course, not all SMTP servers in the world are correctly configured to be secure. But insecure open relays are no longer common, and most email spam is generated directly from malware infested PCs in a botnet targeted at the destination SMTP. This is reduced by many SMTP servers rejecting traffic from residential IP adddresses or the aforementioned verification mechanism.
So for the OP - the ISP SMTP server has an implicit trust of local IP addresses, and will accept and pass on any emails from that trusted network. It should take a correctly authenticated session and appropriate FROM address (i.e the isp local domain or one hosted by the isp) for it to accept and relay a message from outside the network. But you can still spoof some details, as SMTP isn’t always reliable in that sense.
According to some people (John Gilmore, a founder of the EFF), an open relay is correctly configured. (More information, which provides better context.)
Of course, he has a rant about it on his webpage. The immediate context is his ISP (Verio) dropping him for running an open relay in violation of his terms of service, but the rant is a lot more general than that. One section about blacklists is particularly juicy:
A blacklist is precisely what it sounds like: Someone or some group compiles a list of servers that are currently sending spam, which inevitably includes open relays because spammers find those things pretty quickly, and people automatically subscribe to those lists to know which emails are likely spam. It can be very difficult for someone to successfully send email from a blacklisted server.
More:
Right. This is… no longer a mainstream position, let’s say that. It’s also factually incorrect, as he seems to be saying that backbone routers carry traffic without accounting for who it’s from and what contracts the companies that own the backbone have signed. (Obviously smaller (retail) ISPs do more detailed accounting and filtering, as Gilmore himself found out when Verio dropped him.) I’m aware of settlement-free peering and that big ISPs don’t pay for Internet access, but the biggest tier 1 networks still keep track of volume and routing for technical and financial reasons. You can’t just inject packets into the big OC-192 or OC-768 links without letting the owners know who you are and what organization you’re with.
Indeed. Even more specifically, no leaf subnet router should forward packets that explicitly say that they don’t originate in that subnet (i.e. spoofed ip packets). It would have the effect of shutting down DDOS attacks that use spoofed packets. I can’t see any good reason to allow a packet out that lies about where the return should go. It isn’t just accounting, it is good networking practice.
Which brings us back to the OP: Routers don’t check to see if packets are cryptographically signed or otherwise accounted for in a secure fashion, but they do very often verify that the basic routing information makes sense given what physical interfaces they come from. Just like how the OP’s ISP’s mail server only relays unauthenticated mail from inside its network: It verifies the origin, even if it doesn’t bother to authenticate the specific user from that origin.
Gilmore seems to be saying that the current policy of backbone routers is equivalent to the policy of an open relay, but that kind of verified origin policy still kills open relays. An ‘open relay’ that only relays from specific networks isn’t open as Gilmore understands the term.
I’m impressed with Gilmore’s work, but everyone is capable of being wrong.