Spam Filtering Known Issues -

On this page:

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?]

See Also

• Network and Email Security Infrastructure Changes FAQ
• Spam Filtering Landing Page
• Email Delivery - Underlying Protocols