I have a windows 2003 server which is running the IIS(6.0) virtual SMTP server. I have written a event sink for this server to parse and pop incoming e-mails. I'm trying to get the server to accept incoming domains with a wild card. So *.something.com would be accepted by this server.
If I use an alias domain, it wont allow me to use a wild card. If I use a remote domain, I can use a wild card but I have to turn relaying on (which I don't want to do) and it attempts to send itself a message on top of that. If relaying is turned on, i get a error response 5.3.5.
With all that said, I'm looking for a way to configure my server to accept alias domains with wild cards.
I found no configuration that allowed me to do this. My solution is ugly, but it works. I kept the relay and only Allowed the server to relay to itself. I also changed the Imessage.envelopeField.MessageStatus to abort on successful read so that it wouldn't be processed by anything other then my sink (thus, not being routed to a "new" destination).
On windows 2003, to have accesses to the Imessage class you need to import cdo.dll.
Related
I want to understand how my local IP address (localhost) can be exposed to Internet. For that I've read [here] a method of port forwarding using SSH. Which basically does routing from publicly available server to our localhost using SSH.
But I wonder how the service like 'LocalTunnel' works? In above article it's written as following:
There services (localtunnel for example) creates a tunnel from their server back to port 3000 on your dev box. It functions pretty much exactly like an SSH tunnel, but doesn’t require that you have a server.
I've tried reading code from it's github repository and what I understood is:
These services have a server which is publicly available, which generates different URLs, and when we hit that URL, It forward the request to localhost corresponding to that URL.
So basically it's works like a proxy server.
Is these understanding correct? If yes then what I don't understand is that how these server has access to some localhost running on my computer? How it perform request to it? What I'm missing here? Here is the code which I referred.
The Short Answer (TL;DR)
The Remote (i.e. the localtunnel software on your computer) initializes the connection to the Relay (i.e. localtunnel.me) acts as a multiplexing proxy and when Clients (i.e. web browsers) connect, the relay multiplexes the connections between remotes and clients by appending special headers with network information.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
Video Presentation
If you prefer a video preso, I just gave a talk on this at UtahJS Conf 2018, in which I talk a little about all of the other potential solutions as well: SSH Socksv5 proxies (which you mentioned), VPN, UPnP, DHT, Relays, etc:
Access Ability: Access your Devices, Share your Stuff
Slides: http://telebit.cloud/utahjs2018
How localtunnel, ngrok, and Telebit work (Long Answer)
I'm the author of Telebit, which provides service with similar features to what ngrok, localtunnel, and libp2p provide (as well as open source code for both the remote/client and relay/server to run it yourself).
Although I don't know the exact internals of how localtunnel is implemented, I can give you an explanation of how it's generally done (and how we do it), and it's most likely nearly identical to how they do it.
The magic that you're curious about happens in two places: the remote socket and the multiplexer.
How does a remote client access the server on my localhost?
1. The Remote Socket
This is pretty simple. When you run a "remote" (telebit, ngrok, and localtunnel all work nearly the same in this regard), it's actually your computer that initiates the request.
So imagine that the relay (the localtunnel proxy in your case) uses port 7777 to receive traffic from "remotes" (like your computer) and your socket number (randomly chosen source address on your computer) is 1234:
Devices: [Your Computer] (tcp 1234:7777) [Proxy Server]
Software: [Remote] -----------------------> [Relay]
(auth & request 5678)
However, the clients (such as browsers, netcat, or other user agents) that connect to you actually also initiate requests with the relay.
Devices: [Proxy Service] (tcp 5678) [Client Computer]
Software: [Relay] <------------------------ [netcat]
If you're using tcp ports, then the relay service keeps an internal mapping, much like NAT
Internal Relay "Routing Table"
Rule:
Socket remote[src:1234] --- Captures ------> ALL_INCOMING[dst:5678]
Condition:
Incoming client[dst:5678] --- MATCHES -------> ALL_INCOMING[dst:5678]
Therefore:
Incoming client[dst:5678] --- Forwards To ---> remote[src:1234]
Both connections are "incoming" connections, but the remote connection on the "south end" is authorized to receive traffic coming from another incoming source (without some form of authorized session anyone could claim use of that port or address and hijack your traffic).
[Client Computer] (tcp 5678) [Proxy Service] (tcp 1234) [Your Computer]
[netcat] --------------> <--[Relay]--> <------------ [remote]
2. The Multiplexer
You may have noticed that there's a critical flaw in the description above. If you just route the traffic as-is, your computer (the remote) could only handle one connection at a time. If another client (browser, netcat, etc) hopped on the connection, your computer wouldn't be able to tell which packets came from where.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
Essentially what the relay (i.e. localtunnel proxy) and the remote (i.e. your computer) do is place a header in front of all data that is to be received by the client. It needs to be something very similar to HAProxy's The PROXY Protocol, but works for non-local traffic as well. It could look like this:
<src-address>,<src-port>,<sni>,<dst-port>,<protocol-guess>,<datalen>
For example
172.2.3.4,1234,example.com,443,https,1024
That info could be sent exactly before or append to each data packet that's routed.
Likewise, when the remote responds to the relay, it has to include that information so that the relay knows which client the data packet is responding to.
See https://www.npmjs.com/package/proxy-packer for long details
Sidenote/Rant: Ports vs TLS SNI
The initial explanation I gave using tcp ports, because it's easy to understand. However, localtunnel, ngrok, and telebit all have the ability to use tls servername indicator (SNI) instead of relying on port numbers.
[Client Computer] (https 443) [Proxy Service] (wss 443) [Your Computer]
[netcat+openssl] --------------------> <--[Relay]--> <------------ [remote]
(or web browser) (sni:xyz.somerelay.com) (sni:somerelay.com)
MITM vs p2p
There are still a few different ways you can go about this (and this is where I want to give a shameless plug for telebit because if you're into decentralization and peer-to-peer, this is where we shine!)
If you only use the tls sni for routing (which is how localtunnel and ngrok both work by default last time I checked) all of the traffic is decrypted at the relay.
Anther way requires ACME/Let's Encrypt integration (i.e. Greenlock.js) so that the traffic remains encrypted, end-to-end, routing the tls traffic to the client without decrypting it. This method functions as peer-to-peer channel for all practical purposes (the relay acts as just another opaque "switch" on the network of the Internet, unaware of the contents of the traffic).
Furthermore, if https is used both for remotes (for example, via Secure WebSockets) and the clients, then the clients look just like any other type of https request and won't be hindered by poorly configured firewalls or other harsh / unfavorable network conditions.
Now, solutions built on libp2p also give you a virtualized peer connection, but it's far more indirect and requires routing through untrusted parties. I'm not a fan of that because it's typically slower and I see it as more risky. I'm a big believer than network federation will win out over anonymization (like libp2p) in the long. (for our use case we needed something that could be federated - run by independently trusted parties- which is why we built our solution the way that we did)
I've been trying to figure this out for a couple days now. I've got a little linux box that should send email alerts and I need to test this functionality. It's a very, very basic linux box (painfully so).
Is it possible to setup a fake SMTP server on my desktop (IP:192.168.0.20) that it (192.168.0.2) can send emails to? I need to confirm that the messages are correct in content, but that's all. I'm perfectly fine having this spit out to the terminal. There's no DNS on the local network, or DHCP, I'm just using static IP addresses so it needs to work within that limitation.
I've been able to confirm with wireshark that the embedded computer is trying to do something over SMTP, but I don't see any message content at all, looks like it's just trying to talk to the server. I've also tried sending a message using "mail" but I keep getting an "SMTPclient: agent: unknown host" error, which I assume means it can't find the SMTP server I'm telling it to find.
I'm using Ubuntu 14.04 on my desktop.
Thanks!
So, as a basic test it works to just have an SMTP server running on your local machine. Installing Postfix should be all that's required. I set up the relay to our local mailserver but it wouldn't relay through. From the error messages I was getting I gather this is a DNS issue, it can't resolve where to direct the message. Watching wireshark you should be able to see the traffic and the attempt to send the message, which is something I guess. I will update when I have a better answer.
I'm writing a piece of P2P software, which requires a direct connection to the Internet. It is decentralized, so there is no always-on server that it can contact with a request for the server to attempt to connect back to it in order to observe if the connection attempt arrives.
Is there a way to test the connection for firewall status?
I'm thinking in my dream land where wishes were horses, there would be some sort of 3rd-party, public, already existent servers to whom I could send some sort of simple command, and they would send a special ping back. Then I could simply listen to see if that arrives and know whether I'm behind a firewall.
Even if such a thing does not exist, are there any alternative routes available?
Nantucket - does your service listen on UDP or TCP?
For UDP - what you are sort of describing is something the STUN protocol was designed for. It matches your definition of "some sort of simple command, and they would send a special ping back"
STUN is a very "ping like" (UDP) protocol for a server to echo back to a client what IP and port it sees the client as. The client can then use the response from the server and compare the result with what it thinks its locally enumerated IP address is. If the server's response matches the locally enumerated IP address, the client host can self determinte that it is directly connected to the Internet. Otherwise, the client must assume it is behind a NAT - but for the majority of routers, you have just created a port mapping that can be used for other P2P connection scenarios.
Further, you can you use the RESPONSE-PORT attribute in the STUN binding request for the server to respond back to a different port. This will effectively allow you to detect if you are firewalled or not.
TCP - this gets a little tricky. STUN can partially be used to determine if you are behind a NAT. Or simply making an http request to whatismyip.com and parsing the result to see if there's a NAT. But it gets tricky, as there's no service on the internet that I know of that will test a TCP connection back to you.
With all the above in mind, the vast majority of broadband users are likely behind a NAT that also acts as a firewall. Either given by their ISP or their own wireless router device. And even if they are not, most operating systems have some sort of minimal firewall to block unsolicited traffic. So it's very limiting to have a P2P client out there than can only work on direct connections.
With that said, on Windows (and likely others), you can program your app's install package can register with the Windows firewall so your it is not blocked. But if you aren't targeting Windows, you may have to ask the user to manually fix his firewall software.
Oh shameless plug. You can use this open source STUN server and client library which supports all of the semantics described above. Follow up with me offline if you need access to a stun service.
You might find this article useful
http://msdn.microsoft.com/en-us/library/aa364726%28v=VS.85%29.aspx
I would start with each os and ask if firewall services are turned on. Secondly, I would attempt the socket connections and determine from the error codes if connections are being reset or timeout. I'm only familiar with winsock coding, so I can't really say much for Linux or mac os.
We're Having an issue with sending an MSMQ message to the second DNS name on a server. If we send the IP for that same server, we're fine, but thats not where we are going architecturally. Any ideas as to why MSMQ would care about which name it receives?
Server Information:
The physical server load-int-01, has a second IP and DNS name associated with it.
First IP/DNS: load-int-01, with IP 10.0.10.10
Second IP/DNS: load-intv, with IP 10.0.10.20
Queue Path Formats Used:
FormatName:DIRECT=OS:load-int-01\private$\MyQueue → Works Fine
FormatName:DIRECT=OS:load-intv\private$\MyQueue → Returns the error…
The queue does not exist or you do not have sufficient permissions to perform this operation
We have also tried using the IP addresses instead, and both sets of IPs work fine.
FormatName:DIRECT=TCP:10.0.10.10\private$\MyQueue → Works Fine
FormatName:DIRECT=TCP:10.0.10.20\private$\MyQueue → Works Fine
We just got off the phone with Microsoft. This is a limitation of MSMQ. You can not receive on queues with a DNS name different than the server NETBIOS name. You can SEND to queues with an alternate DNS name provided you use the two registry keys mentioned above, OptionalNames and IgnoreOSNameValidation.
Back to virtual ip's for us, or we might keep the virtual name for the sending connection strings (with the reg settings) and use .\ for the receiving servername...that works.
Thanks for the help.
From:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;899611
By default, Message Queuing verifies the message that it receives to determine whether the message is intended for the local computer. If the message is not intended for the local computer, the message is rejected.
So follow the section on "IgnoreOSNameValidation" in this article and I hope it will help.
Very frustrating. I'm trying to migrate some MSMQ targets (web services) and I guess I will have to configure them to use virtual IPs, and migrate the virtual IPs, since migrating the NetBIOS name will be a mission.
MSMQ should be re-christened MSMQ-1982, since it appears to predate the invention of a cunning and useful abstraction layer called "DNS" in 1983.
I had the same issue and got it working. The trick for me was after setting the IgnoreOSNameValidation registry key, you have to restart the Message Queuing service.
I know this is an old post, but it comes up in Google when searching for a solution to this issue.
This did work for me:
FormatName:DIRECT=TCP:HOST.TLD\PRIVATE$\MyQueue
Note that uses TCP instead of OS. This is the relevant documentation:
Non-transactional messaging by using Direct=TCP This configuration
functions without any particular configuration changes.
I'm developing a website on an XP virtual machine and have an SMTP virtual server set up in IIS -- it delivers mail just fine. What I would like is to confirm that any emails the site sends are only going to a specific domain.
The XP firewall seems to only involve incoming connections, I can't block outgoing TCP on port 25. And I haven't been able to configure the SMTP server to filter by delivery address.
With this setup, is there any easy way to filter outgoing email by destination address?
Here's one idea:
Under Advanced Delivery options (SMTP Virtual Server Properties > Delivery tab > Advanced). There you can set a "Smart Host" which is the SMTP server that will be used to actually send the mail, so you could possibly have it deliver directly to the specific domain's incoming SMTP server.
I think the easiest way would be to add a check to your mail sending code on the website (there's got to be some class which is in charge of sending the mails out).
You could include a check which is only active when the code is compiled in debug mode (using compiler directives). Thus, when you are developing and building the site in debug mode, this code checks if the outgoing messages are valid (specific domain) or not. If they are it lets them go, else it doesn't send the mail.