|
That's fine if I test this, but I want to make sure no one ever accidentally sends an email to someone who isn't expecting this.
Not testers, not newbies, and not me.
If I use my own account and I leave for a new job I'd have to change the mail settings or get test emails for all eternity.
I also want to be sure that an email is really send to the provided email address (but not actually delivered).
Fake SMTP does a great job at this, but requires infrastructure which I don't currently have.
|
|
|
|
|
I understand from your initial post that you only want to test the mail features. The used mail server settings must be replaced before going live.
The final SMTP server will be probably those of the company running the web site (or the SMTP server of their hoster if they did not have their own one) and a corresponding account (at best one created especially for the web service).
Quote: but I want to make sure no one ever accidentally sends an email to someone who isn't expecting this.
That is a different problem and one of those that can't be achieved by 100 % (besides not supporting mails to be send to addresses entered on the page).
It is a dangerous area. Once such a service is abused, the IP address of the sending SMPT server will be on several black lists.
Quote: I also want to be sure that an email is really send to the provided email address (but not actually delivered).
That requires that the fake server supports that by talking directly to the recipients mail server. Even if he is able to do that it might fail when the source IP is blocked (e.g. when using a dynamic IP adress).
|
|
|
|
|
Fake SMTP always did a good job of making sure no email was sent out to the actual recipients.
You set it up for your test environment and an email is send to the SMTP server, but the SMTP server simply doesn't send it to the recipient 
At least that's how I think it works (I don't know much about SMTP).
That's what Fake SMTP does and it's what Mailtrap promises.
|
|
|
|
|
Sander Rossel wrote: You set it up for your test environment and an email is send to the SMTP server, but the SMTP server simply doesn't send it to the recipient
I understand that. But if it is not talking to the recipients SMTP server (and it seems so after having a quick look), you would not even know if the recipient address exists.
So all you are testing is the email sending code on your web page (without authentication). If you only have a single recipient address (like with contact forms on web pages), it is better to send and deliver mails to real addresses.
From my point of view such a fake server would be only useful for testing the code that sends to multiple recipients like newsletters or the notificaton mails here at CP. But the first case (newsletters to a list of registered users) can be also done without a fake server when using a small test list.
A quick introduction what is happening when sending mails:- A DNS query is initiated for the domain part of the recipients address asking for the MX (Mail eXchange) record
- A connection to the returned IP address is establish on port 25 (SMTP)
- Using the SMTP protocol the mail is passed to the server
To avoid abuse and spamming, SMTP servers use nowadays a lot of checks before accepting a mail. This includes checking of the source IP address to be black listed or to be a dialup (dynamic) IP. So you usually do not use the above direct sending anymore but send the mail to a so called forwarding SMTP server. That is what you setup in your email client software or on a web server. For security and anti spam reasons, these require nowadays secure connections and authentication. The forwarding server will then establish the connection to the recipients SMTP server. If that fails, you will get a notification mail send to the account used for authentication (nowadays) and containing the error response from the recipients server.
A fake SMTP server is nothing else than a forwarding SMTP server that simply does not forward (does not connect to the recipients SMTP server or - if a better one - quits the SMTP dialog before pushing the mail content up).
Not much to do today at work. So I have plenty of time to write such long posts.
|
|
|
|
|
Personally I use smtp4dev[^] but there are probably lots if you look.
Another possible alternative, if you are using the SmtpClient, is to use a pickup folder rather than an smtp server.
SmtpDeliveryMethod Enumeration (System.Net.Mail)[^]
That way any mail sent though the client is simply written to disc instead for you to inspect at your leisure. However it will involve you having some kind of setting in your code that lets you specify if you are using a pickup folder or an actual smtp server and you'll need to switch between the two for testing\live.
|
|
|
|
|
F-ES Sitecore wrote: Personally I use smtp4dev[^]
Also not SaaS by the looks of it, but looks like a nice alternative for Fake SMTP.
F-ES Sitecore wrote: use a pickup folder rather than an smtp server
F-ES Sitecore wrote: it will involve you having some kind of setting in your code
Exactly, and being lazy as I am I don't want that 
|
|
|
|
|
Not sure if it will do you, but I use 'SMTP4Dev" for all emails I want to generate but go to a folder instead. I have usedd it for years, and it has served all my (fake) SMTP needs.
GitHub - rnwood/smtp4dev: smtp4dev - the mail server for development
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
|
|
|
|
|
Couple of options, SendGrid do a free Azure account with limited traffic for testing (search the Azure marketplace for Sendgrid free), VM with something like hMailServer or even just set something up elsewhere (e.g. your dev machine) and point the app to it...
It's worth pointing out however that you won't be able to run an SMTP server on azure in the long run - not only is it against the license, you won't be able to get appropriate reverse dns set up and the azure IPs are on pretty much every spam list going, so even if you set it up, hardly anyone will be able to receive the mails you send.
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Seems like SendGrid it is.
Apparently, someone set it up before me  
RichardGrimmer wrote: you won't be able to run an SMTP server on azure in the long run - not only is it against the license
What license? Can't I just spin up a VM and install some SMTP software?
|
|
|
|
|
You can, but you end up on shaky ground, and they reserve the right to remove it without notice or compensation etc...
C# has already designed away most of the tedium of C++.
|
|
|
|
|
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git.
While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either].
My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting.
Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps.
Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong.
I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office.
Rant over.
|
|
|
|
|
I did not enjoy git one bit, in the beginning. Today I would kill you if you took it away. You will fail if you try to use it with the "same old" mindset. So a lot of old concepts and habits will have to die.
Local branches for instance are no big deal. You create a local branch in a nanosecond. In CVS/SVN I never did it because it took forever. When working on a feature, that usually was one big commit. Today I typically create a branch for a feature or a bug fix. I commit once or twice to my local branch, publish if for review. We use github for review but there are many tools. People suggest improvements. I do the improvements. And then, after old and new unit tests have passed, I can merge. The nice thing, for me, with a branch for a feature, even a partial feature, is the review process. Everything on master has been well vetted.
Another thing with a local branch is that if it is a bigger feature, of lets say a dozen commits, it is a nice way of saving and keeping track of my own work. Also if I push my branch, I have a backup and do not have to worry about my hard disk.
Another thing, I always used a graphical plugin for SVN operations. With git I always use the command line, except for looking at diffs
... such stuff as dreams are made on
|
|
|
|
|
|
AndyStephens wrote: compared with the likes of TFS or SVN
Here the mistake : you are comparing apples and bananas.
Distributed version control is a different concept from centralized version control. Of course, DVC can also be set up and used as CVC, but that's not the primary goal, and could even end up to be counter-productive, sort of what you are experiencing right now.
I also have to fight the "Git is the new Svn" mentality in my company ; git is not meant to be an upgrade of SVN or TCS.
If you are looking for something to read, I recommend Eric Sink's approach of source control, you can check his website here[^]. The distributed concept is briefly, but sufficiently explained to get the idea.
|
|
|
|
|
I REALLY don't like Git. Subversion is much better in my opinion. 
But to be honest, I prefer REAL version control[^]! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
modified 7-Jun-18 9:14am.
|
|
|
|
|
How did you access my company servers?
I'm kidding, we don't use folders... we use zip files
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Because Linus Torvalds created it? 
|
|
|
|
|
It's not so much that git is complicated, it's that Microsoft have a knack for making things simple and intuitive. It's like going from Entity Framework to nHibernate, or any other similar examples. Of course people will get their fanboy hats on and try to defend or justify the complexity. The thing that annoys me most with git is having to google how to do things that really should be able to do with intuition alone, like google how to discard your working copy and get it back to the remote version and you'll find a hundred threads on SO, all with different archaic commands to type in various combinations, and every command has someone relying saying "don't do it like that".
|
|
|
|
|
F-ES Sitecore wrote: It's not so much that git is complicated, it's that Microsoft have a knack for making things simple and intuitive
 Oh, how I'd love to say just how much you're wrong here.
