You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically in several places we've used the user taking an action's email as the 'From' sender for triggered emails.
This was done 1) for user friendliness e.g. so a parent would see an advisor as the sender of their invitation or progress note and 2) for deliverability
These days, sender signatures are a much bigger deal in deliverability and what we're doing counts as spoofing which is a big red flag. Our new standard email delivery provider, Postmark, will reject all emails at the API level with 'From' set to unverified senders
Search the codebase for Mailer::send* calls and any *.email.tpl files use {$from = *} or {capture assign=from}* and remove that so that the default site email address is used instead
Another approach which may enable us to preserve this behavior would be to create a configuration option on the Mailer class called something like $customSenders—the default would be false, meaning any custom senders are always ignored and the site default is always used. true would mean the current behavior where a custom sender is used if provided. And then an advanced option would be to set it to an array of strings like ['@myschool.org', '[email protected]'] which would permit custom senders either matching the domain myschool.org or the email [email protected]—this would enable us to set up domain-wide sender verification for a school's domain name and then all staff could still be custom senders
The text was updated successfully, but these errors were encountered:
Historically in several places we've used the user taking an action's email as the 'From' sender for triggered emails.
This was done 1) for user friendliness e.g. so a parent would see an advisor as the sender of their invitation or progress note and 2) for deliverability
These days, sender signatures are a much bigger deal in deliverability and what we're doing counts as spoofing which is a big red flag. Our new standard email delivery provider, Postmark, will reject all emails at the API level with 'From' set to unverified senders
Search the codebase for
Mailer::send*
calls and any*.email.tpl
files use{$from = *}
or{capture assign=from}*
and remove that so that the default site email address is used insteadPlaces to change
php-classes/Emergence/People/InvitationsRequestHandler.php
Advanced approach
Another approach which may enable us to preserve this behavior would be to create a configuration option on the
Mailer
class called something like$customSenders
—the default would befalse
, meaning any custom senders are always ignored and the site default is always used.true
would mean the current behavior where a custom sender is used if provided. And then an advanced option would be to set it to an array of strings like['@myschool.org', '[email protected]']
which would permit custom senders either matching the domainmyschool.org
or the email[email protected]
—this would enable us to set up domain-wide sender verification for a school's domain name and then all staff could still be custom sendersThe text was updated successfully, but these errors were encountered: