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', 'user@provider.org'] which would permit custom senders either matching the domain myschool.org or the email user@provider.org—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
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.tplfiles 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.phpAdvanced approach
Another approach which may enable us to preserve this behavior would be to create a configuration option on the
Mailerclass called something like$customSenders—the default would befalse, meaning any custom senders are always ignored and the site default is always used.truewould 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', 'user@provider.org']which would permit custom senders either matching the domainmyschool.orgor the emailuser@provider.org—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