Is there a way to peek or see a message before it hits the SMTP on IIS. This is not an Exchange Server, it's just running SMTP. I am trying to see if I can look at the message and then pass it to SMTP?
Thanks
Edit ~ Instead of adding another listner, I am wondering if there is a way to bind to the default SMTP listner and intercept the message then pass it on.
2nd Edit~ Ok, here is my problem. I have a spam filter in front of my exchange box, unfortunately (due to software design) the filter is limited when it comes to "Directory Harvesting Loookup". This is the process where the email addresses are checked if they exists in AD and the mail is dropped if they don't. My current filter drops the mail if one of the addresses does not exists in AD which is not good. I spoke with the vendor and there is nothing they can do at this time. I am looking put an app in front of this filter which would intercept (open, read, parse) the mail, validate the addresses, and then pass on the email to the filter for additional scanning. I'll then trun off this feature in their software. Don't get me wrong, their filter works great with this one exception which I must fix since I have tons of emails send to nonexistent users in my domain.
You can write your own Proxy SMTP service that you connect to to send messages. You can forward all messages directly to your actual SMTP service and pass all responses back. Then you can evesdrop on all these messages and deal with them accordingly.
Might be a bit overkill for what you're after but it's fairly simple to code as you dont need to know anything about the protocol as all you're being is a proxy.
If you're using .NET 2.0 then you can log SMTP sessions to a file:
How do I create a log file of the SMTP session? (System.Net.Mail)
Updated:
Take a look at this question:
Testing SMTP with .net (Stack Overflow)
From your edit:
"I am wondering if there is a way to bind to the default SMTP listener and intercept the message then pass it on?"
...and from your comment below:
"I am looking to inspect the actual message before the SMTP gets it."
I'm not sure if you fully understand the SMTP protocol. SMTP messages aren't just monolithic fire-and-forget entities. SMTP is session based and there is a conversation between client and server, of which, the message is just a part. The tracing method (linked to above) will record the entire exchange between client and server and does intercept the whole message before passing it on. The alternative, a proxy or mock server, will still require your application to engage in the SMTP client/server exchange. The closest solution to your requirement would be to use something like Papercut which is linked to in the answer above.
Kev
In .Net you can tell the SmtpClient to send email to a different folder than the SMTP service is monitoring. That way you could check each message, then move it to the real pickup folder. (See SmtpClient.PickupDirectory)
IIRC, you can still write up event sinks for the IIS SMTP service (even though it's not full blown exchange). It's been many years since I've done this, but you may want to google for "exchange event sink" to see if that helps.
Seems like a something like Ethereal will let you accomplish the sniffing portion of your request. Its not clear to me what you mean by "intercept" and "pass on". Do you want to filter some traffic or just delay traffic long enough for you to inspect before you pass it on, or both?
Related
I am using phpmailer 6.5.0.
Are the sent emails stored on the server in any way? To put it another way, could the administrator by the webservices see the mail traffic afterwards?
best regards
claus
The web server will not log SMTP traffic (though it would log any HTTP requests that triggered message sends), but if you relay through a local mail server (as is recommended), then the mail server will have logs of both message submission and onward delivery.
You can of course add logging at various levels of detail, either by logging things yourself (e.g. whenever you call send(), or perhaps using the Debugoutput property to inject a callable.
I need to interface a secure system that is situated in a protected LAN environment that absolutely must not expose any inbound tcp connections. Thus serving up an http server to provide a means to a webhook service to call as its callback is not an option.
I need to use a third party SMS provider to send and receive text messages. Receiving text messages is the problem.
So I've never really understand how so many services require their customers to provide a webhook. It's such a headache. Companies provide nice things like SDK. For example, when I want to send SMS messages using Twilio of Telnyx for example, I take their jar files, and basically just call a few methods and the SMS is sent without much fanfare. But the fun starts when I want process incoming SMS messages with those (and other) providers. They demand you host a webhook. So there are webhook providers that remove the pain of providing ways to fend of ddos attacks and other heinous scripting kiddies and whatnot, but then those webhook providers still require me to host an http server for it to drop its events to. Why can't I just keep a tcp connection alive to such a provider, and read from a connection that won't send data back until there is something to report, with a periodic heartbeat? And why can't companies like Twilio and Telnyx and others provide all this, without webhooks? It ought to be as simple as providing an event handler interface that simply gets called when needed. The customer shouldn't have to worry about anything more than just dropping in a library and providing a callback method, imo! It's completely feasible, yet it's not provided! Why?
So, because those companies are forcing me to provide a webhook, is there a webhook provider that I can keep a connection open to, where read request trickle out content as needed? A way where I do not have to host any http server?
can I send an email through a PHP mailer with my localhost without using Gmail? or any other email service like Hotmail, outlook using my localhost?
Yes, and this is actually the best way to send using PHPMailer. There are two things you need:
A hosting provider that permits outbound SMTP. A large number of providers block SMTP by default, but you may find that they will remove the block on request (scaleway.com), provide an alternative service (AWS), which may also be acceptable.
A locally installed mail server. If you're on Linux, something like postfix is a good choice.
The way it then works is this:
Write your PHPMailer script as normal, but delivering to localhost over SMTP (not via mail())
Configure your mail server to act as a "full" mail server, where it attempts to deliver messages directly, or to act as a "smarthost" to relay through some other service, such as gmail or mailgun.
The main advantages of this approach are:
Perceived performance: your message submissions will appear to be instant, so it's great for things like contact forms
Reliability: if your message can't be delivered immediately, the local mail server will automatically take care of queuing and redelivery attempts, in a way that is far more efficient than you would ever achieve if you handled that within your own application.
As with many things, with great power comes great responsibility, and you will have to deal with bounce handling, blacklisting, inbound filtering (or just block it), etc. It's probably not worth doing all this for a simple contact form, but if you have an application that generates a reasonable amount of email traffic (signups, password resets, notifications, etc), it's a great way to go.
I have seen many of the posts relating to sending email under linux but they do not address my particular need.
I want to implement code (C/C++) in my linux application that will send me back some kind of notification (in a stealthy way) under a certain program condition. All it needs to send me is less than 50 bytes of status data. The only thing I am guarenteed is that the box will be on a local network which will have access to the Internet via the usual gateway.
One possibility would be to send me a text to my wireless carrier like this:
mynumber#verizon_gateway.com. But that assumes that I have a mail client available on the linux box which is not a guarantee. If I programmed this at the socket layer directly using SMTP I would have to manage a TCP connection which is not what I prefer to do.
Any suggestions of what would be a possible way to send me a notification from my linux app?
Thanks,
-Andres
For email you could use something like SendGrid, specifically their WebAPI - this will allow you to send email with only a HTTP request.
For SMS you could use something like Nexmo, which will allow you to send an SMS with a HTTP request.
Note that you'll have to include your API credentials in the compiled code - a potental security issue (for your credentials).
Disclaimer: I do a bit of developer evangelism for Nexmo.
I'd like to implement push notification server using node.js. The basic scenario is:
Some applications sends notification messages to the server.
Notification server receives the request and forwards the message to uesr's mail or IM client based on user's preference.
In step 1, which protocol (e.g. REST, socket, HTTP/XML and so on.) would you recommend from the performance perspective?
Also in step 2, I have a plan to use node-xmpp module for IM client but for mail, which way is the best to implement? For example,
Just use SMTP. (But I think this might occur performance degradation because SMTP is an expensive communication and performance depends on SMTP server capacity.
use queue mechanism, in order to avoid drawbacks from the above. node.js app simply puts the message into the queue, and smtp server pulls the message.
other solutions...
Thanks in advance.
With regards to what to use as a protocol, i would go for a REST interface, whereby the application posting sends a POST request to a resource associated with the USER. something along the lines of "http://example.com/rest/v1/{userID}/notifications
I personally would use json as the data/content of the rest request and have node.js write this information to a message queue. (as a json string).
You can than have xmpp readers for each user, as well as an SMTP handler reading from this queue as fast as the SMTP server allows it to go.
However, this full post is what i would do in your situation, rather than a factual response on what is best. I know JMS fairly well and i've been working a lot with rest interfaces lately, therefore this is the way i would do it.