Unfortunately I can't. The more I look on the other side of the fence, the worse it looks.
|
|
|
|
|
These are the most used git commands that I use (using TortoiseGIT):
push, pull, commit, merge, check-out, create branch.
Once you know them well, there's no need to learn all others.
I'd rather be phishing!
|
|
|
|
|
All you ever need to know about GIT[^]
Although, coming from TFS to GIT, as I did many moons ago, the Atlassian GIT tutorial was worth its weight in gold - really good and simple to follow
Local branches are great - just remember to rebase regularly so they don't get stale (rebase essentially crops your commits out of your branch, then puts any commits from the source branch into is, then puts your commits back on top of the updates....means you don't have huge merge problems when you integrate back into source)
C# has already designed away most of the tedium of C++.
|
|
|
|
|
It's not intuitive, but not all that complicated. It's a different mindset. For me, the best thing about Git is that it is a more "universal" system. It may be a little weaker in some ways at working with source code, but I can version anything with git. I put design docs, models, etc. in my project and it handles them just fine. With extensions like GitHub, I do collaborative design through pull requests.
|
|
|
|
|
I used TortoiseSVN before moving to git. It's weird and a bit nonsensical at first but it has reasons. Basically everything revolves around branching and merging[^]. Once those make sense everything else starts to fall into place.
Another[^] good article that might help. Patch branching to resolve conflicts will inevitably be useful to you at some point 
EDIT: To answer your question: The main reason you branch every new feature is to allow flexibility. For example, say you're coding a new feature. You get a call, "OMG, YOU NEED TO HOTFIX THIS PRODUCTION BUG ASAP, THINGS ARE BLOWING UP!!!" You can easily branch a hotfix, test it, and merge it to production. Your feature branch has had no impact on production yet. Now you go back to your feature branch, finish it, test it, then merge it into production. Easy. And yes, the hotfix is still there because git uses a 3-way merge (source, destination, ancestor). As long as the code the hotfix changed wasn't also changed in your feature branch, you won't have any issues. If it was you can use the patch branching technique to choose which code to keep.
modified 7-Jun-18 14:17pm.
|
|
|
|
|
I've gone through the same hassle, moving from SVN to Git.
Now I really wouldn't want to go back!
Branching and merging in Git is so much easier and faster.
Everything is local, which means you can mess around, create some branches, do your thing, before finally merging and sending it back to the server.
You just have to flip a mental switch.
Don't think of Git as a different SVN, think of it as something completely different with the same goal of collaborating and keeping a code history.
One tip, don't use Git using Visual Studio.
I use SourceTree instead and it makes working with Git a whole lot easier.
VS is somehow missing some basic Git functionality...
|
|
|
|
|
Confused ex-pupil who dined while holding American feline (10)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
