-
Notifications
You must be signed in to change notification settings - Fork 0
/
exercise_11.py
7 lines (7 loc) · 7.42 KB
/
exercise_11.py
1
2
3
4
5
6
7
import re
search_str = "ashutosh email id:- [email protected] the data more readable, people usually set up filters. The simplest idea is to add a “signup” label to all the emails arriving to [email protected] and do the same for every different address you’re monitoring. It will give you very clear information on what worked and what didn’tThis method likely also works with some other email providers but we haven’t tested it yet. If you have a chance, drop us an email (to the real address!) and we’ll be happy to update the articleWhy using temporary emails might not be the best approach?As you might have guessed from the title of this post, we don’t believe temporary email addresses really solve the problem. They’re perfectly fine if you need to test a very simple web application. By that, we mean a platform where email workflows are only limited to password reset and registration confirmation, without any focus on user permissions, media, formatting of emails and others. Set up a few temporary addresses and you’ll do all the testing within minutesThe real problem, in our opinion, comes with more complex applications that include but are not limited toDifferent user permissions and levelsMobile and web appsPaid and free plansEmail onboarding and contextual messagesTransactional emails built into the platform etc.Such workflows require dozens if not hundreds of test email accounts to be set up. Not only before the product launch, but for every single change in the application that could impact email communication. Unless you have a dedicated team at your disposal that can be used solely for setting up and tracking throwaway accounts, this immediately disqualifies disposable email services. Typically, they vanish within up to a few hours. If you added 100s of [email protected] type addresses to your codebase, they would be nothing but useless by your next testing sessionAnother drawback of such solutions is that they have very limited design testing capabilities. Sure, most tools can preview plain text and HTML. This should let you spot the most notorious errors and safely test, for example, password reset emails. But, if you’re going to send emails to thousands of users who will open them on hundreds of devices, you will want to put in a bit more effort. Ultimately, you’ll need to test your emails with a separate tool before they’re ready to be deliveredInspect&Debug Your EmailMailinator is a bit of a different story as the email addresses are already created and they don’t disappear after your initial tests. The free tier raises security concerns though. In theory, anyone could read your confidential emails and click on links to your users’ profiles, without even registeringA paid ($159/month) plan is a better option. This way, you can set up hundreds of email accounts and reuse them freely for your tests. API access will let you automate the process and you’ll be able to see all incoming test emails in a Super-Inbox without having to load each account.The issue, however, for both Mailinator and throwaway emails is sending thousands of emails to test accounts in the first place. These domains are not really known for a high sender reputation. Test emails, by definition, also have poor engagement. Both of these factors can seriously affect the deliverability of your legitimate emailsAnd finally, there is still a risk of spamming real users with your test messages. Even the most proficient QAs and developers can miss a line of code here and there that handles some email workflow. If the reference to a real database is not replaced with a dummy email address for testing, real users will likely get your “hello world” message. Some might say “hi back!” but most will be rather disappointed with your lack of professionalismCan I set things up on my own?For someone who’s had some DevOps experience in the past, the obvious approach might be to set up the test environment on their own, without relying on 3rd party tools. This would meanSetting up an infrastructure to handle hundreds of email addresses on your domainGenerating names and settings for all accountsSetting up rules for tracking if emails are receivedAdding these newly created addresses to your applicationSetting up an SMTP server to handle the sending of test emailsExecuting the QA tests on your new farm of dummy emailsThe biggest hurdle here might be with setting up the SMTP infrastructure, especially if you want to do it on a budget. There are even free, ad-powered SMTP servers available to be used but, very likely, such emails won’t even make it through a basic spam firewall. As a result, you might end up investigating failed deliveries when everything, in fact, is set up properly. To get a reliable SMTP server to set things up, you’ll likely need to spend a few dozen bucks on a monthly basis (+ the regular server expanses)Even if you do, you will still be facing some of the obstacles mentioned above. If emails are formatting-heavy, you’ll likely need to check each delivery individually. Even if the messages look fine on Gmail, you won’t be sure if they have the same look on Thunderbird or in Outlook, not to mention less popular browsers. If you were to check this manually, this would amount to quite a lot of work you likely can’t afford. Sure, you could integrate your testing environment with other tools to preview emails or check them for spam “eligibility” but this would mean extra time and likely additional subscriptionsLast but not least, you would still be at risk of sending emails accidentally to real users for the same reasons outlined in the last chapter.Is there an alternative to dummy email testing?Now, if you’re wondering if there’s an easier way to go about all of this, we think there is. Mailtrap was created precisely to overcome such obstacles and make the testing process a breeze rather than a nightmareMailtrap is a software for testing your email workflows without the risk of accidentally reaching your users. It’s a fake SMTP server that can be integrated with your application to perform the needed tests. Since the server is fake, the emails sent don’t reach any real or temporary mailbox and don’t affect your deliverability in any wayTry Mailtrap for FreThey stay on the Mailtrap platform, giving you clear information on what was delivered and how it looked like for end-users, regardless of the browser or app they used. Each email can be also previewed, tested for spam and forwarded to real addresses of your teammates. And all of these can be set up within an hour or so and is likely even more cost-effective than your own infrastructure built for the same purposesLearn why The Software House replaced other solutions with Mailtrap and streamlined their email testing processes from our case studyArticle byAndriy ZapisotskyiGrowth Manager @MailtrapCreate Your Free AccountIn 3 ClicksSign Up NoRailsware ExperienceMailtrap BlogCoupler.ioSmart Checklist for JiraCareers – Railsware HiringMailtrapPricingChangelogStatusTerms of ServicePrivacy PolicyNavigational InformationDPAContactemail: [email protected]© Railsware Products Studio, Inc.Mailtrap uses cookies to enhance your browsing experience, analyze traffic and serve targeted ads. By continuing to use our site and application, you agree to our Privacy policy and use of cookies.Accept"
emails = re.findall("[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+",search_str)
i = 1
for mailid in emails :
print(f"email {i} :- {mailid}")
i+=1