[mailop] Absurd Outlook-originating spam from i...@usa.org
I'm curious if anyone else is seeing this trend today. I've gathered and mildly censored some logs around this campaign I'm seeing today: https://clbin.com/DkSDr Getting a bit of it across the fleet but none more than that one server I pulled those logs from. Just some counts from the fleet of "i...@usa.org" strings in the current exim log: tuesday.mxrouting.net: 11 longhorn.mxrouting.net: 0 safari.mxrouting.net: 12 blizzard.mxrouting.net: 16 pixel.mxrouting.net: 32 lucy.mxrouting.net: 0 redbull.mxrouting.net: 2 echo.mxrouting.net: 16 witcher.mxrouting.net: 0 wednesday.mxrouting.net: 0 moose.mxrouting.net: 2 eagle.mxlogin.com: 28 london.mxroute.com: 76 shadow.mxrouting.net: 22 taylor.mxrouting.net: 0 monday.mxrouting.net: 6 sunfire.mxrouting.net: 1159 arrow.mxrouting.net: 18 Lucky for me, it mainly targeted domains that seem to have left our service but left their MX records pointing to our servers (or potentially domains that pointed MX to our servers just to poorly DDOS it with this campaign). But it is an odd campaign indeed, and I haven't seen one quite this bad while simultaneously consistent from Microsoft servers in recent memory. Are others seeing a similar campaign? Mostly just asking to determine if it's targeted. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
On 3/30/23 07:37, Benoit Panizzon via mailop wrote: What would be the best way to address such issues for Office365 customers? Leave it in the DNSBL until Microsoft reaches out to you with a satisfactory explanation of what they have done to address their spam problem or your normal timeout, if any, whichever is shorter. The purpose of DNSBLs is to allow their users to reject mail from known spam sources. You have identified a known spam source and properly listed it. If you get complaints from users of SWINOG, refer them to the source of the spam, which would be Microsoft. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
Am 30.03.23 um 18:11 schrieb Francois Petillon via mailop: On 3/30/23 16:37, Benoit Panizzon via mailop wrote: Unfortunately, this massively affects other Office365 customers. But they complaint because we (operating the SWINOG blacklist) block them, they don't complaint to Microsoft for being the source of the issue and find it hard to address such issues with Microsoft. What would be the best way to address such issues for Office365 customers? ... In other words, there are 15 spamming domains that generated 90% of the mail traffic on this IP a,d Microsoft does nothing while they have had the information for months. But I would also love to hear from anyone that had to deal with the subject. François I try to tackle this by analyzing domains present in mail headers and rejecting mails accordingly. As you've experienced, talking the Office365 customers into leaving their crappy host isn't working, so I will have to accept that a significant part of the traffic from O365 sources is legit, and blocking their IPs is not an option. Of course I would love to see the big providers keep the spam at bay on their egress, but I realize that this wish won't be granted unless there is massive financial incentive to do so. These are profit-oriented corporations after all, ethical behavior doesn't generate income in their market. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
On 2023-03-30 07:37, Benoit Panizzon via mailop wrote: Hi all Received: from mail-vi1eur04on0730.outbound.protection.outlook.com ([IPv6:2a01:111:f400:fe0e::730]:47502) from new...@news-science-travel.com Auth: by a Spamtrap on 2001:4060:dead:beef::1907:2 25 pretending to be an open relay for jodyyw...@blacklist.woody.ch; Mon, 27 Mar 2023 07:22:56 +0200 (CEST) jodyyw...@blacklist.woody.ch is a spamtrap. I can guarantee, that this email address is not being used for any other purposes and has never been subscribed to any newsletters or similar. From the 'username' i more suspect that this was generated and verified 'valid' by some script checking my spamtrap to accept emails to this destination. Such a 'confirmed' spamtrap hit immediately causes the sending IP to get listed in the SWINOG blacklist. I also looked at the email content. It is spam, sent via PHPMailer relaying it's payload via Office365 submission servers. Unfortunately, this massively affects other Office365 customers. But they complaint because we (operating the SWINOG blacklist) block them, they don't complaint to Microsoft for being the source of the issue and find it hard to address such issues with Microsoft. What would be the best way to address such issues for Office365 customers? Mit freundlichen Grüssen -Benoît Panizzon- I think everyone on the defense side shares your frustration, and I guess you can see why they are in the class of 'too big to block'. Of course, they don't care if you block them, only your customers care. Which is WHY we have to resort to content filtering as the main line of defense for gmail/o365 spammers, and a few ESP's. Now, if you could get EVERYONE to block them for a day, or find some other way to hit their pocket books, maybe we could see some relief. Outbound security will never be a priority for them, despite their size. They do have a few good people there, but their hands are either tied, or they are too short staffed. Sad to say, until maybe the FTC steps in and starts fining them, don't expect anything to change. Worst thing, if WE (inbound filtering and threat detection) can identify it, it is SO much easier for them to catch it on egress. It's costing the public millions of dollars in damages, from malware, phishing, and BEC Compromise.. But it is what it is. All we can do is pray is that they implement their GPT technology and copilot on egress content filtering ;) At least with honeypots like yours, you can improve on 'training' As others had said, unfortunately it is a bit of 'us against them', and we do have to work together as a community. Speaking up is the first step.. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
On 3/29/23 05:13, John Levine via mailop wrote: It appears that Cyril - ImprovMX via mailop said: -=-=-=-=-=- -=-=-=-=-=- @John thank you for your input, but I wonder ; If I leave the Unbound default configuration, won't it will use my local resolv.conf file to access the DNS servers? Or does Unbound uses a specific set of DNS servers instead of using the ones recommended by the OS? Unbound is a DNS cache. It queries the authoritative servers for the zones its client ask about to get the answers which it sends along to its clients. Correction: Unbound is a DNS resolver, not a cache ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
Hi all Received: from mail-vi1eur04on0730.outbound.protection.outlook.com ([IPv6:2a01:111:f400:fe0e::730]:47502) from new...@news-science-travel.com Auth: by a Spamtrap on 2001:4060:dead:beef::1907:2 25 pretending to be an open relay for jodyyw...@blacklist.woody.ch; Mon, 27 Mar 2023 07:22:56 +0200 (CEST) jodyyw...@blacklist.woody.ch is a spamtrap. I can guarantee, that this email address is not being used for any other purposes and has never been subscribed to any newsletters or similar. From the 'username' i more suspect that this was generated and verified 'valid' by some script checking my spamtrap to accept emails to this destination. Such a 'confirmed' spamtrap hit immediately causes the sending IP to get listed in the SWINOG blacklist. I also looked at the email content. It is spam, sent via PHPMailer relaying it's payload via Office365 submission servers. Unfortunately, this massively affects other Office365 customers. But they complaint because we (operating the SWINOG blacklist) block them, they don't complaint to Microsoft for being the source of the issue and find it hard to address such issues with Microsoft. What would be the best way to address such issues for Office365 customers? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
Slavko via mailop skrev den 2023-03-30 12:52: Dňa 30. marca 2023 10:11:32 UTC používateľ Benny Pedersen via mailop napísal: Cyril - ImprovMX via mailop skrev den 2023-03-30 09:30: I removed the usage of OpenDNS, and let Spamhaus know about this. I've also enabled qname-minimisation, we'll see if that helps. rbldnsd have no support for qname It will not be problem with unbound default config (no strict enabled), as when it meets NXDOMAIN it will skip other name parts and will try once with full query name. qname-minimization disabled; in my own bind9, until its solved work around is to rbldnsd dump data to bind zone file, and load the zone file directly in bind, but this needs lots of ram, unless one use dlz datastorages, and this slow down latency that solution, not easy to solve ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
Raymond Dijkxhoorn via mailop skrev den 2023-03-30 12:30: Benny, I removed the usage of OpenDNS, and let Spamhaus know about this. I've also enabled qname-minimisation, we'll see if that helps. rbldnsd have no support for qname no one like to solve it Its not even that. +1 Most DNSBL's have multi level listing support. How on earth would your nameserver know about where to cut the lookups off? dbl in same zone where the zone itself miss _dbl ipv4 rbl in a dbl zone where the zone miss _dbl ipv6 rbl in a dbl zone where the zone miss _rbl in the zone it self spamassassin does not care there, or is it spamhaus ? rspamd have atleast more control of this with each test can be defined what data dns have of intrest Eg would it then ask for myhuaweicloud[.]com[.]multi[.]surbl[.]org where it would actually be needed to ask here multi should have _multi somebadcustomer[.]smn[.]cn-north-1[.]myhuaweicloud[.]com[.]multi[.]surbl[.]org The listings itself are wildcarded -when it fits purpose- but definately not all listings/records apply to that. samme miss of _ I dont think it would work when it comes to DNSBL's lookup types. But enlighten me if you feel i am wrong. Happy to rethink... try enable it in bind9 with strict policy, and then see querylog so it only works if spamassassin have datafeeds and tests is done without real dns servers in the middle ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
Dňa 30. marca 2023 10:11:32 UTC používateľ Benny Pedersen via mailop napísal: >Cyril - ImprovMX via mailop skrev den 2023-03-30 09:30: >> I removed the usage of OpenDNS, and let Spamhaus know about this. I've >> also enabled qname-minimisation, we'll see if that helps. > >rbldnsd have no support for qname It will not be problem with unbound default config (no strict enabled), as when it meets NXDOMAIN it will skip other name parts and will try once with full query name. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
Benny, I removed the usage of OpenDNS, and let Spamhaus know about this. I've also enabled qname-minimisation, we'll see if that helps. rbldnsd have no support for qname no one like to solve it Its not even that. Most DNSBL's have multi level listing support. How on earth would your nameserver know about where to cut the lookups off? Eg would it then ask for myhuaweicloud[.]com[.]multi[.]surbl[.]org where it would actually be needed to ask somebadcustomer[.]smn[.]cn-north-1[.]myhuaweicloud[.]com[.]multi[.]surbl[.]org The listings itself are wildcarded -when it fits purpose- but definately not all listings/records apply to that. I dont think it would work when it comes to DNSBL's lookup types. But enlighten me if you feel i am wrong. Happy to rethink... bye, Raymond ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
Cyril - ImprovMX via mailop skrev den 2023-03-30 09:30: I removed the usage of OpenDNS, and let Spamhaus know about this. I've also enabled qname-minimisation, we'll see if that helps. rbldnsd have no support for qname no one like to solve it ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Unbound configuration for DNSBL ?
I removed the usage of OpenDNS, and let Spamhaus know about this. I've also enabled qname-minimisation, we'll see if that helps. Thank you for your help! Best, Cyril Le mer. 29 mars 2023 à 11:13, John Levine a écrit : > It appears that Cyril - ImprovMX via mailop said: > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >@John thank you for your input, but I wonder ; If I leave the Unbound > >default configuration, won't it will use my local resolv.conf file to > >access the DNS servers? Or does Unbound uses a specific set of DNS servers > >instead of using the ones recommended by the OS? > > Unbound is a DNS cache. It queries the authoritative servers for the > zones its client ask about to get the answers which it sends along to > its clients. > > resolv.conf is for application programs. The usual setup is that it > contains 127.0.0.1 to tell applications to query the cache server on the > same host, which in this case is unbound. > > Unbound has its own configuration file but in most cases the defaults > are all you need. > > R's, > John > > > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
