Spam Filtering Known Issues -
Redirection Notice This page should redirect to Spam Filtering Known Issues. |
On this page:
- MIT Email Forwarding
- Forwarded messages are being flagged as spam by external providers
- O365 "Spam Notice" emails may be flagged as spam by external providers
- Alum.mit.edu Email Forwarding
- Messages sent to alum.mit.edu are getting high spam scores
- Resolved: Alum.mit.edu users cannot configure block/allow lists or view their quarantine on the web
- Sending Mail
- Valid bulk email messages from MIT senders aren't being received by recipients
- "Too many hops" bounce error
- Resolved: Subdomains of mit.edu are not able to send mail
- Informational: Outgoing.mit.edu no longer accepts unqualified addresses (eg., "ops-help")
- Informational: Any strings added after the Kerb (i.e. kerb+ string@mit.edu) are now bouncing
- Email Lists
- Some string entries to Moira lists are not receiving messages from the lists
- Messages sent to some hidden Moira lists bounce
- Resolved: Messages sent to Mailman lists bounce due to an an invalid x.500 address
- Quarantine and Spam Notices
- The "released to" field never populates
- Informational: Messages cannot be deleted from the quarantine
- Updated: Messages deleted from quarantine are no longer accessible to other recipients of email lists
- Resolved: Released messages aren't showing up in my inbox
- Resolved: Some quarantined messages expired before 30 days
- Informational: I'm missing a "Spam Notice" email message. Can it be resent?
- Block/Allow Lists
- Resolved: The Allow/Block list stops working if you disable "Automatically filter junk e-mail"
- Resolved: User's Allow/Block list stopped working some time in December 2018
- See Also
MIT Email Forwarding
Forwarded messages are being flagged as spam by external providers
Users Affected: Users who forward their MIT email to an external provider
Behavior: Valid messages are being incorrectly identified as spam and quarantined, or not received.
Status: High spam scores are caused by the way MIT's email infrastructure handles email forwarding. Microsoft's on-premises Exchange email product has a known issue resulting in invalidating DKIM signatures during the forwarding process. Changes have been made to O365's Exchange implementation to address this issue and avoid disturbing DKIM signatures. We have identified an additional solution, and are actively working on testing and implementation planning. For more information, see: Email Delivery - Underlying Protocols
Workaround: Until additional changes are implemented, be aware that once mail leaves the MIT servers, we have no way of knowing if it was successfully delivered, nor do we have any way of determining what happened to a message that was not delivered. Ensure the address to which you are forwarding is an active email account, not another forwarding service. Routing mail through multiple forwarding services is known to decrease likelihood of successful delivery. If you suspect you are not receiving all of your mail, you may prefer to:
- Turn off email forwarding until we have confirmed that a solution is in place.
- Split your email (mail goes to your MIT inbox and your external provider) so any messages 'lost' can be recovered from Outlook Web Access.
O365 "Spam Notice" emails may be flagged as spam by external providers
Users Affected: Users who forward or split their mail to external email providers
Behavior: External email providers route spam quarantine notices to spam and/or adds a warning about the site.
Status: This is due to Microsoft not signing their quarantine notifications. The lack of a DKIM signature on the notification email causes the message to fail DMARC upon delivery to external email providers. External email providers may treat emails that fail DMARC differently, and many providers will place the inbound email in their own spam quarantine space for review. We have opened a support ticket with Microsoft to request that they sign their quarantine messages (DKIM signature). For more information, see: Email Delivery - Underlying Protocols
Workaround: Regularly check your spam quarantine by visiting https://protection.office.com and any spam filters the email provider you're forwarding your email to uses.
Alum.mit.edu Email Forwarding
Messages sent to alum.mit.edu are getting high spam scores
Users Affected: Users of alum.mit.edu email forwarding service
Behavior: Valid messages sent to users of the alum.mit.edu email forwarding service are falsely identified as spam due to high spam scores.
Status: Changes were applied the evening of 1/2/2019 to reduce the spam scores and improve email forwarding behavior. We are actively gathering information as to the effectiveness of these changes at this time. For updates on the status of this forwarding service from the MIT Alumni Association, see: Changes in Email Forwarding For Life and Spam Filtering
Workaround: Regularly check your spam quarantine messages and any spam filters the email provider you're forwarding your email to uses. Contact help@alum.mit.edu for assistance.
Resolved: Alum.mit.edu users cannot configure block/allow lists or view their quarantine on the web
Users Affected: Users of alum.mit.edu email forwarding service
Behavior: There was no way to configure block/allow lists or view the quarantine directly via a web interface.
Status: Resolved with the rollout of the protection.office.com interface.
Workaround: See: Changes in Email Forwarding For Life and Spam Filtering
Sending Mail
Valid bulk email messages from MIT senders aren't being received by recipients
Users Affected: MIT email senders who use third-party services (such as MailChimp, MailJet, Constant Contact, and IBM Watson) to send bulk messages
Behavior: Microsoft’s Office 365 anti-spam infrastructure has identified some third-party email marketing tools used by the MIT community as potential “bad senders”, causing some bulk messages from these services to the MIT community to be quarantined.
Status: We are actively working with members of the community who use bulk mailers to ensure email delivery for ongoing and future email campaigns.
Workaround: If you are impacted by this, please report the issue to servicedesk@mit.edu to assist our investigation and receive status updates on this issue.
"Too many hops" bounce error
Users Affected: Users who send mail to mailman lists that contain other mailman lists.
Behavior: The mail bounces with a "Too many hops" error. When you release mailman list messages from moderation, it causes them to go through the mail servers additional times increasing the hop count additional times for each level of nesting (Mailman lists within Mailman lists).
Status: We are aware of the issue and are planning a fix to improve the behavior.
Workaround: There is no current solution for existing nested Mailman lists, nor is this a best practice. If you are impacted by this, please report the issue to servicedesk@mit.edu to assist our investigation and receive assistance with your email list architecture to avoid this issue.
Resolved: Subdomains of mit.edu are not able to send mail
Users Affected: Users who send mail from an mit subdomain (e.g., csail.mit.edu, space.mit.edu, etc.)
Behavior: Unable to send mail
Status: IS&T has identified a solution
Workaround: Must delist at https://sender.office.com or contact the Service Desk for assistance doing so.
Informational: Outgoing.mit.edu no longer accepts unqualified addresses (eg., "ops-help")
Users Affected: Power users
Behavior: outgoing.mit.edu used to accept unqualified addresses (eg., "ops-help") and default them to "@mit.edu". This no longer works.
Status: This functionality is no longer available.
Workaround: Do not use unqualified addresses.
Informational: Any strings added after the Kerb (i.e. kerb+string@mit.edu) are now bouncing
Users Affected: MIT email users
Behavior: Email sent to users in the form of username+foo@mit.edu is bouncing.
Status: IS&T has confirmed this is not supported by Microsoft at this time.
Workaround: None at this time to make the + addresses work. Users can request Moira lists to obtain additional addresses for future use.
Email Lists
Some string entries to Moira lists are not receiving messages from the lists
Users Affected: Non-MIT e-mail address members of Moira lists (@gmail.com, @media.mit.edu, etc.) and RT users (xxx@help.mit.edu)
Behavior: These users are not receiving mail sent to those Moira lists.
Status: IS&T has resolved it for known instances. Any additional instances found are being handled on a case-by-case basis. We do not yet know the root cause of this issue and are working with Microsoft to determine it.
Workaround: If you are impacted by this, please report the issue to servicedesk@mit.edu to assist our investigation and receive status updates on this issue.
Messages sent to some hidden Moira lists bounce
Users Affected: Members and administrators of hidden Moira lists.
Behavior: Messages sent to some hidden Moira lists bounce.
Status: We are actively gathering information on this issue and have been able to resolve reported instances.
Workaround: If you are impacted by this, please report the issue to servicedesk@mit.edu to assist our investigation and receive status updates on this issue.
Resolved: Messages sent to Mailman lists bounce due to an an invalid x.500 address
Users Affected: Users sending mail to Mailman lists.
Behavior: Messages sent to Mailman lists bounce due to an invalid x.500 address.
Status: Resolved
Workaround: This has been identified as a caching issue that was caused by the initial deployment of Mailman list aliases. Exchange deleted and recreated lists in exchange instead of modifying them. Unfortunately it maintained a history of this and appended characters to the new X.500 address to make them unique - which also makes them bounce.
We identified and resolved this issue on the server side. Some clients who sent to the lists before the issue was corrected downloaded the incorrect data to their offline address book and stored it in their autocomplete cache. Purging your address auto-complete list cache will remove the erroneous aliases that are causing messages to bounce.
Quarantine and Spam Notices
The "released to" field never populates
Users Affected: MIT email users
Behavior: When you release a message, the "released to" filed in the web interface never populates with any content. The message still releases to your inbox.
Status: Reporting as a bug to Microsoft.
Workaround: None at this time.
Informational: Messages cannot be deleted from the quarantine
Users Affected: MIT email users
Behavior: There is no longer an option to delete unwanted messages from the quarantine. They remain in the quarantine for the full 30 days before being automatically removed.
Status: The delete from quarantine functionality is no longer available. IS&T is investigating this change in behavior.
Workaround: None at this time.
Updated: Messages deleted from quarantine are no longer accessible to other recipients of email lists
Users Affected: Email list users
Behavior: When one user deletes a quarantined message sent to a list or group of users, the quarantined message will be deleted from the spam quarantine of everyone on the list.
Status: The behavior is no longer possible. Messages can no longer be deleted from the quarantine (see above).
Workaround: not applicable
Resolved: Released messages aren't showing up in my inbox
Users Affected: MIT email users
Behavior: Clicking the 'Release message' link in the quarantine summary e-mail or web interface does not seem to cause the message to be delivered to my inbox.
Status: Resolved.
Workaround: Messages may take a few minutes to work their way through the system to appear in your inbox after release. It also takes some time for messages to disappear from the quarantine web interface once they have been released. This is a caching issue, not a sign your message hasn't been released.
If you forward your email to another provider, be sure to check that provider's spam filtering system as it may have identified the message as spam upon arrival by their spam filtering system.
Resolved: Some quarantined messages expired before 30 days
Users Affected: MIT email users
Behavior: Some quarantined messages expired before the 30 days they were supposed to stay around.
Status: When the Spam Quarantine service was launched the setting was initially 15 days. That was extended to 30 days on December 18, 2019 for all future messages.
Workaround: None needed. Enough time has passed all current quarantined messages and all future messages will expire after the full 30 days.
Informational: I'm missing a "Spam Notice" email message. Can it be resent?
Users Affected: MIT and alum.mit.edu email forwarding for life email users
Behavior: User does not receive or no longer has a "Spam Notice" message.
Status: IS&T has submitted a feature request to Microsoft.
Workaround: While, we cannot resend the spam notice itself, we can release the contents of them to you.
Quarantine notices are only sent on days there is spam to report. You will not receive a notice on days no spam is quarantined.
Block/Allow Lists
Resolved: The Allow/Block list stops working if you disable "Automatically filter junk e-mail"
Users Affected: MIT email users
Behavior: If you disable "Automatically filter junk e-mail", your personal settings for filtering don't sync, and your Allow/Block lists stop working.
Status: Expected behavior. This is the setting that determines if your personal settings are used to customize spam filtering or not.
Workaround: Select "Automatically filter junk e-mail" in your settings to [enable your personal "block/allow" lists.]
Resolved: User's Allow/Block list stopped working some time in December 2018
Users Affected: MIT email users block/allow lists set in the old Brightmail Spam Quarantine system
Behavior: The user's block/allow lists from the Brightmail Spam Quarantine stopped working in December 2018 around when MIT migrated to the new O365 Spam filtering.
Status: Expected behavior. Block/allow settings were unable to be migrated from the Brightmail Spam Quarantine system to the new O365 Spam filtering system.
Workaround: There is no migration path for these settings. Users need to configure their allow/block settings for O365 Spam Filtering from scratch. [How do I add an email address to my "blocked senders" or "allowed senders" list with O365 Spam Filtering?]