My company has an app that currently only validates by looking for the '#' in the email address. The app is being upgraded to support other cultures and written language use-cases. I suggested using regex code from Microsoft that validates the addresses using regex. They don't see the need to use the regex version if checking for '#' works. My question here is... What pitfalls exist if the validation isn't good enough. Meaning the email server will not be able to send the emails if they have the '#' but fail other checks. What can go wrong?
The list can be quite long:
1#2
do#home
why#home¬#boooom
iAm#...
#where
#homeIsaid
NoYouAreNot#home
....#......
and so on.
All of these are mistakenly valid email addresses if you only check for #
That said, it's worth mentioning coming up with an email address regex that works can be quite difficult. See this
Related
It's cleanup time.
I'd like to cleanaup my mails. Therefore it would be nice to have all emails sorted/grouped by domains (optionally by TLD's as well).
I'm already using something similar - the field for the sender's email adress, which was described at https://www.howto-outlook.com/howto/viewsenderaddress.htm, which works perfectly. So I think something similar can be done for the domain (and TLD) as well.
Has someone here either a working solution ans share it or guide me how to achieve this.
Thx.
Remarks:
It's Outlook 2007 without Exchange
Thanks to a big search engine when using the proper words solution can be found. :-)
I have found a solution which displays the Senders Domain: https://www.extendoffice.com/documents/outlook/2190-outlook-view-sender-domain.html
and to Sort and Group on the Domain use
https://www.extendoffice.com/documents/outlook/2187-outlook-sort-group-by-sender-domain.html
I'm running OpenBD CFML isValid('email','something#whatever.education') and my result is 'NO'.
.education is a valid domain - why does this fail?
It turns out to be an issue with the regex used behind the scenes to match valid domains.
The regex in place didn't account for domains as long as "education".
I fixed it and it's been merged, should be in the nightly by now, grab the latest update and you should be able to use isValid("email", "AwesomeEmail#School.education") just fine. Viva la open source.
I'm using DotNetKit 1.2.6.5 and SagePayIntegration.Validation() is rejecting a customer email that uses the new .online domain (eg: foo#bar.online) with
CustomerEMail is invalid.
Is this fixed in 1.2.6.7 or is the source code for SagePay.IntegrationKit.DotNet.dll available somewhere so I can fix it?
Despite access to the source code (many thanks to #DavidG) SagePay Support have confirmed that the actual Gateway does not support all these new domains - so even if I modified the DotNetKit it would still be rejected by the Gateway.
SagePay support were very helpful but ultimately the
"... email domain foo#bar.online is not yet supported on our gateway.
We run development sprints continuously and although there are some
domains we may not yet support, we look to in future, dependent on
impact and demand..."
The SagePay Integration Kit uses this regex to validate email addresses:
[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*#(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zA-Z]{2,4})\b
Which does unfortunately not allow extra long TLDs. Fortunately I have the source code for the kit and I've added it to my GitHub account (along with a bug fix which is why I had to get it in the first place as SagePay are not updating it). You can find it here:
https://github.com/WiredUK/SagePay.IntegrationKit
And the Regex you need to edit is this file:
https://github.com/WiredUK/SagePay.IntegrationKit/blob/801f61cf965c391a98a025aa632949719084cef0/ApiRegex.cs
For info, you need to edit the very last part of the expression from 2,4 (which matches 2 to 4 characters in the TLD) to allow more, for example 2,30.
Edit: And just because I can, I opened an issue and fixed it.
Can I get a sample PHP code example which calls SmartyStreets LiveAddress API for address validation?
Sure -- we have sample code at our GitHub repository. There's 3 examples there:
A request to our API using cURL (can handle many addresses at once)
A GET request. Easy, but only supports one address per request
A "SLAP" (Single-Line Address Processing) example which shows how to verify an address if it's not already split into components like street, city, state, etc.
If you have any further questions, I'd be happy to help; I wrote these examples.
If you are developing SmartyStreet code on a test system that doesn't have a secure certificate, you can add this line to disable the certificate test:
if ($bTestSystem) curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
Smarty streets uses the same approach as many other solutions. The user enters an Address and then a lookup is performed and if the address is not found the user is presented a list of valid addresses to select. This is a slower approach that may not be ideal.
A newer approach that may be a better option comes from Addrexx. The Addrexx solutions allows users to autoselect their information from dropdown lists. This speeds the process on entering personal information. Full disclosure: I am a developer at Addrexx. Addrexx is a SaaS that includes complete integration packages for salesforce, magento, big commerce and many more platforms.
You can see the Addrexx approach at http://addrexx.com/ecommerce.html.
I'm using rails 3.1 with Devise. When an account confirmation email goes out, it is received with the following subject line:
Subject: [["test13#test.com"]]MySite Account Confirmation Instructions
I've modified the corresponding entry in config/locals/devise.en.yml like this:
mailer:
confirmation_instructions:
subject: 'MySite Account Confirmation Instructions'
I don't want the '[["test13#test.com"]] in the email subject line. How can I get Devise to not put it there? BTW I really don't want to have to create some custom mailer that overrides Devises' stock mailer... Big extra bonus points for an answer that avoids anything to do with custom mailers. But if that is the only way, I need to know that too...
My guess is that the [["test13#test.com"]] should actually only show up in development mode, since that's the format of ActionMailer's DevelopmentMailInterceptor (see the notes in RailsCast 206)
The email address between brackets indicates the address to which the email would have been sent on production. It instead sends it to you at an email specified in your DevelopmentMailInterceptor.
The mail subject is generated in Devise::Mailers::Helpers.headers_for (source code here), so the most straightforward way would be monkey-patching this method.
This was a strange one... Had to reboot my Mac, after which the problem was gone.