Hi hope you're doing great! I'm looking a portable SMTP server (Windows), basically with RFC compliance for ETLs testing purposes. Right now I'm using Fake SMTP Server but it permits email addresses with invalid characters and oversized attachments so I need something close to real situations.
Please must be a portable app.
Best regards
Francisco
Search in Google for alternatives, not found.
Related
In developing our docusign application, we need to use real emails addresses (to test the addressing logic, etc.) but we do not want those users to get all the development envelopes. In our own code, we handle this using mailtrap.io, a custom SMTP service that traps emails and sends them all to a common inbox that developers can review. Is there a way to do something similar in your docusign developer account, where you would be using real email addresses, but they would not actually go the intended user.
thanks,
~Bill
Thanks for any help
No, you cannot. The emails are sent from DocuSign.
If you want to test the real thing, completely real, then it also includes emails being sent.
If you are ok making any change, so it's not 100% like the real thing, I would suggest to take your email address and change the domain (mailinator.com or your own internal domain) this is a change, yes, but also changing the SMTP server is a change, so in either case - you are not doing 100% what the real app will do.
The emails can also be suppressed (by changing account settings in DocuSign), but again, that won't test the real thing if that's what you need.
I have tried to have my SMTP server with exim4 for a while to send ecommerce registration and transaction confirms.
I followed all the good rules, like SPF, DKIM, DMARC, SMTP encryption. The postmaster tool by google said the IP has a good reputation and there are not spam traffic.
I reached a antispam test result of 10/10 using https://www.mail-tester.com/ or some similar tools.
But everything was not enough, my ecommerce registration messages are sent to spam by Gmail and it is the same with some other famous providers. I have understood I can't do nothing against.
Then, what is a good solution for user registration for an ecommerce? How can I reduce the messages delivered to spam folder?
I'm afraid you haven't provided enough information to identify the problem.
Hundreds of factors can contribute to deliverability outcomes; it's not as simple as setting up authentication, reverse DNS, etc. In addition, no free mail tester can accurately tell you how your deliverability will be at Gmail, Outlook, Yahoo, etc., because mail testers don't have the same data those ISPs use to make spam filtering decisions.
If you want more reliable deliverability, it's generally easiest to use a transactional email service to send email, rather than trying to run an SMTP server yourself. There are occasional exceptions to this, but because most senders will have an easier time using one of these services, it's almost always the first thing to try.
(How do email services provide better deliverability? A number of ways, but I think the biggest difference is that they can more closely manage the email sending reputation of their IP ranges. Having anti-spam systems built into the service enables them to resolve problems that much faster, compared to hosting providers which tend to have fewer tools and less data available to stop spammers, so their IP ranges' sending reputation is usually worse.)
Here is something you can try that may help.
Use a 3rd-party delivery provider (AWS SES, SendGrid, Mailgun) with a Good IP reputation. Here's a list of places you can check their IP reputation https://www.helloinbox.email/#reputation (Talos and Barracuda).
Use a subdomain to send transactional emails (email.example.com).
Let me know if that doesn't work.
Let's imagine that I have a site with some features that require email validation (eg. user registration). Of course I will validate emails using regex but once upon a time I saw SMTP validation in someone else's code. What good and bad sides has SMTP validation?
I can assume the following pros and cons:
Pros:
We can check out some email addresses for existence (not all SMTP servers allows this feature).
Cons:
Our site can be blocked.
Maybe we can use this to make webserver going down. Webserver will take domain part of email address and make request to it. We can create fake SMTP server that will receive request but will make great delay to response. Maybe if we force webserver to make dozens of such checks it will not be able to answer other clients.
Not all SMTP servers provide this capability.
Please be constructive.
"SMTP Validation" I assume refers to the SMTP VRFY command, and in this day and age you would be a fool to trust in it. It's a great feature if you're a spammer because it allows you to enumerate email addresses for a given server.
No one in their right mind will expose this command to the internet and have it respond with anything other than 252 send some mail, i'll try my best, aka "I'm only going to validate email addresses during an actual mail transaction".
The only sane use of VRFY these days is as an internal interface between a spam filtering appliance and the mail server hiding behind it.
TL;DR Don't use "SMTP Validation", it will be horribly unreliable at best.
If you want to validate that a user has entered a valid email address, then send it an email with an activation link/code.
In addition to Sammitch's answer, there are email validation services available via API that can provide SMTP validation - sometimes down to the mailbox level - for reasonable prices.
You can find these with a simple Google search, but I'm told LeadSpend and QAS (an Experian subsidiary) are among the best of the bunch.
I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
I've been playing with HTML5 location lookups recently and its relatively straightforward to pull someones location from a device like an iPhone.
I want to write an app that uses location data, but its important that the location be factual. In other words I need to prevent people from authoring a fake post to the backing website / web service with mocked up GPS coordinates.
Is there anyway to collect GPS coordinates from a mobile device using the HTML5 geolocation apis and securely transmit that back to a web service in a way that someone wouldn't be able to author a post with the same data and "game the system" so to speak?
Not without some serious encryption on the payload on the client. Which if there is money involved, someone will reverse engineer and figure out how to create valid payloads themselves. Remember if there is money or fame involved then somebody will think the effort to do something like this is "worth it". If your web service is public and not using some kind of encryption nothing on the client will ensure that someone with a network connection can't sniff your protocol and fake whatever data they want. And SSL won't cut it. Anyone can proxy the SSL connection on their local network decrypt the payload and inspect it to their hearts content.
No. Completely agree with the answer from fuzzy lollipop. If you’re talking to a remote machine, the data can always be faked. Always always. What makes you certain you’re even talking to a mobile device at all? The User-Agent string? Pfft, it can be faked. Talking to a GPS? Pfft, could be coming from a predefined path. Talking to a web browser? Pfft, could be a bot, or some other malware.
And don’t think encryption (i.e. HTTPS) is going to help you. The client could edit any of your HTML, CSS, or JavaScript on-the-fly — take Firebug or Greasemonkey for example.
The reasons why you can’t trust the client are the same as the reasons why exploits such as SQL or HTML injection are so common. Ever heard the phrase “the customer is always right”? Well, the customer may be right, but the client is always untrustworthy.
The system is there to be gamed. As flaws are discovered, you patch them one by one. It’s more like leapfrog, rather than achieving the holy grail. Bruce Schneier’s quip “security is a process, not a product” comes to mind. Asking for a system that “can’t be gamed” is missing the point. What you need to be doing is creating a system where the server sanitises the data, and/or rejects bad data — fuzz testing is not a bad idea, either.
That’s about the best you can do without shipping custom untamperable mobiles to your customers with the OS in ROM, and the inside sealed with epoxy.