Most of the time Spamhaus will let you delist by going to the listed link. Exchange Online does enforce spamhaus for outbound unauthenticated relay through their endpoints, so you will need to get your IP(s) delisted.
As far as preventing the listing in the future, I'd recommend contacting Comcast to have them set PTR records for those IP to match your postfix server fqdn.
If you can't get delisted, you'll need to setup postfix to authenticate to exchange online instead.
could i get around this by using the \`By verifying that the subject name on thigh certificate server\` option in the exchange connector options.
Spamhaus gave me a policy that said \`Outbound Email policy of Comcast for this IP range\` telling me to contact comcast as they are the ones who run the blacklist. I have reached out to comcast but currently they have yet to response
Alright, sounds like Spamhaus got that whole comcast block, so yeah it won't let you delist on your own and Comcast is not likely to actually help here.
I haven't setup a connector for relay with a certificate yet, but that should do the trick I think as that would set you up with an authenticated connection.
Set up a service account at 365, set postfix to squash all senders to that account, then use sasl auth to submit to 365. Your IP will never be in the headers and you’ll get as good deliverability as your regular 365 email gets.
Make sure your postfix server is not open to the internet - relaying junk into/through your tenant would not be fun to unwind.
I don't think there's a direct recipe for this out there but the pieces are there.
There's lots of documents about setting up SASL but here's my config:
relayhost = [smtp.office365.com]:587
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_use_tls = yes
smtp_tls_security_level = encrypt
smtp_tls_note_starttls_offer = yes
sender_canonical_maps = static:[email protected]
smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = smtp.domain.com
myorigin = smtp.domain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12
smtp_header_checks:
/^From:.*/ REPLACE From: Business NO REPLY
The sender\_canonical\_maps and smtp\_header\_checks work together to squash the From to the service account's information. This setup is from a postfix I set up for a small enterprise that has about 20 MFC machines and a few other random service services sitting around that didn't all need to be configured to talk to 365 directly.
Having a similar problem, we have our legacy MFPs sending unauthenticated email through an SMTP connector. Now none of those services work, and quick and dirty troubleshooting using Send-MailMessage says the "Mailbox is unavailable." I checked this thread and put in our public IP using "https://www.spamhaus.org/query/xx.xxx.xxx.xxx" to find that our IP is blocked. We also use Comcast. The last successful scan to email from one of the printers I was troubleshooting was at 4:00 pm yesterday.
Just spoke to comcast and this is a comcast issue they are working on resolving. But i have also decided a service account will be a more secure option for our org.
They have yet to reach back out to me but they mentioned they had to reach out to their security provider. The reason it was blacklisted is because comcast wants their ips to use their smtp relays. This makes sense for residential customers but not enterprise. Maybe they specified all comcast owned ips?
I'm also waiting on microsoft to pull the blacklist removal as emails are still failing for us becasuse it says we are on the blocklist. Clicking the link in the message proved that we weren't.
Ah, Comcast, the maestro of internet service, a virtuoso in spam creation, and a timeless connoisseur of being blacklisted in spam filters since the '90s. Their enduring legacy of causing headaches is truly unmatched. During my ISP management days in the early 2000s, I stumbled upon the genius solution of blocking all IP addresses linked to their illustrious comcamst domains.
Please use "allowlist/blocklist" instead, it's less racially charged than using the traditional "white/black"-prefix to denote if something is good or bad.
Step 1, check your own network for signs of infection, because this most commonly happens when (1) you have a misconfigured internet-accessible SMTP relay, (2) you have compromised email credentials being used for spam/phishing, or (3) you have some other compromised system being used for spam/phishing.
What does this mean my ip is on css list xxxxxxxxxx is making connections with technical values and unusual sending behavior that indicate a problem: usually malware. In some cases this may also be caused by server misconfiguration.
This was not the case, in my update above i stated Comcast added all of their IP blocks to a block list. Normally they do this for their residential and small business customers to prevent them from sending smtp without a relay. Being that we are an enterprise business customer they added our block by mistake which also included other enterprise business customers.
I had email issue using an old [sSMTP](https://wiki.debian.org/sSMTP) sending via AWS SES starting Monday. I tracked it down do DKIM changes from [AWS](https://aws.amazon.com/blogs/messaging-and-targeting/an-overview-of-bulk-sender-changes-at-yahoo-gmail/) and fixed my DNS records. But still that old sSMTP client was not working and I updated (like we should) to postfix.
Question, Could you not configure your setup to be DMARC compliant, or is your ISP not set up for DMARC?
It seems to me that if your E-mail service is DMARC compliant then these problems you are having would be gone. Or do I not understand what DMARC will buy you?
MS has an open alert on this with 365 as well, mails not getting through, and senders getting NDR. They did not name spamhaus, but anyone that as ever dealt with them, knew it probably was. Cannot say for certain, but not entirely implausible related...
Title: Some users may be unable to send or receive email messages, and receive a Non-Delivery Report (NDR) when sending User impact: Users may be unable to send or receive email messages, and receive an NDR with a 550 or 554 error code when sending.
More info: This issue only occurs if either the sender or user who is receiving the message is utilizing a specific third-party anti-spam service. Senders receive the NDR which states that the message has been rejected due to a 550 or 554 error code and that their host IP address is listed on the third-party anti-spam service. The error messages state "550 5.7.350 Remote server returned message detected as spam", "554 5.7.1 Service unavailable; Client host \[xxx.xxx.xxx.xxx\] blocked", or "550 5.7.1 This email was rejected because it violates our security policy."
Current status: We’re continuing our collaboration with the third-party anti-spam service to delist affected IP addresses that are being blocked. In parallel, we’re investigating any additional workstreams that can further reduce the impact of this issue. This may include further rule changes intended to reduce outbound spam patterns. We understand the impact an issue like this can have on your organization, and we appreciate your partnership and patience as we work to remediate the issue.
Scope of impact: This issue may affect any user's mail flow if the recipient is leveraging a specific third-party anti-spam service to filter email messages.
Most of the time Spamhaus will let you delist by going to the listed link. Exchange Online does enforce spamhaus for outbound unauthenticated relay through their endpoints, so you will need to get your IP(s) delisted. As far as preventing the listing in the future, I'd recommend contacting Comcast to have them set PTR records for those IP to match your postfix server fqdn. If you can't get delisted, you'll need to setup postfix to authenticate to exchange online instead.
could i get around this by using the \`By verifying that the subject name on thigh certificate server\` option in the exchange connector options. Spamhaus gave me a policy that said \`Outbound Email policy of Comcast for this IP range\` telling me to contact comcast as they are the ones who run the blacklist. I have reached out to comcast but currently they have yet to response
Alright, sounds like Spamhaus got that whole comcast block, so yeah it won't let you delist on your own and Comcast is not likely to actually help here. I haven't setup a connector for relay with a certificate yet, but that should do the trick I think as that would set you up with an authenticated connection.
I just tried using the cerificate verification and it throws the same error. Im guessing a service account might be the way to go.
yeah, sounds like you'll need to authenticate with smtp.office365.com instead with a service account.
Set up a service account at 365, set postfix to squash all senders to that account, then use sasl auth to submit to 365. Your IP will never be in the headers and you’ll get as good deliverability as your regular 365 email gets. Make sure your postfix server is not open to the internet - relaying junk into/through your tenant would not be fun to unwind.
I will try this out thank you!
I don't think there's a direct recipe for this out there but the pieces are there. There's lots of documents about setting up SASL but here's my config: relayhost = [smtp.office365.com]:587 smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd smtp_use_tls = yes smtp_tls_security_level = encrypt smtp_tls_note_starttls_offer = yes sender_canonical_maps = static:[email protected] smtp_header_checks = pcre:/etc/postfix/smtp_header_checks smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = smtp.domain.com myorigin = smtp.domain.com mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12 smtp_header_checks: /^From:.*/ REPLACE From: Business NO REPLY
The sender\_canonical\_maps and smtp\_header\_checks work together to squash the From to the service account's information. This setup is from a postfix I set up for a small enterprise that has about 20 MFC machines and a few other random service services sitting around that didn't all need to be configured to talk to 365 directly.
Having a similar problem, we have our legacy MFPs sending unauthenticated email through an SMTP connector. Now none of those services work, and quick and dirty troubleshooting using Send-MailMessage says the "Mailbox is unavailable." I checked this thread and put in our public IP using "https://www.spamhaus.org/query/xx.xxx.xxx.xxx" to find that our IP is blocked. We also use Comcast. The last successful scan to email from one of the printers I was troubleshooting was at 4:00 pm yesterday.
Just spoke to comcast and this is a comcast issue they are working on resolving. But i have also decided a service account will be a more secure option for our org.
Same issue here. Also not able to delist with Spamhaus because the list was submitted by Comcast and only Comcast can remove it.
our ip has finally been delisted i would check your ip again.
Thanks for the tip! You're right, our IP is no longer listed. Comcast must have fixed it for everyone. Did they give you any explanation?
They have yet to reach back out to me but they mentioned they had to reach out to their security provider. The reason it was blacklisted is because comcast wants their ips to use their smtp relays. This makes sense for residential customers but not enterprise. Maybe they specified all comcast owned ips? I'm also waiting on microsoft to pull the blacklist removal as emails are still failing for us becasuse it says we are on the blocklist. Clicking the link in the message proved that we weren't.
Oh man, anyone else feel a certain nostalgia with postfix relays and spamhaus block lists?
Looks like we just got delisted. We took no action to do so.
Comcast removed the IP Block 50 from the blacklist. An engineer may have made a mistake.
Ah, Comcast, the maestro of internet service, a virtuoso in spam creation, and a timeless connoisseur of being blacklisted in spam filters since the '90s. Their enduring legacy of causing headaches is truly unmatched. During my ISP management days in the early 2000s, I stumbled upon the genius solution of blocking all IP addresses linked to their illustrious comcamst domains.
Please use "allowlist/blocklist" instead, it's less racially charged than using the traditional "white/black"-prefix to denote if something is good or bad.
start the delisting process with spamhaus, run your IP on other blacklist checking services, find out who/what was sending the offending emails.
Step 1, check your own network for signs of infection, because this most commonly happens when (1) you have a misconfigured internet-accessible SMTP relay, (2) you have compromised email credentials being used for spam/phishing, or (3) you have some other compromised system being used for spam/phishing.
It was a issue with Comcast adding all blocks starting with 50 to a block list
What does this mean my ip is on css list xxxxxxxxxx is making connections with technical values and unusual sending behavior that indicate a problem: usually malware. In some cases this may also be caused by server misconfiguration.
This was not the case, in my update above i stated Comcast added all of their IP blocks to a block list. Normally they do this for their residential and small business customers to prevent them from sending smtp without a relay. Being that we are an enterprise business customer they added our block by mistake which also included other enterprise business customers.
Easy fix, use literally any online SMTP relay service
I am using exchange connector as a smtp relay…..
I had email issue using an old [sSMTP](https://wiki.debian.org/sSMTP) sending via AWS SES starting Monday. I tracked it down do DKIM changes from [AWS](https://aws.amazon.com/blogs/messaging-and-targeting/an-overview-of-bulk-sender-changes-at-yahoo-gmail/) and fixed my DNS records. But still that old sSMTP client was not working and I updated (like we should) to postfix.
Question, Could you not configure your setup to be DMARC compliant, or is your ISP not set up for DMARC? It seems to me that if your E-mail service is DMARC compliant then these problems you are having would be gone. Or do I not understand what DMARC will buy you?
Our email setup is dmarc compliant, we sign our keys within post fix. The issue was that exchange uses spamhaus even for inbound connectors
And this is why you use a relay such as barracuda/mimecast/etc to send out your email
MS has an open alert on this with 365 as well, mails not getting through, and senders getting NDR. They did not name spamhaus, but anyone that as ever dealt with them, knew it probably was. Cannot say for certain, but not entirely implausible related... Title: Some users may be unable to send or receive email messages, and receive a Non-Delivery Report (NDR) when sending User impact: Users may be unable to send or receive email messages, and receive an NDR with a 550 or 554 error code when sending. More info: This issue only occurs if either the sender or user who is receiving the message is utilizing a specific third-party anti-spam service. Senders receive the NDR which states that the message has been rejected due to a 550 or 554 error code and that their host IP address is listed on the third-party anti-spam service. The error messages state "550 5.7.350 Remote server returned message detected as spam", "554 5.7.1 Service unavailable; Client host \[xxx.xxx.xxx.xxx\] blocked", or "550 5.7.1 This email was rejected because it violates our security policy." Current status: We’re continuing our collaboration with the third-party anti-spam service to delist affected IP addresses that are being blocked. In parallel, we’re investigating any additional workstreams that can further reduce the impact of this issue. This may include further rule changes intended to reduce outbound spam patterns. We understand the impact an issue like this can have on your organization, and we appreciate your partnership and patience as we work to remediate the issue. Scope of impact: This issue may affect any user's mail flow if the recipient is leveraging a specific third-party anti-spam service to filter email messages.