1 to 3 of 3
All emails from Intervals are sent from email@example.com on behalf of the user. The mechanism is very similar to gmail, yousendit, and other companies that handle hi volume email. If your organization utilizes SPF (Sender Policy Framework) and the emails from Intervals are not making it through adding mx.myintervals.com to the record should alleviate the problem. For example:
Modify this record:
"v=spf1 a mx ~all"
To include mx.myintervals.com:
"v=spf1 a mx a:mx.myintervals.com ~all"
If you do not use SPF and emails are getting blocked approving firstname.lastname@example.org as an authorized sender and/or whitelisting all email from mx.myintervals.com | 126.96.36.199 may do the trick as well.
I am not getting very far in resolving this problem. The techo from our email provider says the following:
You can be excused for not understanding, since the information does not seem to be correct.
From the logs, the messages are not being sent from email@example.com (as indicated in the attached png).
It may well be that Martin has changed it to send from firstname.lastname@example.org.
You can see this in the SMTP transcript where the mailer (Intervals) is issuing a MAIL FROM: email@example.com.
When a message is sent on behalf of, the envelope sender is typically different to the message sender address.
It is the envelope sender (MAIL FROM) which is important and is causing the problem.
MailEnable has a policy defined where it requires authentication from anyone attempting to send with an e-mail address that is hosted on the server itself. This is done to prevent backscatter spamming and address spoofing.
This is a very standard configuration and is something that probably should not be changed.
A simple way to get around the problem is to change the sending software to behave in the manner that Michael suggested in his 1st of May message... (ie: to have the sender issue a MAIL FROM: firstname.lastname@example.org rather than MAIL FROM: email@example.com)
Perhaps firstname.lastname@example.org is the default setting in the intervals application and it has been changed to send as email@example.com.
The SPF related information mentioned here is not relevant to the problem because MailEnable does not discriminate against SPF by refusing the mail (it will junk mail it should the policy fail).
The email address of the Intervals Administrator is firstname.lastname@example.org. Should I change that or what should I do? This is causing us a lot of trouble at the moment and seems as if it should be simple but I do not know how to correct the issue even though both Intervals and our email provider are trying to help. I just don't understand what I need to do inside Intervals to sort this out.
Your help would be much appreciated.
The reason we provide the Sender and the From headers is to be consistent with DomainKeys (DKIM) Ideally, email providers would use DomainKeys Identified Email authentication to verify the DNS domain of the email Sender header and allow authenticated emails to bypass spam filters. Intervals signs all of it's emails using DKIM that email servers can use the DomainKey-Signature and DKIM-Signature headers to verify the authenticity of the email.
In addition to supporting DKIM, our emails are formatted using the same Sender/From header combination as the likes of gmail.com and yousendit.com, both of whom regularly send email on behalf of other users.
However, if an email provider has decided to put in place indiscriminate spam filtering without verifying the Sender field via DKIM, there is very little we can do about it at present.
There are two options available that may help.
The first option is to petition the email provider to whitelist the IP for the intervals sending domain. This is 188.8.131.52
The second option is for Intervals to add a setting that allows customers to change their email settings so that the From header is using the myintervals.com domain instead of the customer's domain. This is something we are considering in the future.
In the meanwhile, we'll get in touch with you and MailEnable to make sure we've covered all of our bases and that there isn't something we are missing.
1 to 3 of 3
Comments are closed.
For more Intervals help documentation, please visit help.myintervals.com