We wanted to activate spam protection in EXT:powermail and implemented the example configuration from the documentation.
First we switched on the honeypot and the session check and the mails to us (administrators). After a few minutes we received some emails.
At first we thought it was just a transition, but unfortunately it didn't stay that way. We even contacted a website user by phone to see if he noticed anything when submitting the form (session check failed). But he hadn't noticed anything out of the ordinary. He also received a confirmation email and our recipient received the completed form.
Now our question: is it normal that the mails are sent despite a negative session check or honeypot (sometimes both together), or do we still have a configuration error? Why is an email sent at all if the form was detected as spam?
We use:
TYPO3 10.4.23
Powermail 8.2.3
Powermail will not send mails to the sender if the spam check is failing. There are a few checks which then lead to an spam-indication (from 0 to 100%). You can configure which check has which indication and when will be a stop in sending normal mails.
I would turn on logs or notification emails on spam for admins via TypoScript setup - see documentation https://github.com/einpraegsam/powermail/blob/develop/Documentation/ForAdministrators/BestPractice/SpamPrevention.md#configuration-via-typoscript
Related
We have an on-premise hosted Jira 6.0.8. We have set up an outgoing mail server using a Gmail account and used the send test e-mail feature to successfully send an e-mail out.
Our problem is with e-mail notifications. We are not getting any at all. We have gone through troubleshooting docs https://confluence.atlassian.com/jirakb/troubleshoot-notifications-in-jira-203394737.html here but have not been able to find the solution.
Here is what we have already tried;
Ensured user profile 'My Changes setting' was set to 'Notify Me'
Ensured Notification scheme was correct and associated with the project
Ensured Project Notification email was set to the same as the outgoing mail server Gmail address
Checked the 'Mail Queue' after making a comment on an issue and saw waiting messages in it for the correct issue. These then disappeared from the queue without error within 60 seconds, indicating that they had been sent.
Enabled DEBUG logging under 'Logging and Profiling' for the outgoing mail server and com.atlassian.jira.service and com.atlassian.jira.service.services.DebugService. We reviewed the log file and saw nothing that indicated error but did see the log of the MailqueueService sending the e-mail.
have used the 'Notifcation Helper' tool and it verified that the user would receive the appropriate notification indicating notifcation scheme and permission are set up ok.
Still the notification e-mail is not received.
There was a point made in the troubleshooting link above
Check that your Base URL is set to a domain / IP which your SMTP server will accept. Example: Google apps accounts must have a matching base url to their Google Apps domain.
However, our Adminsistration> System>General Configuration>Base Url for Jira is something like http://myservername:8880 since it is internal self-hosted. This did not cause a problem with the test mail. Could this be an issue for the notification e-mails?
Any help would be greatly appreciated.
I'm making a user management system for my app, and I need to send users a "forgot my password" email with a token that lets them reset their account password. I signed up for SendGrid through Azure (to get the 25,000 emails per month free, which sounded like a great deal) and wrote some code to use it, but after testing my program a bit I was dismayed to find that only a couple of my emails actually went through.
After going onto the SG control panel, I found that 4 out of the 6 test emails I sent went through, and all of the others were rejected as being spam. I sent an email to mail-tester.com to see what it though my spam score was and it gave me a 4.3/10.
The email in question was a single sentence with a link to the password reset, without any images or other elements. I only sent those 6 emails out, so the volume of my emails definitely wasn't the issue. Still, I'm very puzzled as to why my messages are getting flagged as spam.
Without going to the trouble of making an elaborate authentication setup, are there any basic changes I can make to my system to make it get through to users?
In this case it's most likely because you are sending such a short message, with a link to 'reset your password' from a non-whitelabelled email address (the email address you're sending from cannot be verified against the actual domain), and the link may also be a different URL. It's probably getting pulled up as a potential phishing email.
You can rectify this by white labeling your domain and email links via the SendGrid dashboard, it's easy to do and should improve your deliverability.
Also check out this article from the SendGrid support team about White Labeling.
A question from 2015 which is sadly still relevant today as usage of SendGrid increases.
My organization has blocked all SendGrid mails except for those on the paid tier using fixed IP addresses with resolvable public DNS names (such as sendgrid1.sampledomain.tld) which we then whitelist.
There are now far too many domain impersonation, phishing and other spam mails coming in from SendGrid for us to allow everything from them - roughly 10 000 mails over a seven day period, which is far too many to manually report to SendGrids abuse department.
So my answer would be that switching to the paid tier of SendGrid is the better option if you like a better chance of your mails arriving intact at their destination.
I receive only Spam Mails from Sendgrid.
Goes direct to Spam folder and try to report Sendgrid everywhere I can. Maybe they get blocked by most mail servers and make them think about their policy in "hosting" all these Spammers.
In my case my emails are marked as spam because of the anchor label different to the href being actually called.
And that's because of the 'click tracking' setting of sendgrid.
So, if you have something like
yourdomain.com
sendgrid may replace the href and you end up with something like:
yourdomain.com
The sendgrid page being called tracks the click and then redirects the user to the url you originally set. But this sometimes results in your email being marked as spam.
Try to set 'click tracking' in sendgrid dashboard to off: settings | tracking | click tracking.
details here: https://sendgrid.com/docs/ui/account-and-settings/tracking/
Always start by setting up Domain Authentication, formerly known as domain whitelabel as #MartynDavies says. Found under Settings -> Sender Authentication in the UI. Should look like this:
https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-domain-authentication/
To identify problems have a look at Activity and choose to see deferred, drops, bounces, blocks and spam reports.
https://app.sendgrid.com/email_activity
Under Suppressions you can see details for Blocks and Bounces among others:
https://app.sendgrid.com/suppressions/blocks
https://app.sendgrid.com/suppressions/bounces
There you can see errors like:
550 5.7.1 SPF check failed. em1234.mydomain.com does not declare 11.222.33.44 as a valid sender
If it says Verified but you see errors like this then contact SendGrid support.
One thing that has worked is to upgrade from the Free plan to Essentials or Bronze via the Azure Portal. This made a lot of the emails marked as spam pass through.
I had a similar issue when trying to send a user verification email using SendGrid.
In my case, using a custom domain as the sender identity solved the issue.
Make sure to also verify the domain before using it.
We are trying to send mail on to Gmail account by using send grid api but Gmail has blocked the email which is sent from send grid. Please check the message given below:
550 5.7.1 [167.89.24.147 12] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for more information. kw15si11591084pab.218 - gsmtp
We have checked all header parameter suggested by Send Grid and implemented it in our code. At the same moment, it works fine for other domain like AOL, Rediff etc.
Please suggest how we overcome with this problem as we have huge users on Gmail and we will send our emails to all those users as. Also, we have noticed that the email came after some time from Send Grid.
Many thanks in advance.
The recipient mail server analyzed your message and determined that the content of the message is spammy. My recommendation would be to run your formatted message through a third-party service, www.mail-tester.com , to identify ways to improve the reception of the message. It's also possible that your sending IP address, 167.89.24.147 based on the response message you've included, is listed on a black list. You'll want to scan your sending IP on a site like http://multirbl.valli.org/ and, if you see that your IP is listed anywhere, submit a delisting request with the black list.
SendGrid also has a Spam Checker app - Turning on SendGrid's Spam Checker app can help combat this, as you're able to set a predefined filter and get alerted when your content exceeds the filter that you set.
I have a Liferay 6.1.0ga1 Portal that requires email confirmation from new registered users.
Following my feedback from the Portal users, and testing with misc Email Providers I've noticed:
Users that use a gmail account for their account, have no problem at all
Hotmail users will receive the 'welcome to our portal' and 'Email confirmation' emails, directly into their junk folder
Yahoo users are receiving most of the sent emails (welcome email, reset pasword, etc) normally, but the email confirmation is never received, and cannot be found even in their Spam Folder. The same happens for every request for a new confirmation mail. In a certain case, the Confirmation email arrived a few hours later, but I cannot really reproduce this scenario.
This is becoming a blocker issue because yahoo users can't register to the portal.
Can anyone provide some ideas on what is causing this behavior, and how could I make sure that all users can receive their confirmation emails ?
Edit:
Could it be that certain email providers are using a strict policy, are blocking the Confirmation Email, because it includes an activation email? I've thought of some solutions like
- Creating a register Hook that informs the new users that they could set their account to accept mails from my Portal
- Creating a hook that will use another Email Template for email confirmation, e.g including the confirmation Token and excluding the activation url
You could take a look at this very old question: How do you make sure email you send programmatically is not automatically marked as spam?
So have you tried the mentioned options in the marked answer there?
I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:
Register for an account by filling out a form and submitting it.
Receive an email with a confirmation code link
Click the link to confirm the new account and log in
When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:
A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.
How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.
We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.
TRANSACTIONAL & SYNCHRONOUS
The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.
TRANSACTIONAL & ASYNCHRONOUS
The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.
The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.
NON-TRANSACTIONAL & SYNCHRONOUS
The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout
When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.
NON-TRANSACTIONAL & ASYNCHRONOUS
The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.
What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!
The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.
My 2 cents:
Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.
In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.
What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.
Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.