Asking for trouble...
-
A colleague of mine stumbled on this post on a forum earlier today:
http://forums.asp.net/p/1106645/1694691.aspx
About 4 posts down is a snippet of XML (something .net related... I don't do a lot of .net) Conveniently highlighted in aforementioned snippet is an email address. And next to it, lo and behold, a password.
So, 10 seconds later, out came my trusty old Telnet client, guessed (successfully) at the name of their POP3 server, and entered the username and password. Imagine the glee when the server responds with "+OK".... I was tempted to put the details into Outlook Express and start downloading, but I thought not...
Just as big a WTF is the fact that the post is from 2007, and boyo has not yet changed his publicly available credentials... Hope this guy isn't in charge of their corporate email system....
-
Hey! That's the same combination that I have for my (monogrammed) luggage!
-
I'm tempted to send him a friendly e-mail letting him know the situation... from his own e-mail account.
-
That's kinda what I thought too! But I thought I'd leave that particularly amusing task to someone else.... Don't wanna use my company's internet access for borderline hacking activity (is it hacking when people freely have given out their credentials????)
Maybe I'm just far too honest (he says a few days after using a neighbours' unsecure wireless connection.... hey! I've got an idea about that ;-)
-
@MeesterTurner said:
That's kinda what I thought too! But I thought I'd leave that particularly amusing task to someone else.... Don't wanna use my company's internet access for borderline hacking activity (is it hacking when people freely have given out their credentials????)
a) darknet, b) which one of us is going to email him... we can't all do it, but it's only... right ... to tell him, don't you think? (my opinion? free email account for a few days - what if he's a sysadmin on some network somewhere? RDP anyone? - those aren't usually logged)
-
And I wanted to play "the good guy"...
From: MAILER-DAEMON@sh-h01.dnrnet.it
Subject: Undelivered Mail Returned to Sender
Date: June 3, 2009 9:17:53 AM EEST
To: [me]This is the mail system at host sh-h01.dnrnet.it.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<technical@webmyne.com>: host mail01.secureserverdot.com[216.14.208.15] said:
550 sorry, no mailbox here by that name (#5.1.1) (in reply to RCPT TO
command)
Reporting-MTA: dns; sh-h01.dnrnet.it
X-Postfix-Queue-ID: 2C90D187837D
X-Postfix-Sender: rfc822; [me]
Arrival-Date: Wed, 3 Jun 2009 08:17:52 +0200 (CEST)
Final-Recipient: rfc822; technical@webmyne.com
Original-Recipient: rfc822;technical@webmyne.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail01.secureserverdot.com
Diagnostic-Code: smtp; 550 sorry, no mailbox here by that name (#5.1.1)
-
@Heron said:
I'm tempted to send him a friendly e-mail letting him know the situation... from his own e-mail account.
POP3 is not used for sending email. Besides, sending does not require any credentials anyway.
-
Finally, someone who sent teh codez.
-
@MeesterTurner said:
(is it hacking when people freely have given out their credentials????)
Is it trespass when the homeowner left their keys in the door?
-
more like... is it trespass when the homeowner has left their keys in the center of town with their address engraved on them?
-
@SlyEcho said:
@Heron said:
I'm tempted to send him a friendly e-mail letting him know the situation... from his own e-mail account.
POP3 is not used for sending email. Besides, sending does not require any credentials anyway.
Only if the mail server is misconfigured. If SMTP Auth is being used, the password will probably be pulled from a central store, such as LDAP, meaning it will be the same as the POP3 password. Another possibility is POP-before-SMTP. Either way, sending should require credentials.
-
@morbiuswilters said:
Either way, sending should require credentials.
win+r
cmd
nslookup -type=MX webmyne.com
telnet mail01.secureserverdot.com 25
[wait for banner from server]
HELO moocow.com
MAIL FROM: moo@moocow.com
RCPT TO: chirag@webmyne.com
DATA
[Somethinghere....]
.
QUIT
exit
Now, where did I need password again? Sure, mail server might not (but usually does) accept messages directed to it from address it handles without authentication and possibly deeper sender verify.
-
@Buzer said:
@morbiuswilters said:
Either way, sending should require credentials.
win+r
cmd
nslookup -type=MX webmyne.com
telnet mail01.secureserverdot.com 25
[wait for banner from server]
HELO moocow.com
MAIL FROM: moo@moocow.com
RCPT TO: chirag@webmyne.com
DATA
[Somethinghere....]
.
QUIT
exit
Now, where did I need password again? Sure, mail server might not (but usually does) accept messages directed to it from address it handles without authentication and possibly deeper sender verify.Did you miss the "misconfigured" part? An MTA that accepts without some authentication is known as an "open relay" and is a major source of spam. Non-authenticated SMTP is very stupid. Your example is not even on-topic. We're talking about sending to a particular mailbox from the same mail address. You aren't even doing that. Please educate yourself before you make false, ignorant statements.
-
@morbiuswilters said:
Did you miss the "misconfigured" part? An MTA that accepts without some authentication is known as an "open relay" and is a major source of spam. Non-authenticated SMTP is very stupid. Your example is not even on-topic. We're talking about sending to a particular mailbox from the same mail address. You aren't even doing that. Please educate yourself before you make false, ignorant statements.
An MTA that accepts mail it handles without authentication is not an open relay (heck, that's what it supposed to be doing). While it's normal that you pass the email thru your MSA server instead of sending it directly to the final public MTA, it's not required. Why do you think I did nslookup to check the mail exchanger? Sure, there is a lot of reasons why this might fail (usually due to spam filters, but it's also possible it might require authentication if the sender domain is set to some that it handles (which was not the case with my example, but it's easily adjustable for that case)), but most of time, it does work.
-
@Buzer said:
@morbiuswilters said:
Did you miss the "misconfigured" part? An MTA that accepts without some authentication is known as an "open relay" and is a major source of spam. Non-authenticated SMTP is very stupid. Your example is not even on-topic. We're talking about sending to a particular mailbox from the same mail address. You aren't even doing that. Please educate yourself before you make false, ignorant statements.
An MTA that accepts mail it handles without authentication is not an open relay (heck, that's what it supposed to be doing). While it's normal that you pass the email thru your MSA server instead of sending it directly to the final public MTA, it's not required. Why do you think I did nslookup to check the mail exchanger? Sure, there is a lot of reasons why this might fail (usually due to spam filters, but it's also possible it might require authentication if the sender domain is set to some that it handles (which was not the case with my example, but it's easily adjustable for that case)), but most of time, it does work.An MTA that accepts mail for a domain it is hosting without authentication is an open relay. That's what we are talking about here. Please try to pay attention.
-
Morbius, unless you have mistyped what your saying, you are very very wrong and very very rude. If SMTP needed authentication then we wouldn't have a spam problem.
Are you trolling or just confused?
An SMTP server will accept email for its domain, say example.com. If you look up the MX record for the example.com domain, you get the IP address of the SMTP server. You connect to that server, which will normally accept either all mail, or only valid addresses, in the example.com domain.
If you connect to it to send to example.net, you should get rejected with a relay denied message.
If this were not the case, when I want to send a message to example.org, what password should I use? You have an email address, one assumes. How do people send mail to it without a password?
How do the 'open relays' you refer to manage to send spam to the MTA that accepts mail for the domain your address is in?
An MTA that accepts mail for a domain it is NOT hosting without authentication is an open relay.
As an aside, I'd also be interested in your evidence for the claim that open relays (ie not hacked windows boxes or spammer-hosted machines) are a major source of spam in 2009.
-
@morbiuswilters said:
An MTA that accepts mail for a domain it is hosting without authentication is an open relay. That's what we are talking about here. Please try to pay attention.
Ehh, so you could only send a mail to a domain if you know the password? unlikely...
I think the situation is like this. Lets say we have a particular mailserver that is the mailserver of somecompany.com, if I recall correctly the situation should be:
Mail from: a@example.org to: b@somecompany.com -> Accept the e-mail (do not relay). Anything else than this would be a huge WTF.
Mail from: spammer@spam.com to: a@example.org -> Refuse the email (do not relay). Doing anything else would make the server an open relay. Allowed after authentication
Mail from: a@somecompany.com to: b@example.org -> Accept and relay the email. Authentication might be wanted and/or the server might be configured to check if the mail sender's IP it from within somecompany.com
-
Looks like somebody already has...
who needs telnet web plenty of webmail sites exsist.
-
@fusspawn said:
... who needs telnet web plenty of webmail sites exsist.
Webmail sites won't let you give a false from address. The receiving MTA will, since they have no way to verify it (Other than SPF, which reduces the pool of domains you can choose from for your fake address)
-
@freakwent said:
Morbius, unless you have mistyped what your saying, you are very very wrong and very very rude.
I'm rude to idiots who don't know what they are talking about but still insist on opening their mouths.
@freakwent said:
If SMTP needed authentication then we wouldn't have a spam problem.
So very wrong. Reducing forgeries would eliminate some spam, but not all. Not even close.
@freakwent said:
Are you trolling or just confused?
An SMTP server will accept email for its domain, say example.com. If you look up the MX record for the example.com domain, you get the IP address of the SMTP server. You connect to that server, which will normally accept either all mail, or only valid addresses, in the example.com domain.
If you connect to it to send to example.net, you should get rejected with a relay denied message.
If this were not the case, when I want to send a message to example.org, what password should I use? You have an email address, one assumes. How do people send mail to it without a password?
How do the 'open relays' you refer to manage to send spam to the MTA that accepts mail for the domain your address is in?
Read the fucking thread. Somebody suggested sending the guy an email from his own account. Following that was somebody saying that SMTP does not require authentication. No, the protocol does not require it but if you are sending mail from a domain the server is receiving for you will have to authenticate with the server unless it is misconfigured. Clearly the server will accept mail addressed to domains it receives for. What we are talking about here is trying to send from an address to the same address.
There's no guarantee that the guy's POP3 credentials will permit sending mail through his mail server with his domain as the sender, but it's certainly possible. It's also possible that you can connect to his mail server and send mail from his account without authentication, but that would be an instance of the mail server being misconfigured.
@freakwent said:
As an aside, I'd also be interested in your evidence for the claim that open relays (ie not hacked windows boxes or spammer-hosted machines) are a major source of spam in 2009.
Did I say botnets weren't also major sources of spam? No, I did not. Open relays still account for a good portion of spam, unfortunately. If you can't keep up with the conversation, please don't spew nonsense just for the hell of it.
-
@morbiuswilters said:
I'm rude to idiots who don't know what they are talking about but still insist on opening their mouths.
You must be horribly rude to yourself, then.
A mail server which accepts email from outside its domain which claims to be from itself is misconfigured. It is an open mail server. It is not necessarily an open relay, because it is not relaying the mail, simply storing it in the appropriate mail boxes.
Please learn the distinctions between the words you use before you try being abusive to others who actually know the words better.
-
@tgape said:
@morbiuswilters said:
I'm rude to idiots who don't know what they are talking about but still insist on opening their mouths.
You must be horribly rude to yourself, then.
A mail server which accepts email from outside its domain which claims to be from itself is misconfigured. It is an open mail server. It is not necessarily an open relay, because it is not relaying the mail, simply storing it in the appropriate mail boxes.
Please learn the distinctions between the words you use before you try being abusive to others who actually know the words better.
The server would be an open relay (assuming that it actually sends mail anywhere remote), but that doesn't mean it would be used as such in the preceding scenario. If a mail server is meant to accept mail from users for relaying to local or remote addresses and it does not authenticate, it is an open relay. If the mail server in the above scenario were misconfigured and not authenticating users, it would be an open relay unless it was also incapable of relaying mail at all, which would make it really misconfigured. So the only possible way the misconfigured mail server wouldn't be an open relay was if it didn't relay at all. Your distinction is pointless and you are an idiot.
Do you even know how mail works? I suggest getting yourself a few "For Dummies" books and trying to learn.
-
@morbiuswilters said:
But it doesn't. He explicitly said that he is talking about mail from outside the domain for within the domain.@tgape said:
@morbiuswilters said:
I'm rude to idiots who don't know what they are talking about but still insist on opening their mouths.
You must be horribly rude to yourself, then.
A mail server which accepts email from outside its domain which claims to be from itself is misconfigured. It is an open mail server. It is not necessarily an open relay, because it is not relaying the mail, simply storing it in the appropriate mail boxes.
Please learn the distinctions between the words you use before you try being abusive to others who actually know the words better.
The server would be an open relay (assuming that it actually sends mail anywhere remote),
@morbiuswilters said:
No, he is not an idiot. He is aware of the distinction that you are unaware of between the different terms "relaying" and "delivering locally". Your talk of "relaying to local or remote addresses" is nonsense. You do not "relay" to a local address. You "deliver" to it. I'm sure this distinction is made clear in that "for dummies" book you were referring to. It's certainly unambiguously defined in the rfc:but that doesn't mean it would be used as such in the preceding scenario. If a mail server is meant to accept mail from users for relaying to local or remote addresses and it does not authenticate, it is an open relay. If the mail server in the above scenario were misconfigured and not authenticating users, it would be an open relay unless it was also incapable of relaying mail at all, which would make it really misconfigured. So the only possible way the misconfigured mail server wouldn't be an open relay was if it didn't relay at all. Your distinction is pointless and you are an idiot.
[quote user="http://www.faqs.org/rfcs/rfc2821.html"]
2.3.8 Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store
which a mail user agent is expected to subsequently access. A
"relay" SMTP system (usually referred to just as a "relay") receives
mail from an SMTP client and transmits it, without modification to
the message data other than adding trace information, to another SMTP
server for further relaying or for delivery.[/quote]
-
@DaveK said:
@morbiuswilters said:
But it doesn't. He explicitly said that he is talking about mail from outside the domain for within the domain.@tgape said:
@morbiuswilters said:
I'm rude to idiots who don't know what they are talking about but still insist on opening their mouths.
You must be horribly rude to yourself, then.
A mail server which accepts email from outside its domain which claims to be from itself is misconfigured. It is an open mail server. It is not necessarily an open relay, because it is not relaying the mail, simply storing it in the appropriate mail boxes.
Please learn the distinctions between the words you use before you try being abusive to others who actually know the words better.
The server would be an open relay (assuming that it actually sends mail anywhere remote),
@morbiuswilters said:
No, he is not an idiot. He is aware of the distinction that you are unaware of between the different terms "relaying" and "delivering locally". Your talk of "relaying to local or remote addresses" is nonsense. You do not "relay" to a local address. You "deliver" to it. I'm sure this distinction is made clear in that "for dummies" book you were referring to. It's certainly unambiguously defined in the rfc:but that doesn't mean it would be used as such in the preceding scenario. If a mail server is meant to accept mail from users for relaying to local or remote addresses and it does not authenticate, it is an open relay. If the mail server in the above scenario were misconfigured and not authenticating users, it would be an open relay unless it was also incapable of relaying mail at all, which would make it really misconfigured. So the only possible way the misconfigured mail server wouldn't be an open relay was if it didn't relay at all. Your distinction is pointless and you are an idiot.
[quote user="http://www.faqs.org/rfcs/rfc2821.html"]
2.3.8 Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store
which a mail user agent is expected to subsequently access. A
"relay" SMTP system (usually referred to just as a "relay") receives
mail from an SMTP client and transmits it, without modification to
the message data other than adding trace information, to another SMTP
server for further relaying or for delivery.[/quote]
*sigh* You people are so fucking stupid. The server that handles delivering mail for a domain does not have to be the same server that receives for that domain. So a server can "relay to the local domain" if the mailbox is not on the same server. There is nothing incorrect in what I stated, you shit-for-brains.
-
@morbiuswilters said:
*sigh* You people are so fucking stupid. [bla bla bla] you shit-for-brains.
Can't we all just get along? Or at least try not to direct personal insults at each other? If this place keeps it up like this, I'm outta here soon...
-
@rohypnol said:
@morbiuswilters said:
*sigh* You people are so fucking stupid. [bla bla bla] you shit-for-brains.
Can't we all just get along? Or at least try not to direct personal insults at each other? If this place keeps it up like this, I'm outta here soon...
Where's the fun in that? What point is there in being a genius if you can't make other people feel worthless when they know less than you?
-
@morbiuswilters said:
@rohypnol said:
@morbiuswilters said:
*sigh* You people are so fucking stupid. [bla bla bla] you shit-for-brains.
Can't we all just get along? Or at least try not to direct personal insults at each other? If this place keeps it up like this, I'm outta here soon...
Where's the fun in that? What point is there in being a genius if you can't make other people feel worthless when they know less than you?
So lemme get in this discussion along with you guys: a SMTP server listens for connections. Anyone can CONNECT without a username/password and post an email to one of the users of that SMTP server (few SMTP servers require authentication, because otherwise they'd need authentication from yahoo.com, gmail.com, hotmail.com, etc.com). It's up to the server to decide whether to accept or reject the email (usually it's rejected because the recipient isn't recognized or it's temporarily rejected by Greylisting). The server decides if the source was legitimate. I can send an email to support@microsoft.com from morbiuswilters@tdwtf.com.inexisting.domain and the server wil decide if it wants to accept or reject the message. Usually it accepts it and marks it as spam if it's obvious spam. You don't need to be a genius to understand that.
-
@morbiuswilters said:
if you are sending mail from a domain the server is receiving for you will have to authenticate with the server unless it is misconfigured
Most of time you don't. Whatever this is is "misconfiguration" or not depends on several factors, but generally that is wanted behavior. I'm not sure about other countries, but at least in Finland, every consumer ISP (and very few make exceptions) filters port 25 in both directions except to their own mail server (this is an order from our Communications Regulatory Authority). Sure, some mail servers provide other ports as well (like MSA's 587 or secure SMTP's 465), but many (most?) of users are unaware of any other port than 25.
-
@Buzer said:
@morbiuswilters said:
if you are sending mail from a domain the server is receiving for you will have to authenticate with the server unless it is misconfigured
Most of time you don't. Whatever this is is "misconfiguration" or not depends on several factors, but generally that is wanted behavior. I'm not sure about other countries, but at least in Finland, every consumer ISP (and very few make exceptions) filters port 25 in both directions except to their own mail server (this is an order from our Communications Regulatory Authority). Sure, some mail servers provide other ports as well (like MSA's 587 or secure SMTP's 465), but many (most?) of users are unaware of any other port than 25.
I'm not even sure what the ports have to do with anything, but on to your first point. Such a scenario would most likely be using IP-based rules. That's a rather antiquated way to keep unwanted users from access your relay because 1) users on the network can still forge emails from other users on the same domain; 2) it does little to protect against an ISP user who is spamming and 3) it provides no way for traveling users to relay through the mail server. SMTP authentication fixes all of these problems which is why it is used (in some form) for pretty much any modern email system.
Clearly there is a lot of ignorance here, so let me try to explain this from the top in very simple terminology. If you want to send an email from domain1.com to domain1.com you need to send through that domain's "outgoing SMTP server". That server will require some form of authentication unless it is misconfigured. If the email is addressed to a local domain, the outgoing SMTP server will pass off the message to the local delivery agent (which may or may not be on the same physical server) for delivery to the mailbox. If the email is addressed to a non-local domain the SMTP server will attempt to deliver to that domain's "incoming SMTP server". Due to the way mail systems are architected, if the outgoing SMTP server does any authentication at all, it will almost always apply regardless if the domain is local or remote. So if an outgoing SMTP server lets you send email through it to a local domain without authentication it will do the same for remote domains, making it an open relay.
This is precisely what I said above, I just left some of it up to the inference of the reader on the assumption that the reader could figure it out. To recap: I never said nor implied that incoming SMTP servers require authentication for delivery from remote domains to local domains. It's done sometimes, but only for specific reasons and it is not the norm. So, no, you don't need to authentication to send from domain2.com to domain1.com via domain1.com's incoming SMTP server. I figured this was fairly basic and didn't need to be explained, but clearly several individuals misunderstood and thought I might be implying that. However, you will need authentication if you want to send from domain1.com to any other domain (local or remote) via domain1.com's outgoing SMTP server, unless the outgoing SMTP server is misconfigured. It really does not matter if the destination is local or remote as authentication almost always applies in either scenario. Yes, it is possible that domain1.com's outgoing SMTP server will require authentication when sending to remote domains but not when sending to local domains, but that is not the norm and would be the result of a specific need; it would require explicit efforts to permit such a setup. God knows why you'd even want to, but that's irrelevant. The point is, if an outgoing SMTP server permits unauthenticated sending from a local domain to a local domain it will almost always permit unauthenticated sending from the same local domain to a remote domain, making it an open relay. Hence the statements I made that certain individuals wanted to take issue with even though they clearly did not understand what they were talking about.
Does this clear things up? To take a step back from my own arrogance and be forthright: I know quite a bit about mail. I've architected, built and maintained complex mail systems supporting millions of users. I do know what I'm talking about.
-
@morbiuswilters said:
This is precisely what I said above, I just left some of it up to the inference of the reader on the assumption that the reader could figure it out. To recap: I never said nor implied that incoming SMTP servers require authentication for delivery from remote domains to local domains. It's done sometimes, but only for specific reasons and it is not the norm. So, no, you don't need to authentication to send from domain2.com to domain1.com via domain1.com's incoming SMTP server. I figured this was fairly basic and didn't need to be explained, but clearly several individuals misunderstood and thought I might be implying that. However, you will need authentication if you want to send from domain1.com to any other domain (local or remote) via domain1.com's outgoing SMTP server, unless the outgoing SMTP server is misconfigured. It really does not matter if the destination is local or remote as authentication almost always applies in either scenario. Yes, it is possible that domain1.com's outgoing SMTP server will require authentication when sending to remote domains but not when sending to local domains, but that is not the norm and would be the result of a specific need; it would require explicit efforts to permit such a setup. God knows why you'd even want to, but that's irrelevant. The point is, if an outgoing SMTP server permits unauthenticated sending from a local domain to a local domain it will almost always permit unauthenticated sending from the same local domain to a remote domain, making it an open relay. Hence the statements I made that certain individuals wanted to take issue with even though they clearly did not understand what they were talking about.
You have, however, missed the case when we send from domain1.com to domain1.com via domain1.com's incoming server. Common sense suggests me that this will [b]not[/b] require authentication, and I'm sure that's what [b]SlyEcho[/b] meant by "sending does not require any credentials".
I can't test it with webmyne.com, though, because of DNS blacklists. And it appears they're protected with SPF, anyway.
-
@Spectre said:
@morbiuswilters said:
This is precisely what I said above, I just left some of it up to the inference of the reader on the assumption that the reader could figure it out. To recap: I never said nor implied that incoming SMTP servers require authentication for delivery from remote domains to local domains. It's done sometimes, but only for specific reasons and it is not the norm. So, no, you don't need to authentication to send from domain2.com to domain1.com via domain1.com's incoming SMTP server. I figured this was fairly basic and didn't need to be explained, but clearly several individuals misunderstood and thought I might be implying that. However, you will need authentication if you want to send from domain1.com to any other domain (local or remote) via domain1.com's outgoing SMTP server, unless the outgoing SMTP server is misconfigured. It really does not matter if the destination is local or remote as authentication almost always applies in either scenario. Yes, it is possible that domain1.com's outgoing SMTP server will require authentication when sending to remote domains but not when sending to local domains, but that is not the norm and would be the result of a specific need; it would require explicit efforts to permit such a setup. God knows why you'd even want to, but that's irrelevant. The point is, if an outgoing SMTP server permits unauthenticated sending from a local domain to a local domain it will almost always permit unauthenticated sending from the same local domain to a remote domain, making it an open relay. Hence the statements I made that certain individuals wanted to take issue with even though they clearly did not understand what they were talking about.
You have, however, missed the case when we send from domain1.com to domain1.com via domain1.com's incoming server. Common sense suggests me that this will not require authentication, and I'm sure that's what SlyEcho meant by "sending does not require any credentials".
I can't test it with webmyne.com, though, because of DNS blacklists. And it appears they're protected with SPF, anyway.
domain1.com's incoming SMTP server should not permit external servers to send mail from domain1.com unless it is badly misconfigured. No mail from domain1.com should ever come in through the incoming SMTP server; it should only be sent from the user through the outgoing SMTP server. Anything is possible, of course, but it is not likely the incoming SMTP server would be misconfigured to permit this without the outgoing SMTP server being an open relay as well. It is far, far more probable that the misconfiguration would be on the outgoing SMTP server which would make it an open relay.
-
@morbiuswilters said:
sigh You people are so fucking stupid. The server that handles delivering mail for a domain does not have to be the same server that receives for that domain. So a server can "relay to the local domain" if the mailbox is not on the same server. There is nothing incorrect in what I stated, you shit-for-brains.
Sigh. I admit, you got me.
Normally, in the case of a machine which receives email for another, we have one of two situations:
- The machine for which it receives email is not otherwise connected to the Internet. From the perspective of all of us on the Internet, it's all one big fscking box - which may have hundreds of IPs spread across the entire IP A-C spectrum. As such, most of us don't consider it an open relay, even though it technically relays.
- The machine is a failover MX host, and we all know it's horribly misconfigured. But, assuming that the box for which it receives email is not misconfigured, it still won't relay to said box, as said box won't accept the email, due to ingress filtering.
- The machine for which it receives email is not supposed to be otherwise connected to the Internet, but somebody messed up. Possibly even in the design phase.
And so, as soon as I learn to count, I'll hopefully figure out what forum I'm looking at. Sigh.
-
I think morbiuswilters is a bot. it just caught the subject 'Asking for trouble...' and got into 'insulting mode on'
could someone restart the script...?
-
@morbiuswilters said:
Does this clear things up? To take a step back from my own arrogance and be forthright: I know quite a bit about mail. I've architected, built and maintained complex mail systems supporting millions of users. I do know what I'm talking about.
Now this explains it. You are thinking large corporate email systems. Yes, the things you have explained do make sense in those enviroments (I also work with one and there is similar rules there). But do you realize those account for very small percent of the email systems out there? And there is quite fundemental differences between them and small systems? In small systems (be it small company or some small hobby website or just personal email), users don't always have luxary of using MSA that can validate that user has permission to send as the one they are claiming to be.
...which brings me to this:
@morbiuswilters said:I'm not even sure what the ports have to do with anything, but on to your first point. Such a scenario would most likely be using IP-based rules. That's a rather antiquated way to keep unwanted users from access your relay because 1) users on the network can still forge emails from other users on the same domain; 2) it does little to protect against an ISP user who is spamming and 3) it provides no way for traveling users to relay through the mail server. SMTP authentication fixes all of these problems which is why it is used (in some form) for pretty much any modern email system.
Ports have to do with it since disallowing access to port 25 does two things: 1) Disallows users from sending directoly to the MTA (zombies tend to this) 2) Disallows users from using many email services (as they tend to use port 25. Fortunally many tend to have port 587 open these days). Since this does the latter, users could no longer send email from their previous email accounts if ISP didn't allow them to forge the from header.
Naturally there is many cons with this decision and pretty much just one gain. Some people decided that gain outweights the cons and issued the order. Personally, I don't fully agree with it.
-
@Buzer said:
Now this explains it. You are thinking large corporate email systems. Yes, the things you have explained do make sense in those enviroments (I also work with one and there is similar rules there). But do you realize those account for very small percent of the email systems out there? And there is quite fundemental differences between them and small systems? In small systems (be it small company or some small hobby website or just personal email), users don't always have luxary of using MSA that can validate that user has permission to send as the one they are claiming to be.
Small systems work on the same principles as large systems. It's true that a small office or personal mail server may not require passwords but such a server would be limited to internal IP access only. If it wasn't, it would be an open relay. Limiting possible senders to a handful of internal computers through the use of IP restrictions establishes a form of authentication. There really is no reason not to require passwords for even a small system, but it happens. Of course, this doesn't apply here since the original suggestion was sending through the mail server from an external IP address. Face it, you are still wrong.
@Buzer said:
Ports have to do with it since disallowing access to port 25 does two things: 1) Disallows users from sending directoly to the MTA (zombies tend to this) 2) Disallows users from using many email services (as they tend to use port 25. Fortunally many tend to have port 587 open these days). Since this does the latter, users could no longer send email from their previous email accounts if ISP didn't allow them to forge the from header.
The from header doesn't really matter, it's the envelope sender that is important. It seems you are talking about ISPs blocking access to all external SMTP servers which requires users to send all mail through the ISP's outgoing SMTP server, including messages with from addresses on a domain the ISP's mail server does not handle. However, the incoming SMTP server for the external mail service still should not permit unauthorized servers to send using its own domain. I understand that it is possible, but since there are better alternatives and it is a very bad workaround that can result in a lot of problems (which you yourself admit in the next sentence), I wouldn't say it is common or something that can be relied on. This is also not what you originally said: you contradicted my statement by showing that it is possible to send mail from an external domain directly to an incoming SMTP server without authentication.
The fact is, you badly misunderstood what I was saying and proceeded to correct me with a very condescending example that had nothing to do with the conversation. I stand by my original statements: if an outgoing SMTP server does not require authentication (SMTP Auth, IP-based, POP-before-SMTP, etc..) it is misconfigured and is an open relay. An incoming SMTP server that permits external clients to send mail from a local domain is just laziness as there are better alternatives and I would consider it misconfigured as well.
-
@morbiuswilters said:
An incoming SMTP server that permits external clients to send mail from a local domain is just laziness as there are better alternatives and I would consider it misconfigured as well.
Since I haven't yet encountered a SMTP server that would outright deny external incoming messages with server's domain as sender, I tested against a few servers, and found that all messages have been delivered without problems.$ telnet gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP j10si1126431muh.15
helo example.net
502 5.5.1 Unrecognized command. j10si1126431muh.15
HELO example.net
250 mx.google.com at your service
MAIL FROM:<foo@gmail.com>
250 2.1.0 OK j10si1126431muh.15
RCPT TO:<bar@gmail.com>
250 2.1.5 OK j10si1126431muh.15
DATA
354 Go ahead j10si1126431muh.15
Subject: Test
From: foo@gmail.comTest 1,2,3
.
250 2.0.0 OK 1244227462 j10si1126431muh.15
QUIT
221 2.0.0 closing connection j10si1126431muh.15
-
@morbiuswilters said:
The fact is, you badly misunderstood what I was saying and proceeded to correct me with a very condescending example that had nothing to do with the conversation. I stand by my original statements: if an outgoing SMTP server does not require authentication (SMTP Auth, IP-based, POP-before-SMTP, etc..) it is misconfigured and is an open relay. An incoming SMTP server that permits external clients to send mail from a local domain is just laziness as there are better alternatives and I would consider it misconfigured as well.
So you consider, for example, the four largest (I guess?) webmail providers (AOL, Yahoo, GMail & Windows Live) as misconfigured? In my small test, all of those accept such messages (and I even used the reciever as sender). Yahoo was the only one who marked it as spam.
Let's give a little real-life case from some small business since you think same principals work as in corporate enviroments... Let's say you had some webmail and shared hosting (from different providers. Like GoogleApps for email, Bluehost for website). Quite a bit of the websites these days are made with PHP. Let's say you wanted to send registration email. You enter your mail address as the "From:" contact. And let's say you used mail() (like most of users) instead of PEAR::Mail or similar, you cannot really adjust the details. Result: GMail & Google App users can no longer recieve the registration message. Some shared hosting providers might also block outgoing SMTP traffic to non-intrenal mail servers.
-
The answer is simple: the "From" field does not indicate where the email comes from, but who composed it. You don't have to be a genius to realize that.
-
@ender said:
@morbiuswilters said:
An incoming SMTP server that permits external clients to send mail from a local domain is just laziness as there are better alternatives and I would consider it misconfigured as well.
Since I haven't yet encountered a SMTP server that would outright deny external incoming messages with server's domain as sender, I tested against a few servers, and found that all messages have been delivered without problems.Gmail, Hotmail and the other free webmail providers are clearly special cases due to their very nature. They are lax when it comes to permitting external clients to send using their domains to maximize usability with applications or services that their users might need. The downside to this is it increases the amount of spam they have to deal with, although Gmail manages pretty well; I get spam in my inbox all the time on Hotmail and Yahoo from external sources using the webmail domains. These services are a whole other can of worms, though, and basing your knowledge off what they do isn't wise.
-
@Buzer said:
So you consider, for example, the four largest (I guess?) webmail providers (AOL, Yahoo, GMail & Windows Live) as misconfigured?
They are special cases, as I said above.
@Buzer said:
And let's say you used mail() (like most of users) instead of PEAR::Mail or similar, you cannot really adjust the details.
What are you talking about? What details does the PHP mail() function not allow you to adjust?
@Buzer said:
Result: GMail & Google App users can no longer recieve the registration message.
Which is why Gmail does allow external clients to send using their domain. It's by no means optimal, but if they don't do it they limit usability. However, for any normal, private mail system this should not be allowed. If you think emulating a free, public mail service is a good idea, you are mistaken. Shared hosting also represents the bottom of the barrel in terms of good system design, so I wouldn't try to extrapolate lessons from it either.
Analogy Time: Private office buildings and homes almost always require some form of authentication to enter them. Public parks, on the other hand, do not. However, the existence of public parks does not mean that every private building should or does permit unauthorized entry, unless they want homeless crack addicts coming in and pooping all over the rug.
-
@morbiuswilters said:
@Buzer said:
And let's say you used mail() (like most of users) instead of PEAR::Mail or similar, you cannot really adjust the details.
What are you talking about? What details does the PHP mail() function not allow you to adjust?
SMTP auth details. If you use sendmail and different server handles email, that email server would block messages coming from that server.
@morbiuswilters said:@Buzer said:
Result: GMail & Google App users can no longer recieve the registration message.
Which is why Gmail does allow external clients to send using their domain. It's by no means optimal, but if they don't do it they limit usability. However, for any normal, private mail system this should not be allowed.
Most of the sites are on shared hosting, especially small business or small hobby website (where people normally wouldn't pay $50/month for hosting (decent managed VPSs are around that price range)). And those were the type of users for who I said that the corporate email standards don't really apply. Sure, most of these run on top of CPanel or such and use same server for mail, database and web, so they could deny local address coming from remote source. However, I seriously doubt this is default setting (I have used at least 4 shared hostings that use CPanel, all of them have accepted the mail coming from local address directed to local address). Also, at least CPanel and Plesk don't have port 587 enabled by default for SMTP, so people behind ISP firewall that blocks port 25 would be screwed with default install.
-
@morbiuswilters said:
An MTA that accepts mail for a domain it is hosting without authentication is an open relay. That's what we are talking about here. Please try to pay attention.
Um, no. An MTA that accepts mail for a domain it is not hosting without authentication is an open relay. An MTA that accepts mail for a domain it is hosting is how things are supposed to work.
-
@Random832 said:
@morbiuswilters said:
An MTA that accepts mail for a domain it is hosting without authentication is an open relay. That's what we are talking about here. Please try to pay attention.
Um, no. An MTA that accepts mail for a domain it is not hosting without authentication is an open relay. An MTA that accepts mail for a domain it is hosting is how things are supposed to work.
Oh God, more idiots who can't be bothered to read the thread. I was referencing an outgoing SMTP server in the above quote. If you had bothered reading the context, you would know that.
-
@morbiuswilters said:
An incoming SMTP server that permits external clients to send mail from a local domain is just laziness as there are better alternatives and I would consider it misconfigured as well.
I believe this is the primary case that everyone here but you have been talking about. The original context clearly indicated a message that was to be injected from an external address, purportedly going from an internal address to that same internal address. A server that allows this is misconfigured, as you have indicated. It is not an open relay, contrary to your statements made above, and included below.
Note that, in the first post where you called it an 'open relay', you were referring to an example data stream where someone purportedly connected to a particular email server, and generated a message from outside the system to one of its users. This does not even come at all close to an open relay. If Buzer was connecting from an end-user IP address, he should've been rejected because of being on a "dialup user blacklist" (as they are called for historical reasons). If moocow.com had an SPF record or a SenderID record (it doesn't), then the mail server should've checked to make sure Buzer was connecting from an authorized IP. But since he wasn't attempting to claim he was a local user, SMTP AUTH doesn't enter into it.
References:
@Heron said:
I'm tempted to send him a friendly e-mail letting him know the situation... from his own e-mail account.
@SlyEcho said:
POP3 is not used for sending email. Besides, sending does not require any credentials anyway.
@morbiuswilters said:
Only if the mail server is misconfigured. If SMTP Auth is being used, the password will probably be pulled from a central store, such as LDAP, meaning it will be the same as the POP3 password. Another possibility is POP-before-SMTP. Either way, sending should require credentials.
@Buzer said:
<snip> Now, where did I need password again? Sure, mail server might not (but usually does) accept messages directed to it from address it handles without authentication and possibly deeper sender verify.
@morbiuswilters said:
Did you miss the "misconfigured" part? An MTA that accepts without some authentication is known as an "open relay" and is a major source of spam. Non-authenticated SMTP is very stupid. Your example is not even on-topic. We're talking about sending to a particular mailbox from the same mail address. You aren't even doing that. Please educate yourself before you make false, ignorant statements.
-
@tgape said:
I believe this is the primary case that everyone here but you have been talking about. The original context clearly indicated a message that was to be injected from an external address, purportedly going from an internal address to that same internal address. A server that allows this is misconfigured, as you have indicated. It is not an open relay, contrary to your statements made above, and included below.
Once again, injecting through the incoming SMTP server is not likely to be successful at all. Sending the message through the outgoing SMTP server would likely work, assuming you have the proper credentials (and we probably do for this account). If the outgoing SMTP server did not require authentication, it would be an open relay. I never said that an incoming SMTP server that accepted mail from and to the domain it is hosting is an open relay. In fact, I didn't even bother mentioning that route because the mail server should reject the attempted forgery outright (assuming the mail admin isn't a complete dumbass and excluding free, public webmail services that allow this for compatibility reasons).
@tgape said:
If moocow.com had an SPF record or a SenderID record (it doesn't), then the mail server should've checked to make sure Buzer was connecting from an authorized IP. But since he wasn't attempting to claim he was a local user, SMTP AUTH doesn't enter into it.
SPF does not apply to outgoing SMTP. SMTP Auth (usually) does not apply to incoming SMTP. These are two distinct concepts. What is so hard to comprehend about that?
-
@morbiuswilters said:
Once again, injecting through the incoming SMTP server is not likely to be successful at all.
You're the only one making this claim. You're also the only one who seems to be suggesting to try talking to the domain's outgoing mail servers.
In all of the companies I've worked, the outgoing mail servers weren't even accessible to the outside - they could initiate TCP connections to the outside world, but could not receive them. At least one of those companies had blocks on incoming TCP connections at both a 'hardware' firewall layer and a host-based firewall layer - and it wasn't even running an email server on the external interface.
I generally like to stick to attempting to talk to IP addresses that will at least ACK my SYN.
I've never actually seen an Internet-facing outgoing SMTP email server which *was* running SMTP auth.
I've seen SMTP auth used in two situations:
- inside a company that realizes that spam zombie viruses inside the company might try to send spam
- on Internet-facing inbound SMTP gateway boxes, to allow remote employees to send email with their company email address as the sender.
As such, I've definitely seen SMTP auth on more incoming SMTP servers than on outgoing SMTP servers, especially when you restrict it to just boxes which can actually talk directly to the Internet. (I don't know why it's so difficult for company execs to understand that spam zombies send spam, but I've only seen that argument won in one company: the one I work at right now.)
@morbiuswilters said:
I never said that an incoming SMTP server that accepted mail from and to the domain it is hosting is an open relay.
@morbiuswilters said:Did you miss the "misconfigured" part? An MTA that accepts without some authentication is known as an "open relay" and is a major source of spam. Non-authenticated SMTP is very stupid. Your example is not even on-topic. We're talking about sending to a particular mailbox from the same mail address. You aren't even doing that. Please educate yourself before you make false, ignorant statements.
Note that this was said in response to a quote of a session talking to the incoming SMTP server for a domain. You lose.
-
<add name="WebSurveyTool" connectionString="Data Source=192.168.1.2;Initial Catalog=WebSurveyTest;Persist Security Info=True;User ID=sa;Password=webmyne" providerName="System.Data.SqlClient" />Their SA password is there too if anyone gets far enough...
4chan posting anyone?
-
@tgape said:
I've never actually seen an Internet-facing outgoing SMTP email server which was running SMTP auth.
How about the aforementioned free mail services?
@tgape said:
on Internet-facing inbound SMTP gateway boxes, to allow remote employees to send email with their company email address as the sender.
Well... how's that different from "an Internet-facing outgoing SMTP email server which was running SMTP auth"?
-
@tgape said:
@morbiuswilters said:
Once again, injecting through the incoming SMTP server is not likely to be successful at all.
You're the only one making this claim.
The claim that it won't be successful? I just checked it out and the server happily accepted my forged email. The hosting company is running an ancient version of qmail, though, and after poking around some more I don't have a lot of confidence that the hosting company knows what they are doing. So in this case, sending through the incoming SMTP server with a forged local address worked without auth. I was wrong, but I guess I shouldn't be surprised by how shitty some setups can be. That doesn't change the fact that their mail servers are set up incorrectly and permit forged emails from local addresses originating from anywhere on the Internet. If you don't think that is "misconfigured", then you are TRWTF.
@tgape said:
In all of the companies I've worked, the outgoing mail servers weren't even accessible to the outside - they could initiate TCP connections to the outside world, but could not receive them. At least one of those companies had blocks on incoming TCP connections at both a 'hardware' firewall layer and a host-based firewall layer - and it wasn't even running an email server on the external interface.
So how do you send mail externally? VPN? You do understand that your experience isn't all that relevent and that plenty of outgoing mail servers are externally accessible? Even if the server is only accessible via the internal network it should still use authentication to prevent forgeries within the organization.
@tgape said:
Note that this was said in response to a quote of a session talking to the incoming SMTP server for a domain. You lose.
Note where I said his example wasn't even on-topic because he wasn't sending from the same domain he was sending to. Anyway, this thread has become seriously retarded. You're just nitpicking and trying to find statements that seem contradictory out-of-context. I still maintain that the general statements I made should apply to any well configured mail system, even if they don't apply to this bargain basement hosting provider.
-
@Spectre said:
@tgape said:
I've never actually seen an Internet-facing outgoing SMTP email server which *was* running SMTP auth.
How about the aforementioned free mail services?
I don't think he's making much sense anymore (if he ever was). If an outgoing SMTP server was Internet-facing, it would have to use some form of authentication or else it would be an open relay.
@Spectre said:
@tgape said:
on Internet-facing inbound SMTP gateway boxes, to allow remote employees to send email with their company email address as the sender.
Well... how's that different from "an Internet-facing outgoing SMTP email server which was running SMTP auth"?
Once again, he seems confused. Plenty of outgoing SMTP servers are accessible via the Internet for this very reason. Otherwise you can only send from within the office or using a VPN. Most ISPs work this way as well, so you can use your ISP mail account to send even if you aren't at home.
