New order emails and enquiry form emails, both ending in admin's spam/junk folder. I am not able to rectify it. Using 'mail' configuration instead of 'smtp' in the console. Have put '-F' in front of mail parameters. Tried using the port '587', '465' for for smtp.office365.com. Need help!
For those running into this issue with OpenCart here are some things you should verify.
Ensure your email address in System->Store->Email matches the email used in System->Mail->SMTP Username
In System->Mail->SMTP Hostname you may need to add the prefix "ssl://" or "tsl://" before your mail.servername.com this is not very clear and easy to miss if you're not sure which one to use, try ssl:// first then tsl:// and send yourself a test email with the contact form.
If using Cpanel, ensure there is an SPF record for your domain. This is found in Cpanel->Email->Email Deliverability
To test if emails are actually working the best way is to login into a test account and send a "Contact Us" email. If the page goes blank after submission, there is likely an issue with settings.
I have found using the OpenCart Default "Mail" setting will always result in emails being marked as spam, so you'll need to get in there and set them up with SMTP.
Related
I'm setting up a MediaWiki page. I go to Preferences after I have logged in with my admin account. I try to send a confirmation email at my email address. I don't receive anything.
I'm the owner of all files and I have rwx rights. LocalSettings.php: $wgEmailAuthentication = true; . But $wgEmergencyContact and $wgPasswordSender have something like "apache#Œinvalid (it contains some invalid characters and literally the word invalid). I have changed them to myusername#domain and it still doesn't send a confirmation email. Maybe I'm putting the domain in wrong format? Does the problem have to do with LocalSettings or is it something else?
and welcome to stackoverflow
what about this setting : Manual:$wgSMTP
Is it setup ?
PS: feel free to follow mediawiki tag, many things to learn through other's questions
I'd like to know if the following is actually possible:
A mailto link that does not contain an email address, but somehow auto populates the TO: field with the email of the original sender.
For example:
"a href="mailto:ORIGINALSENDER?subject=UNSUBSCRIBE&body=I would like to unsubscribe from future emails">Click here to send an unsubscribe email /a"
Is this possible without having to specify an email address in the link itself? Is there a class or function i can call to autopopulate the To: field?
The reason i ask is we send out curated email templates to individual customers and they are sent via a specific system. This system does not have an unsubscribe function, unfortunately. I am not able to use or suggest a system that does as i am but a lowly cog in the corporate machine.
In a word, no, not dynamically in an email that I'm aware of. Are you sending from the same email address each time? Can you set up an additional email address to handle unsubscribes and just have that hardcoded? (i.e. unsubscribe#yourdomain.com and have that monitored)
If you're using different email addresses, then consider replacing 'click here to unsubscribe' with something to the effect of 'to unsubscribe, reply to this email with unsubscribe in the subject line'
Lastly, making a recommendation and giving a good argument for using a system that better suits your requirements is a first step towards being more than a lowly cog in the corporate machine :)
I have restricted the account creation to only bureaucrats. That is, only bureaucrats can create accounts for other users.
A confirmation email is sent to the newly created user on successful account creation in MediaWiki. But, would like to know where can i change the content of Confirmation Email template that i receive in MediaWiki.
Where can i find the various email templates used in MediaWiki?
For eg: Content of Confirmation Email upon successful account creation is as below.
Someone, probably you, from IP address ::1,has changed the email
address of the account "Admin" to this address on admin's Wiki!.
To confirm that this account really does belong to you and reactivate
email features on admin's Wiki!, open this link in your browser:
I would like to change the above content but couldn't find where these email contents are stored or from where it is invoked.
Any help is appreciated.
The email templates are stored as normal system messages, in the MediaWiki namespace, e.g. MediaWiki:Notificationemail_body_changed.
You can filter out all relevant system messages like this: Special:AllMessages&prefix=Notificationemail
Currently, there are four:
MediaWiki:notificationemail_body_changed
MediaWiki:notificationemail_body_removed
MediaWiki:notificationemail_subject_changed
MediaWiki:notificationemail_subject_removed
Those pages will give you the message in your wiki's default language. To change a specific language (that a user might have chosen), use MediaWiki:notificationemail_subject_removed/ar (Arabic), MediaWiki:notificationemail_subject_removed/en (English), etc
#leo's answer is correct for messages sent regarding email authentication.
All other email messages as related to changes in pages, etc., are stored in system messages that start with enotif_, and you can see them all using this filter:
Special:AllMessages&prefix=enotif_.
The messages for vanilla* MediaWiki are:
enotif_impersonal_salutation
enotif_subject_deleted
enotif_subject_created
enotif_subject_moved
enotif_subject_restored
enotif_subject_changed
enotif_body_intro_deleted
enotif_body_intro_created
enotif_body_intro_moved
enotif_body_intro_restored
enotif_body_intro_changed
enotif_lastvisited
enotif_lastdiff
enotif_anon_editor
enotif_body
And you can see them all using this filter:
Special:AllMessages&prefix=enotif_
* People using extension:Echo have a few other messages to change.
I'm on JIRA 4.1.2
When creating notifications, I'd like to notify a distribution group on our Exchange server, rather than create a JIRA user group. This is to avoid having to constantly update the group membership to reflect the distribution list as people move in and out of the list.
I can use the email address "distro#domain.com" successfully in my notification schemes as a Single Email Address, and everyone on the list receives emails as expected, but the emails are plain text, when I would prefer HTML.
Any individual user can update their email preferences, but I can't figure out how to do this for an email address that doesn't correspond to a user on the system. Any ideas on how to accomplish that?
EDIT
Now I'm even more confused. I found my way to the User Default Settings page, and the default for emails is listed as HTML, yet for the list I'm sending to, it's coming through as plain text.
We use Google Apps' account to send site-generated mail from support#oursite.com. It was fine until some point (between April and June) the settings got changed and now when they click "Reply" they see support#oursite.com instead of user's email.
in April's letters both Reply-To and To headers are filled out with user's email;
in June's ones, Reply-To contains user's email but To header contains support#oursite.com.
In all cases FROM headers contain support#oursite.com; we try to put user's email into it but (supposedly) Google SMTP replaces it to support#oursite.com somehow.
The question is:
has anyone else encountered such a problem? (yes, I've searched, not the same cases found)
what solution did you find?
UPD: the behavior described above is for Gmail (both free and GApps) web client only. In any other client (e.g., Gmail for Android/Apple, etc.) hitting "Reply" results in the correct email in the "To" field.
I believe GMail has been doing this for a while - I'm surprised that this started happening to you just recently.
However, there may be a solution. See http://lifehacker.com/111166/how-to-use-gmail-as-your-smtp-server and read 'Update 3' at the bottom of the page.
Google Enterprise support says the following on this subject :
If the From address is your own account (either your primary or an
alias custom from) the 'Reply-to' address is changed to the To
address. This is implemented for replying to sent messages. If you
reply to a message you just sent, you are, in effect, sending another
message to all the To addresses. If you change the From address to a
non-sending address (not the primary and not an alias custom from) and
the reply-to should begin to work as expected without any further
problems.