Re: [mailop] DKIM: Who's using the x tag?
I ran a check across our spamtraps. Approximately 4% of the messages we received yesterday had the x= field. Senders that included it were Gmail, Microsoft, Apple, Mailchimp, Mailgun, Splio, dotdigital, HubSpot, Mailjet, Selligent, Campaigner, GetResponse, Salesmanago, TurboSMTP, Postmark, Aweber, Sendpulse, SocketLabs, Mailup, and a few smaller ESPs. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM: Who's using the x tag?
> If you've got any evidence of x= in the wild that you care to share, > thank you kindly in advance! DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=customer.domain; s=k3; t=1728563812; x=1728824312; i=news@customer.domain; bh=x; h=Subject:From:Reply-To:To:Date:Message-ID:X-MC-User:Feedback-ID: List-ID:List-Unsubscribe:List-Unsubscribe-Post:Content-Type: MIME-Version:CC:Date:Subject:From; b=x Mailchimp does this. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google Spam
On Mon, Sep 30, 2024 at 09:18:37AM -0400, Scott Q. via mailop wrote: > Anyone else getting spammed to bits by usepersistiq.com ? Apparently so seeing as there is a big thread on Reddit on it. I hesitate to even try to answer your other question. Best regards, Fellow Spam Recipient -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ask for commercial smtp gateway
[No private replies required, list only is fine.] > It [UCEProtect, ed.] is a really good indicator how many abusive > IPv4 systems are in an AS. I am questioning their methods, their data sources, and their evaluations. It is guaranteed that they don't have visibility into everything (I am saying this as somebody with a much less public report on similar stuff, but recognizing the shortcomings of *our* data sources in the same way), it is likely that their visibility is heavily biased, and it is clear that their methods indicate that they don't even understand the concept of end-user networks (PBL anyone?) but just lump everything together. Their green listings might indicate that they've just never seen anything from somewhere (the absence of evidence is not evidence of absence), and their red listings might indicate that they've once observed a hijacked home user's computer from somewhere, it's not even there any more (because after a reboot it went from A.B.C.D to E.F.G.H), and are now going for the /16 when they see the next one. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ask for commercial smtp gateway
> Get a Linux machine in an AS that doesn't host abusers (check the AS > using http://www.uceprotect.net/de/rblcheck.php) and install your MTA there. I might not advocate for UCEProtect as a source of truth for anything. But that's just my €0.02. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Super dumb gmail request ...
> The flaw for me is that TOTP involves using phone apps I don't know > the provenance of, https://github.com/freeotp is much lighterweight than Microsoft or Google Authenticator anyway. > that back up the data in a format I don't know > to my "Google Drive", which is the most protected place I'd choose. I am under the impression that FreeOTP does not back up data. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Super dumb gmail request ...
> There's life at Google. Just pay for GSuite. Is this the generic advice that all Android device users should take in order to ensure they will be able to continue to use the Google account which is essentially mandatory to have in order to use said device? If so, how come it is not suggested when you buy a device, or when you go through initial setup and plug in an account? -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Anyone from sbcglobal.net
> 550 5.7.1 Connections not accepted from servers without a valid sender > domain.flph840 Fix reverse DNS for 66.171.0.45 $ host 66.171.0.45 45.0.171.66.in-addr.arpa domain name pointer outbound.eastex.net. 45.0.171.66.in-addr.arpa domain name pointer eastex.net. It should have exactly one. https://datatracker.ietf.org/doc/html/rfc1912#2.1 I wouldn't reject messages based on that, but there you have it. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailserver accepts ssl/tls only
On Thu, Jul 18, 2024 at 08:36:09PM +0800, Jeff Pang via mailop wrote: > Can I setup mailserver to accept messages via sdl/tls only from > other MTA? How to disable peer MTA send me plaintext mail? Qiyong, is that you? -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Strange sending issues with GMX
> routed through a separate gateway. Unfortunately, this gateway's IP > address is heavily compromised and listed on the Spamhaus blacklist. On specific request from GMX. > Isn't GMX's approach to spam prevention for non-European regions > overly simplistic and potentially harmful to legitimate users? That is a question you have to ask them. > Does anyone else think that GMX's anti-spam measures for outgoing > emails from outside Europe are a bit too blunt and potentially > counterproductive? "A) The email message(s) you are sending has been erroneously classified as spam by GMX. As a result your email was delivered by GMX mail systems that exclusively delivers emails that have been internally classified by GMX as spam." It points you at https://postmaster.gmx.net/en/case?c=uar Have you done this? Best, -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Domains discrimination
> I agree that overall, the new TLD program has been a failure and makes > a mockery of ICANN's claim to operate as a public charity in the > interests of the public. The second round is just around the corner. I guess you're thrilled. I am. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] how to stop this spam
On Thu, Jun 20, 2024 at 05:33:47PM +0800, Jeff Peng via mailop wrote: > BTW, What’s the good way to block messages based on languages? Analyzing messages for language content first, then being able to decide based on results. There are multiple libraries for multiple programming languages that will do this. See for example https://medium.com/@monigrancharov/text-language-detection-with-python-beb49d9667b3 > > On 2024-06-20 15:49, Stuart Henderson via mailop wrote: > >On 2024/06/20 10:13, Jeff Pang via mailop wrote: > >>Hello > >> > >>Recently i got a lot of spams like this one: > >>https://cloud.hostcache.com/spam.eml > >> > >>They have two features: > >>1. arabic language > >>2. from google groups (though i never joined those groups) > > > >I've reported a bunch of these over the years, never any response. > >google don't seem to care. > > > >>how can i stop them effectively? (block arabic and google groups?) > > > >Yes that's probably the way. Or just block all of google groups if you > >don't need it. > > > >___ > >mailop mailing list > >mailop@mailop.org > >https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to ensure ownership from a Microsoft email?
> PS I’m definitely on the hate side today, having discovered that to actually > _use_ MS’s implementation of DKIM, I may well have to shell out a 6 figure > GBP sum. If anyone can demonstrate to me that outbound DKIM signing in > Exchange Online Protection is possible, and working, without any additional > Defender for M365 licenses then the beers are on me. So far all my research > points to it being a paid-for feature! https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide ? Best, -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI
> Other than that, I'm with you, it is a fraction of a percent of signed > mail, not common at all. I'm with Dr Levine; I just looked at all the stuff our spamtrap system has received in May so far (n~=8M). The exact number I came up with is 0.6%. Also, the percentage of signed mail out of all mail seen is ~60%. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Strange Behavior from Microsoft IP Address
> To give you a bit of context, we operate as an ESP, facilitating our > customers in sending out newsletters. If you want anybody to have an opinion on this stuff why don't you identify yourself, the domain names and the IPs involved. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google Mail rejects forwarded email despite `~all` in SPF
> The SPF of molgen.mpg.de has `~all` (soft fail): > > $ dig txt molgen.mpg.de +short > "v=spf1 ip4:141.14.0.0/16 ~all" But this is irrelevant. The envelope-from of a forwarded message is the original one - if you do not deliberately rewrite it - and in such a case, the SPF that is evaluated at the forwarding destination should be that of the original sender, nothing to do with yours. As for DKIM, if the forwarded message did not contain a DKIM signature to begin with, then your options would be 1) continuing to occasionally forward mail that is not DKIM signed at all or 2) figuring out a way to sign what is essentially random email from random third parties using your reputation, which may not be what you wanted either. > We do not want to set up DKIM due to the increased message size, Now there's a straw man if I ever saw any. If you're worrying about adding 5-15 lines to messages that frequently contain hundreds, thousands of lines, you have the luxury of having problems that nobody else has. > and complexity of key handling. Is there an alternative? You can do it. A man+dog shop (looking at the mirror) can do it, so a university department with people on the IT payroll can do it. (But you may still not want to sign mail sent by random folks on the Internet with your domain.) -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] how does mailhash.josephlist.net work?
> What I found out is that the email content is searched for email > addresses and if some hash of that email address matches, the email is > rejected. It's the full email address. Only the domain part does not > trigger the issue. Yeah. To my knowledge, the idea of hash blocklists was first publicly proposed in M3AAWG 41, October 2017. https://msbl.org/ebl.html has the details. Ever since, Spamhaus HBL has come up (to address not only email addresses but also files and cryptocurrency wallets) and it seems that even more people have taken up the mantle now. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.
On Fri, Mar 15, 2024 at 08:11:42AM +, Alexandre Dangreau via mailop wrote: > Hello, > > In fact, if you need a /64 IPv6 range you probably use the wrong service. For > VPS and Public Cloud instances (PCI) the IPv6 range is shared with all the > VM, so each VM (VPS or PCI) have one single IPv4 (/32) and one single IPv6 > (/128). > > Only baremetal have a dedicated /64 IPv6 range. The support team could help > you to find a server corresponding to your needs. Let me point out the obvious: that is a suicidal approach. You're not exactly running out of /64's. There are altogether 18 446 744 073 709 551 616 of them in the address space, not all of which are yours, of course, but even if you only have a /32 you still have 4 billion, and it's safe to say you don't have 4 billion customers. (I will go deeper into this at the end of this message.) Spamhaus released their IPv6 policy already in 2011: https://www.spamhaus.org/resource-hub/dnsbl/spamhaus-releases-ipv6-blocklists-strategy/ They refer to RFC 6177: https://datatracker.ietf.org/doc/html/rfc6177 I am nobody, but I wholeheartedly wish for OVH to reconsider its approach and to always assign at least a /64 to a customer, no matter whether they're buying VPS or bare metal. (It should be per customer, not per unit of hardware, as well.) You have over 17 billion /64's in your four /32's. Restricting all VPS customers to a single /64 is something that could only be caused by a fundamental, should I say utter, misunderstanding of IPv6. Once again, please reconsider. $ whois -h whois.radb.net -- '-i origin AS16276' | grep route6: | grep /32 | sort -u route6: 2001:41d0::/32 route6: 2402:1f00::/32 route6: 2604:2dc0::/32 route6: 2607:5300::/32 Best, -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?
> If the message is "your book is due in five days", it doesn't seem > reasonable that legitimate addresses are going to belong to > discontinued domains repurposed as spamtraps within that time > period. Certainly not a lot of them. We religiously observe the M3AAWG BCP for maintaining spamtraps and condition all new recycled domains with a 12-month period of responding with 550 5.1.1 No such user. Doesn't stop them. Not talking about this specific sender; _anyone._ -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
> ... but that does mean trusting 8.8.8.8 with your private secret. From Spamhaus documentation: "access to public mirrors requires the use of a non-public, non-shared DNS resolver (therefore excluding services like Google Public DNS), while DQS can use any DNS channel" https://docs.spamhaus.com/datasets/docs/source/70-access-methods/data-query-service/010-dqs-differences.html Now if that was a problem and this private secret got out because of a query that was just done through Google a few minutes ago, we'd find out in no time at all because Spamhaus would shut this private secret down. I also expect we wouldn't have been the first ones to explore this "problem" if it was one. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
> Otherwise you need to stop using Spamhaus -- even if you sign-up, > perhaps because of the query volume, you still must query them > directly not via a public resolver. This is not true. One of the main points of DQS is that the DNS service you use no longer matters. They don't need to block the server - if you misused the DQS (whatever the definition of misuse might be), they can simply block *you* from accessing the data, not *all users of the same DNS infrastructure*. [atossava@x ~]$ nslookup > server 8.8.8.8 Default server: 8.8.8.8 Address: 8.8.8.8#53 > 2.0.0.127.zen.spamhaus.org Server: 8.8.8.8 Address:8.8.8.8#53 ** server can't find 2.0.0.127.zen.spamhaus.org: NXDOMAIN > 2.0.0.127.[DQS zone].zen.dq.spamhaus.net Server: 8.8.8.8 Address:8.8.8.8#53 Non-authoritative answer: Name: 2.0.0.127.[DQS zone].zen.dq.spamhaus.net Address: 127.0.0.2 Name: 2.0.0.127.[DQS zone].zen.dq.spamhaus.net Address: 127.0.0.10 Name: 2.0.0.127.[DQS zone].zen.dq.spamhaus.net Address: 127.0.0.4 -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
> Hmm. How do I check that? > Running nslookup defaults to my local resolver instance. If it happens silently at the ISP's end, you can't check it - except indirectly. What are the return codes that you get from your Spamhaus Zen queries? -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Admin contact for Protonmail
On Wed, Jan 31, 2024 at 02:03:33PM +, Tarun Singh via mailop wrote: > Hello Folks, > > Is there anyone from Protonmail on this distro? Can you please reach out to > me offline? Abuse and postmaster appear to work. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
On Fri, Jan 19, 2024 at 03:31:19PM +0100, hg user wrote: > Ok sorry not "most" but "some may"... > > My checkpoint rep said that they get their reputation lists from other > companies... is it wrong ? It's possible that Check Point are just an aggregator and don't actually have first-hand data. But I don't think of Check Point when somebody says DNSBL, which may be my own failure :-D As far as I've been able to tell, Spamhaus, SURBL, Abusix, SpamCop, SORBS, UCEProtect, PSBL at least all have their own data, I would even go so far as to guess "exclusively". -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> Since most RBLs exchange data, Source? -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> > https://www.talosintelligence.com/reputation_center/lookup?search=66.175.222.108 > > > Thanks for this; I wasn't familiar with Talos Intelligence. Do they publish > a blocklist? Paying users only. Paying users include the Finnish government's internal outsourcing center (Valtori) and Telia (our largest telco). Their error messages are shit, you don't even know where to look: /var/log/old/maillog-20220410.gz Apr 7 12:47:44 mail postfix/smtp[11896]: 52E23100EBBCA: to=, relay=mail.cm.telia.net[80.74.207.118]:25, delay=0.54, delays=0.09/0/0.14/0.31, dsn=5.0.0, status=bounced (host mail.cm.telia.net[80.74.207.118] said: 554 Your access to this mail system has been rejected due to poor reputation of a domain used in message transfer (in reply to end of DATA command)) It was only by accident that I was able to find out what it was, and when I did, I also managed to find out that said "poor reputation" involved Cisco having believed urlscan.io's misassessment that the Roundcube webmail software on a server is indicative of... ...drum roll... * PHISHING AGAINST THE GENERIC BRAND OF EMAIL * which caused Cisco to list all Roundcube servers everywhere. I shit you not. This was soon two years ago, but you don't make a fuckup like that when you're one of the largest companies in the business. And their error messages continue to suck every bit as much AFAIK. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> We're an email groups service, like Google Groups. Based on evidence > provided by Spamhaus, it appears that some groups that migrated from Yahoo > Groups when Y! Groups shut down contained some Spamhaus spamtrap addresses. That might be the explanation for why some of your customers' lists contain addresses that ceased to exist before groups.io started to. It does look rather suspicious when that happens. > On Spamhaus' suggestion, I built a reverification system late last year and > tested it on a small group of users. Yesterday, I kicked off a > reverification to a much larger segment of users. Looking forward to seeing this in our traps. This is a third-party observation that has nothing to do with Spamhaus. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid phish of the day
On Wed, Dec 13, 2023 at 05:53:13PM -0500, John R Levine via mailop wrote: > Phishing their own customers. I suppose in a karmic sense they > deserve it. > > (No, CAUCE is not a customer.) Neither are the resources where Koli-Lõks OÜ spamtraps received the same. :-) -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Docusign phishing campaign of the decade, brought to you by Microsoft?
On Tue, Dec 12, 2023 at 06:22:10PM -0600, Jarland Donnell via mailop wrote: > Hey friends, > > Do me a favor and search your logs for this domain: > SIBBERTLLC.onmicrosoft.com Three hits yesterday. > One customer received 1,347 attempted deliveries from it so far. > Another, 823. Still counting, and plenty more but with smaller > numbers. Is there no one at Microsoft watching anything, because if > this doesn't set off red flags, there are no red flags. I think there isn't. This campaign wasn't particularly voluminous towards our spamtraps, we frequently get hundreds and thousands of any given campaign (such as the "meet Ukrainian ladies" fake dating scams that are being sent from throwaway Hotmail accounts all the time). -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] dnsbl.spam.fail
> The residential address of the operator is a risk, because spamming is > a criminal activity in most countries and spammers are sometimes > organized like the mafia. They hate those lists and try to bring them > down by all kinds of attacks. Not providing them more attack surface > than necessary isn't a bad idea. Domeneshop does not have a residential address. They list their corporate physical address on their website. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] dnsbl.spam.fail
> Well, yeah, not really _impossible_, but I was referring to doing > monitoring based on DNS lookups, as is normal for DNS BL. Of course. > Also, Domeneshop confirmed they operate spam.fail as internal list OK. I tried tagging them on LinkedIn; it's an automatically generated corporate page with no owner. I tried tagging Asgeir Kristofersson, a person who reports currently working there; the tagging was automatically removed. > that they indeed have blacklisted Hetzner ranges because "lack of abuse > handling": Bastiaan van den Berg even participates here from time to time. Not that mailing list participation equals anything with respect to abuse handling. > Their MX, their rules... Indeed, but a little bit of transparency would go a long way. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] dnsbl.spam.fail
> Inability to do external DNS lookups makes it impossible to monitor > for presence on their list. https://spam.fail/search?ip=127.0.0.2 -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Another very strange microsoft originated email??
On Thu, Dec 07, 2023 at 12:44:58PM -0800, Randolf Richardson, Postmaster via mailop wrote: > I'm not familiar with Hertzner, but APNIC's WHOIS indicates a > country code of ZZ for the sending IP address's netblock, which the > ISO lists as "Unknown or unspecified country." The descr: reveals what you need to do. > descr: Transferred to the RIPE region on 2018-06-27T02:24:02Z. $ whois -h whois.ripe.net that.ip.add.ress -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Another very strange microsoft originated email??
On Thu, Dec 07, 2023 at 12:29:37AM +, Suresh Ramasubramanian via mailop wrote: > Free trial account on Microsoft 365 being relayed through Microsoft 365 > outbounds by a Hetzner IP As Suresh says. I've got a copy too. Nothing unusual in it, it definitely came through M365 infrastructure. From where it was injected to M365 is not that important - it could have been anything as long as they were capable of authenticating using the user accounts in that domain. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft's block list?
On Wed, Nov 22, 2023 at 04:25:36PM +0200, Otto J. Makela via mailop wrote: > Can someone shed light on a Microsoft/Outlook block list? Our hobby server > (on upcloud.com) seem to have been blocked for quite some time now. I have no idea why, but given that upcloud.com spammed my company to try to sell us their business, I'd be tempted to say that they have a reputation. The "n" is way too small to claim that it would mean anything, but maybe this unique data point could serve as that $.02 that you needed to move your VPS to another provider. (I can provide a complete unredacted copy of the spam to you, you and I go back 40 years and I have no issues trusting you with spam evidence.) > At this time, SPF and DKIM should be correct for our outgoing messages. > Is there anything to be done, apart from switching to some mail sender > company instead of ourselves attempting a direct connection? A direct connection may be perfectly fine. Your server will always be affected by your hosting provider's reputation. I wouldn't try with DigitalOcean either. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to report abuse to cloudflare? Only via Web-Form?!? Phishing sites not against cloudflare policy!?!
If you want any real action from Cloudflare, you have to jump through the hoop of filling in the web based abuse form. It sucks but only you can decide whether it's worth your time and effort. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Abuse Desk - we NEED to talk! (regarding 2a01:111:f403:2e1b::800 and other IP Addresses)
> 2a01:111:f403:2e1b::800 sent about 50 Spam Mails in October! Either to > Spam-Taps or being reported by our customers. 50 in a month and you're worried? :-) We get between 5000 to 9000 a day yes, a day from Microsoft outbounds to our spamtrap collection. About one thousand of those are fake dating porn spam in Finnish. Among the rest, more of the same in other languages. Plenty of 419, too. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Still Don't understand Google's relaying systems.. Duplicate Return-Path, and other things..
> They're a legit Google customer. What's there to marvel at? https://developers.google.com/gmail/api/guides <- have a look. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Still Don't understand Google's relaying systems.. Duplicate Return-Path, and other things..
On Thu, Oct 26, 2023 at 10:07:30AM -0700, Michael Peddemors via mailop wrote: > Not to be 'snide' Atro, but that part is pretty obvious.. You would have thought so - I would have thought so too. Which is why I reacted that way to your asking about it. > It was the technical details I was searching for, on HOW it is able > to relay from those IPs.. please review the original post again.. I > thought I was clear on that.. They're a legit Google customer. What's there to marvel at? -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Still Don't understand Google's relaying systems.. Duplicate Return-Path, and other things..
> Maybe Brandon can weigh in on or off list, but is there a a way for > spammers to simply relay out Gmail servers if they are Google Cloud? $ host -t txt sredplus.com sredplus.com descriptive text "google-site-verification=gyoD4DWS9XSrAmz9s5Pc9OBLvvowksBJtB0Oi-DAlsQ" sredplus.com descriptive text "v=spf1 mx include:_spf.google.com include:24145163.spf02.hubspotemail.net include:sendgrid.net -all" $ host -t mx sredplus.com sredplus.com mail is handled by 10 alt3.aspmx.l.google.com. sredplus.com mail is handled by 5 alt2.aspmx.l.google.com. sredplus.com mail is handled by 5 alt1.aspmx.l.google.com. sredplus.com mail is handled by 1 aspmx.l.google.com. sredplus.com mail is handled by 10 alt4.aspmx.l.google.com. I guess those two tell you everything you need to know: their email infrastructure is Google, they're just using it for cold email^W^W spam in addition to their regular stuff. This is really commonplace these days. > > > -- > "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 -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Amazon SES using SAME sender Domain for multiple customer?
> Does anyone know, why Amazon is not using their customer's domain as
> envelope sender?
It appears that customers can decide to do it.
> The Username part looks like a completely new random string on every
> email sent. Or is there a way to match one specific Amazon SES customer?
Parts of it may be same.
Our "n" is on the order of 100,000 for August 2023.
In roughly 16,000 of these, the envelope-sender matched the ERE
([0-9a-f]+-){6}000...@eu-west-1.amazonses.com
70% were somehow involved with amazonses.com (that Envelope-From or
another one at that domain).
30% had an envelope-from that did NOT involve amazonses.com or amazon.com.
--
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, https://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
> Might be convinced with this if it weren't for gmail being the source of > ~40% of the spam we receive. And that's after all of the botnets and so on have been blocked through the use of DNSBLs, I suppose? Mail subject lines seen in our test/dev spamtraps from Google outbounds over the past two weeks: For more details please reply Buy STRONG SMTP Cyber Weapon Come over to local moms home common bedtime habit skyrockets dementia risk. Milf Available for Free Hookups Come to my place & bang me tonight! Separated women looking for men The Ultimate Cure for Urination Frequency at Night The rate at which our production spamtraps get stuff from Google outbounds is more or less 1% of all mail, all of the time. This iso low tens of thousands of spam every day (yes, we're small, with only low thousands of domain names feeding this). It's mostly fake dating/hookup crap, with 419 a strong #2 contender and pharma #3. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
> I'm sure I've had a long explanation on here in the past year, but the > short answer is if the message is not DKIM valid and you're forwarding, you > should rewrite > the MAIL FROM to a domain you own that will SPF authn the message... and > try not to forward spam. That's not how forwarding works, Brandon. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMX/Mail.com contact?
On Fri, May 12, 2023 at 08:29:07PM +, Mike Hillyer via mailop wrote: > Anyone have a contact? I have someone with an accountant.com address trying > to run a check scam on me. > > Mike Hillyer They're represented on this list and have picked up not too long ago. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue
> I think we have to disagree here. The PTR naming is set via > SendGrid. It doesn't NEED to be the same as the A record. This is > for those MTA's that do forward/reverse matching, which isn't always > successful. > > Yes, doing that for a IPv6 email address to satisfy Google, go ahead. > > But nothing wrong with sending an email from a PTR with a name, that > doens't have the FQDN forward/reverse matched. RFC 1912 #2.1 It is 27 years old. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New to mass mailings
> Understood. We plan to change the setup over the summer but until then we > have to work with what we have. When we change we will probably set up our > own postfix server for mail handling. As far as I can tell it's about a two hour job to do the latter. > I should have added that our future "mass mailings" would be around 1000 > emails per week or every two weeks, iow, not too much. What I said is not about your proposed activities but the fact that you're planning to share the reputation of your sendouts with that of any number of other Ionos customers. > I did check the Ionos sending IP address on a couple of websites, including > mxtoolbox.com, and it is not listed. Good for you. That may change at any time for reasons that have nothing to do with you, and where the fix is also something you have no control over. My €.02 is biting the bullet and deploying your own server PDQ. It also makes it possible for you to do the DKIM signing you mentioned. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New to mass mailings
> We are mailing from our own CRM system but using Ionos (1and1.com) as our > mail service. You're setting yourselves up to fail by mailing out of a server shared by thousands of other customers. The error messages you quote testify to that. Don't do it. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any Apple email team on the list? Interesting tidbit like to shed light on...
On Tue, May 02, 2023 at 10:11:46PM -0400, John Levine via mailop wrote: > It appears that Michael Peddemors via mailop said: > >Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) > > I sent a message to myself from > > Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) > > There's no X-Universal anything. Wherever it came from, it's not the > Mac mail progaram. Our traps get a slow but steady drip of messages from Apple outbounds. Last month, one tenth of a percent of those messages (which tells the astute reader there's got to have been at least one thousand such messages) contained the header X-Universally-Unique-Identifier. Almost half of the messages we got were mail sent from anywhere else _to_ an Apple account that has been configured to forward email to an address that has never worked (before being made into a spamtrap), though. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] emailage.com ?
On Mon, Apr 24, 2023 at 10:44:47AM +0200, Jasper Spaans via mailop wrote: > Hello, > > We're seeing quite some postfix PREGREET errors in incoming smtp > traffic from hosts claiming to be emailage.com (by lexisnexis). Does > anyone know whether this is just a dressed up list washing service, > or would it be worthwhile for our customers if we start whitelisting > them? My $.02: [root@mail ~]# grep emailage /etc/postfix/* /etc/postfix/helo_access:emailage.com REJECT Spam list cleaners are welcome to take a hike -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] delisting from Invaluement ivmURI
> One of our brand's domain has been listed on the Invaluement ivmURI RBL. The operator is present here on Mailop. They should be waking up soonish - I can't remember where they are but there's a chance they're on the west coast and that would mean it's soon 5 am there. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] warming up IPs, Microsoft?
> I believe it, but the more relevant question is what fraction that is of the > total > mail they send. I see way more real mail than spam from them. I can only speak to the mail we see. I am sure all of the entities that are sending to our spamtraps mostly send good email. I simply could not have any visibility to the rest. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] warming up IPs, Microsoft?
> You have to validate each domain you use for sending, which is a > modest pain, but that's one of the reasons their mail stream is > pretty clean. Do you mean AWS SES specifically? They're consistently #4 by volume in our dataset (occasionally even #3, rarely #5), next only to SendGrid, ExactTarget and Mailchimp. In February we had close to 6000 separate domains sending from AWS SES to our spamtraps. The corresponding number is more than 15,500 for SendGrid, less than 5500 for ExactTarget, and close to 15,000 for Mailchimp (closer to 16,000 when you take into account the fact that the senders with freemail From's are not one, but many). -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intuit directly spaming
> > harder to give due suspision on sendgrid because they give full It's actually kind of easy. Is the IP announced by AS11377? Yes? -> SendGrid. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intuit directly spaming
> Interesting to me Atro said this is sendgrid. I saw sendgrid format > sender address but headers do no show any sendgrid. So now its > harder to give due suspision on sendgrid because they give full > infrastructure to rent for other domain like intuit? Yes. Full headers (munged of course) and plaintext content https://pastebin.com/88xXcVZh This will remain up for a week. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intuit directly spaming
On Mon, Feb 27, 2023 at 08:05:31PM +0100, Faisal Misle via mailop wrote: > I wonder if its the similar MO as PayPal, where they use Quickbooks accounts > to send fake invoices... so it uses the legitimate QB stream Right on the money, that is exactly what it is. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
> what is your data that shows hetzner being worse than others in this field? What is the point you are trying to make by trying to turn this into a race where it wasn't one previously? We are discussing Hetzner specifically, prompted by the original post from Lena, last I checked. > hetzner has grown big and in absolute numbers it's clear that the > number of abuse is big - but only relative numbers are fair to > compare! In addition to making the mistake of trying to make it a race, you are also mistaking a qualitative discussion for a quantitative one. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
> Ever been on the receiving end of a retaliatory abuse complaint? Yup, that too. > As a Hetzner customer I expect some trust in the company I pay money > to, As do I, as a Hetzner customer. > that they'll give me a chance to face my accuser and fix the > problem if there is one, or give a response as to why I shouldn't > have to if there isn't a problem. I, too, expect to be told what the nature of the problem is. Where the report comes from should be completely irrelevant. I frequently don't bother with complaints of abuse to Hetzner because I get back the autoreply that states I am expected to OK them forwarding it verbatim to the spammer. Most of the spammers I would complain about are not the hijacked systems but the dedicated ones. > There are two sides to every story, surprisingly companies aren't > keen to just kick all of their customers out by third party demand, > on demand. Not expecting shooting on sight, as already said. Some safety measures would be nice though, such as not outsourcing the ToSsing of spammers to the spammers themselves. > > On 2023-02-07 07:15, Atro Tossavainen via mailop wrote: > >>Neither do I. The response simply describes what is happening. When a > >>third party X complains that Hetzner customer Y is a spammer, I > >>consider > >>it only appropriate that Hetzner passes the complaint along and asks Y > >>for a statement, and does not simply impose restrictions on Y based on > >>X's say-so. Informing X of what the internal process entails does not > >>look offensive, let alone insulting, to me. > > > >Have you ever been on the receiving end of retaliation from a > >spammer, Ralph? > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
> If we were passing them on verbatim we wouldn’t have to manually > process them. Suppose it is so, then. > As for the spammers comment, you know that the vast majority of spam > leaving our network is from compromised servers. You would know that beyond any doubt. I don't have comprehensive stats, although I may have guesses. > Most spam complaints we get are for legitimate clients. There are > spammers who try to sign up with us, but those that get through and > start spamming don't last very long. OK. I'm curious about the Russian spam list spammer on 78.47.158.139 four days ago, as well as the dedicated 419 domain on 168.119.9.111 two weeks ago, if you are at liberty to discuss. (As well as the Japanese credit card phishers everywhere. Subject: [実録]格安カードで騙された！ 88.99.150.167 188.40.100.144 138.201.209.250 95.216.221.140 195.201.12.225 148.251.202.161 78.47.187.206 135.181.5.246 95.217.226.237 116.203.45.186 176.9.44.204 65.109.189.33 95.217.211.68 144.76.32.106 188.34.190.243 ) > We deal with this by giving our client a chance to resolve the > issue. But you don't know the legitimate client from the illegitimate one before you do, which could mean you might be passing on information that the illegitimate one could then use for retaliating against the complainant. > If they don't, then we take action. Blocking servers for a > single abuse complaint without first informing our client about a > potential issue is not something that a reliable hosting partner > would do. Not expecting you to shoot on sight, that's for sure. Admittedly I also don't know how much information in the initial complaint you actually do forward to the customer. In the absence of reliable evidence to the contrary, I am expecting it to be "everything." (Which brings us back to square one: don't enable further abuse.) I'd love to be wrong on that. > These are dealt with in a timely manner, and a quick look at the > blacklists that show data for entire networks/companies will show > that we take spam seriously. Having only one live SBL is indeed an indication of mostly getting it right. Many others have dozens, hundreds. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
> Neither do I. The response simply describes what is happening. When a > third party X complains that Hetzner customer Y is a spammer, I consider > it only appropriate that Hetzner passes the complaint along and asks Y > for a statement, and does not simply impose restrictions on Y based on > X's say-so. Informing X of what the internal process entails does not > look offensive, let alone insulting, to me. Have you ever been on the receiving end of retaliation from a spammer, Ralph? -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
Thanks Bastiaan for picking up the red courtesy phone so fast. > I’m not seeing anything offensive or insulting in our response. I am referring to the fact that the wording of the autoreply suggests that Hetzner is simply passing complaints verbatim to the spammers themselves and not dealing with it yourselves. To me, that _is_ offensive and insulting, because as we all know, we (tinw) don't want the spammer to know about us, we don't want the spammer to remove just us, we want you to remove the spammers, and there is nothing the spammer themselves can accomplish to that end. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hetzner
> My conclusion is that Hetzner is a heaven for spammers. Bastiaan is on this list. Is there anything you can do, Bastiaan, to make the offensive responses to abuse@ go away permanently and for the company to stop insulting complainants? -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Freenet.de Contact
> Thank you for this. I usually avoid role-based addresses when trying to reach > out to someone about email if only because I rarely if every receive any > response, but I wrote to that one today hoping for a response. This is actually an interesting viewpoint. Should others also do the same with respect to companies represented here on Mailop? Especially if others have been told not to reach out personally, but only to use role addresses? -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Google spurning the City of Kuopio, Finland
Hello world, It was reported in Finnish news today https://yle.fi/a/74-20014495 that the city of Kuopio (#8 largest in the country) is unable to send email to addresses served by Google and that this would be expected to last for about two weeks. According to the comments in the article, the reason for the problems was a problem on the email server of the city which caused the domain name kuopio.fi to end up on a block list at Google. The news article links to a press release from the city itself. It says that for about a week, the city has had problems sending email from Microsoft environments to Google accounts. I am not affiliated with the city of Kuopio or their ICT partner Istekki myself, I'm just watching this as a curious onlooker. Based on what I see in spamtraps, "sending email from Microsoft environments" isn't happening. 100% of the (very small amount of) email genuinely sent from the City of Kuopio is sent from a dedicated server managed by Istekki which is not a Microsoft environment. If there is anything that should be reported back to the City of Kuopio or their ICT partners, I'm happy to act as the local conduit. :-D -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there a way to unsubscribe from Nextdoor emails?
Here's my €.02. The context for this is http://mainsleaze.spambouncer.org/may-2021-in-spamtraps-esps/ (and similar posts on same site before, as well as my LinkedIn posts on the same topic later) Here's a data point to the current conversation. [atossava@x ~]$ for i in 202?-??_ESP-blog/202*_esp_sendgrid*; do nextdoor=`fgrep -c .nextdoor.com $i`; total=`wc -l < $i`; month=`echo $i | cut -f1 -d_`; echo $month: `expr 1000 \* $nextdoor / $total` ‰ ; done Output: 2021-01: 7 ‰ 2021-02: 7 ‰ 2021-03: 7 ‰ 2021-04: 7 ‰ 2021-05: 8 ‰ 2021-06: 7 ‰ 2021-07: 9 ‰ 2021-08: 9 ‰ 2021-09: 11 ‰ 2021-10: 12 ‰ 2021-11: 11 ‰ 2021-12: 13 ‰ 2022-01: 17 ‰ 2022-02: 33 ‰ 2022-03: 32 ‰ 2022-04: 32 ‰ 2022-05: 31 ‰ 2022-06: 29 ‰ 2022-07: 34 ‰ 2022-08: 46 ‰ 2022-09: 43 ‰ 2022-10: 36 ‰ 2022-11: 32 ‰ Another one is that they keep adding more trap addresses to hit, and we've had control over these for years. Opt-in it is not. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact at Outlook?
On Wed, Nov 23, 2022 at 04:01:30PM -0600, Jarland Donnell via mailop wrote: > Assuming that doesn't pan out, can you file an abuse complaint with > their DNS provider? Sure can't hurt anything. Oddly enough Microsoft's DNS provider is... Microsoft. Microsoft has an employee participating on this list. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google Gives Gmail Mass Email Services the Boot
On Fri, Nov 18, 2022 at 10:56:26AM -0700, Anne Mitchell via mailop wrote: > It's about time, and to the extent that you were involved (if at all), > Brandon, *thank you*! > > "Users of mass email services such as Gmass, Woodpecker, Lemlist and others > that have been using Gmail’s API to send bulk email that tricked recipients > into thinking that they were receiving personal one-to-one emails have been > put on notice today by Google: “Applications that use multiple accounts to > abuse Google policies, bypass Gmail account limitation, circumvent filters > and spam, or otherwise subvert restrictions are prohibited from accessing > Gmail API scopes.”" > > https://www.isipp.com/blog/google-gives-gmail-mass-email-services-the-boot/ Much appreciated. Thanks to all who contributed to make this happen. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [Public] trouble delivering to cox.net
> I do see a not > insignificant amount of mail to invalid recipients so you might want to > check that you're understanding/processing bounces/deferrals properly. Koli-Lõks OÜ spamtraps concur, seeing mail from USAA both to typotraps as well as recycled domains. These are of course no longer undeliverable, but a health check on the data ought to get rid of them just the same. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Threat Update.. Tales from the Trenches..
> >PS, don't know what o365 is doing, but a marked reduction in uncaught spam > >leaking from their networks.. > > > Really? I'm seeing a constant stream of fake dating spam from apparently > compromised O365 accounts, with no end in sight. I'm with Hans-Martin on this one. > Many of them use link shorteners (mostly tinyurl.com), content text > has so little variation that good old regex rules get all of them, > so it seems to be just a single spamming operation. Targets are > german, so that may be a reason you're not seeing those. Targets are also Swedish and Finnish. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] abuse@ equivalent for yahoo dot com?
> You can use https://senders.yahooinc.com/contact Email responses to email abuse. thank you, very much Best regards, RFC 2142 -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP noise from *.bouncer.cloud
> Fine. You're responsible for delivering mail submitted to you, and > it is entirely reasonable to confirm that the entity you are > accepting it from has provided a usable address. What Postfix then > does to verify it is exactly what would be done if a message was > simply accepted without verification. Does not take into account the matter of spam with forged headers. I didn't send that email, and you're "verifying" whether I did, doing exactly the same as Radek's woodpecker-as-a-service. No different from my perspective. [root@mail ~]# grep -i sender /etc/postfix/helo_access* /etc/postfix/helo_access:inpost.tmes.trendmicro.com REJECT Sender Address Verification is Abusive /etc/postfix/helo_access.pcre:/\.mailspamprotection\.com/ REJECT Sender Address Verification is Abusive /etc/postfix/helo_access.pcre:/\.pphosted\.com/ REJECT Sender Address Verification is Abusive And that's just some of the big names doing it. > This is a bit less clear, but I'd say that is fine because you have > every reason to believe that you are acting on behalf of the address > owner, not some 3rd party who may not have acquired the address > legitimately. This, too, can be co-opted by people who aren't your users. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP noise from *.bouncer.cloud
> Atro appears to object to this use. I disagree. It's abusable. Your users might not be who you think they will be. > Arguably this is less expensive than "double opt in", which is doing > a similar thing. Yes. It also returns a different category of result. > One way around that might be for the > final step be to send the applicant a copy of their completed form. > If this bounces, then you ask them to correct the address. Yup. > Of course, if they give *someone-elses* email (whether by accident > or deliberately) you have just mailed personal data to a third party People will mistype their address. Some of the typos exist. I know because I have access to some of those that do - we are in the business of spamtrapping, some of our traps are typo domains, and some of the stuff that comes in is... not bulk email. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP noise from *.bouncer.cloud
> Regarding the above, I have the following question:
>
> What do you (and maybe other people on the list) think about such email
> verification method ("abusing RCPT TO") used as part of:
>
> a) mail receiving process - I'm thinking here for example about the Postfix
> feature "reject_unverified_recipient" that checks sender's email using this
> method before accepting (or rejecting, if sender's email doesn't verify) the
> message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
> other MTAs have similar features too, there are also milters that do this.
Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are forged
as senders in spam.
And so is Challenge/Response based spam filtering.
> b) website registration process - some time ago I was maintaining some
> website where people often mistyped their email addresses. Due to the
> nature of the website the typical "click on confirmation link that
> arrives via email" approach could not be used
List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.
> anything except the registration form). So I included the code that did the
> email verification ("abusing RCPT TO") upon form submission, and in case of
> a verification failure, asked the user to correct the address.
...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)
> Do you think using this method of email verification in such cases
> is OK or not?
If it is, then it must be OK in all cases. This is, after all, the
intended use case for Radek's system as per his previous correspondence.
But I don't think it is.
In my opinion, whether you do it yourself or outsource it to a partner
cannot be a factor in whether it is abusive. Neither is the volume. The
main bit is that the creator of any such system has observed the fact
that EXPN and VRFY are no longer available, so they have decided to
circumvent this fact and impose themselves on the mail server owners
in ways they can't pre-emptively break without breaking all email.
The solution to that, then, is rejecting all connections from such
systems, either within SMTP or on the network level. But doing that
requires observing where it is coming from first.
Those blocks tend to be of a set-and-forget nature.
--
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP noise from *.bouncer.cloud
Czesc, Radek, > We assume that: > - our customer (data controller) who requested us to verify the email address > got it in a legal way > - our customer is obeying anti-spam policies. So do all the ESPs. But their customers send mail, and the recipients are able to act upon it, informing the ESP of problem clients and sometimes even getting traction. In the case of email verifiers, there is no message, and there is no email recipient to do the same. The only people who have any visibility to the efforts of woodpeckers who abuse SMTP (EXPN and VRFY were disabled and even removed from mail software for a reason) are grumpy mail server admins who have much less time than your average spam recipient for this kind of behaviour. "Email verification" abusing RCPT TO produces zero benefits in exchange for nonzero resource use for the target system owners. I had entered "bouncer.cloud" in my list of HELOs to reject offhand a long time before this conversation. Don't worry, you're not alone; the list of similar players is dozens of lines long, could probably be made shorter by replacing most of the existing rules with entries in the regex version of the same, and additionally, some of the HELO rejects are redundant now that the networks involved have been entered into the firewall drop list, entities who have been kind enough to register their own networks such as Mailinblack or Kickbox are no longer able to make any connections to our systems at all. > Thank you again for the opportunity to be here - if you are already tired of > me - please let me know. Having said all of the above, I truly welcome the fact that you have shown up here to own up and explain what it is that you are doing and where you are coming from with this. It may not make matters any better from the perspective of whether anybody's inclined to accept email verification attempts, but from my perspective, somebody who shows up in a potentially hostile environment such as this deserves some kudos just for doing it. We've discussed this offline before and I wanted to say this in public too. Pozdrawiam, A. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] State of the Union - Update due to activity..
On Tue, Aug 30, 2022 at 05:36:16PM -0500, Jarland Donnell via mailop wrote: > That subdomain style, I've been eyeballing that trend for a while. > This guy got super mad at me for identifying that trend on a network > that hadn't yet started sending spam: > https://forum.directadmin.com/threads/rbl_dns_list-suggestion.64780/post-350740 LOL. That network (212.192.216.0/22) was assigned by Serverion to "voldeta-mnt" (Des Capital B.V., AS213035) on 2022-06-04T10:45:44Z. This is what came up first for me when I googled that business name: https://scamalytics.com/ip/isp/des-capital-b-v The spam started a week later. It was a 419. On July 1-2, there was a massive spam run that rivalled the monthly output of some minor ESPs in the same recipient mailboxes. All your basic kinds of garbage affiliate spam. I get the impression plonking AS213035 in a router's null-route list might amount to lossless compression. The list of networks that this AS advertises is 67 lines long even after doing the CIDR math to show it in its most compact form, and they're everywhere, AfriNIC, RIPE, ARIN and APNIC ranges are all present in that list. Best regards, -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] State of the Union - Update due to activity..
On Tue, Aug 30, 2022 at 01:11:20PM -0700, Michael Peddemors via mailop wrote: > Hehehe... > > No, I meant who are behind these.. https://emailable.com/abuse/ > Is AWS alright with this.. I suppose the answer is yes. Getting any kind of answer to any question out of them is beyond difficult, so this may be simply by implication. > Trouble is how to tell good email validators from bad ones.. > Even, what is a good validator vs a bad one.. The good email validators don't show up on your mail servers. They do stuff on their own, based on DNS and other things that don't require turning into a woodpecker. > And how about transparency? Technically, I don't see the reasoning > why to do this, and if you need to do it, not be transparent about > it.. Yes. I didn't write this https://www.spamhaus.org/news/article/722/on-the-dubious-merits-of-email-verification-services and I have nothing to do with the folks who did, but it's hard to disagree with anything in it. > Now, if there was only some method to see if you really have > permission to use an email address.. ;) Interested in buying a bridge in southern NYC? ;-) -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] State of the Union - Update due to activity..
> In other news.. Any comments about these guys on AWS? > > 3.217.146.99 1 mx25.herpderpderpderp.com > 3.223.197.220 1 mx2.emailablev.com > 3.226.89.155(RS) 2 va1.mx-check.com Sure. [root@mail ~]# egrep 'herpderp|emailablev|mx-check' /etc/postfix/helo_access.pcre /emailablev\.com/ REJECT Spam list cleaners are welcome to take a hike /herpderpderpderp\.com/ REJECT Spam list cleaners are welcome to take a hike [root@mail ~]# egrep 'herpderp|emailablev|mx-check' /etc/postfix/helo_access mx-check.com REJECT Spam list cleaners are welcome to take a hike -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid
On Wed, Aug 17, 2022 at 11:44:18AM -0700, Luke via mailop wrote: > That account was terminated on the 14th. For what it is worth (and I know > this is worth very little here), our system did prevent more than ~90% of > their *attempted* mail from ever leaving our pipes. So I like to tell > myself we prevented 9 million phish instead of telling myself we sent 1 > million phish. Kidding of course... > > Thomas, if you're still seeing mail arrive *today* with those unsubscribe > links, that would be incredibly strange. Would love to chat offline if > that's actually what you're seeing. An account sending email 3 days after > being terminated isn't really a thing that happens. A thing that might have affected the sending is that Radix (the .store registry) took the sending domain out on 2022-08-14 at 03:23:40 UTC. At least you'd hope that non-existent domains couldn't be used as senders. The spamtraps do concur with what you say though, that flood was on the 12th and 13th, ending around 10 pm UTC on the 13th. More recently, what's the deal with user accounts 28489652, 28470998, 28470691, 27864014 and especially 5965629? > > Luke > > On Wed, Aug 17, 2022 at 10:09 AM Thomas Ho via mailop > wrote: > > > Funny how we're still seeing this exact same template spewing out of > > Sendgrid for days. > > > > I guess (hope) they're busy working on tackling much more malicious spam > > coming from their network. > > > > -Thomas > > > > On 8/13/22 15:46, John Levine via mailop wrote: > > > This showed up today, send to the email of my father who died in 2019. > > > > > > Full copy available on request to anyone who has a plausible use for it. > > > -- Forwarded message -- > > > Date: Sat, 13 Aug 2022 15:41:20 > > > From: support > > > Reply-To: g...@hansa-fx.com > > > To: x@x.x > > > Subject: IP address blacklisted(Child Pornography Act 1996 violated) > > > > > > Hello, > > > > > > We have found instances of child pornography accessed from your IP > > > address. This is a punishable offence under The Child Pornography > > > Prevention Act of 1996 . For now we are blacklisting your IP address > > > and if there is any further action from Microsoft you will be informed > > > via email. > > > > > > If this was not you and you suspect potential hack or id theft contact > > > Microsoft Support Team at +1-808-460-7701 > > > > > > Microsoft Support > > > +1-808-460-7701 > > > > > > support > > > > > > 16 Central, HCW , Tampa , FL > > > > > > Unsubscribe ( > > > > > https://u28413401.ct.sendgrid.net/asm/unsubscribe/?user_id=2401&data=jGkM5n0umWt5giSnrpl6O4tFPc5wzKFsV94hjZBX8pQIheAKOas_zWNsEOncd-HbCkpbIvoVXgT8sU6DigWO_eN-7q_f3_YdzG22esQZaeYvwfRfC4RvAZR91smd6V5UOKs3K3YnTNLu7eqpmNs5MgibY69YuER5xZyCM1zKjcZ-8WdqDiZ09ZDW8MnPZwlCq4ExdET6b1FfymKFmn0M57AS6OrQ9Z41ntAYLbucVhznk0bqlHrqgYAhJmD8r32C-y6jAiILcbSJnjKcwbO4A2XlH2Xq_STVI0NZNEGJSk3rsNiS1BljdqcVvog_l47a_9QqpTTzdEtJxb76h7njtiNvZmy2GahPuC5VtdWCFL8sw8dhTZN792pmswmZV8Stx9YNphaZCY0Zz-Y-6B3oy7d_C-u0550ED8DjIh5dQKo05hHfkqQv-JzGA1cm2BIQcEaDOWBAXIFPQhsZtmN1NV352KGimJzF1zQBc869JXc0LNV6lWdxB9tHv9FPAxyyUvAI7GCYEprshgEYBXxNc5vwH5SsHnk5XXKpbVztKb-rF_CXEu4_sVDZt1dcMerLreg5jj1abowz0vzCxu91ljSE_625gU2Nfvwf_evzfEtaDdgklH90ndYyZNjTEUFL7B1TCJ3FIyVfY2tfVarBYX_aZRyujWy2HMNwhbJApYoFQ5KIVbl8odCtVRe5Ss6z720nEmO6S3yE8IgJXIPTCuYH_plCZ2es85QKi21w-gGWICt3gPZNDYpxq2V23Amf9DtI98NiQg93_f9tWLu3ncR_l7Xu-QyQ-NHpZGOZzJGJl6hZO0NKhBs2fS-DSZwbI8sy0pFprpTmbArND7x-CkuBHe5H1WW0FyHCHb1NLsK9SBn-aJMsk0xtAowOpzMGPsWj_AFn12Gj1MU2qh_ > > > > > Zc4tlcFvAEIaXfZnGVU0Y8MqPIL7zCaF4I01Q1GxU7wziTkPwcMyeUT8qvfjbtJnQ9_zTMykNipOu1NmmemXBHGJml3neoZ75wscSo_2XSg1AKGk0ceEGUu-Xrj5FsTwd4i_Lvu6i2aPAKpRgkCrLZN7x_Cy7fsLksN8juSIi3m-GYcaCMsxtAjo9xI9ZewQel_kjR-Nl43qwegdl1Al5eZmDY0VY749OELIRduc-SUty-0Pmt4NZPKD7hqCkVV6X_qgRC2aKxJAlFKIU03FW1R6Iueoz4qstvxH32NPeLz2H_OoTdTI= > > > > > ) - Unsubscribe Preferences ( > > > > > https://u28413401.ct.sendgrid.net/asm/?user_id=28413401&data=iw27W5ySrSfDVCRlPaXMu5zZMK6M9L26Fq8UYqOfdZhoMDAwdTAwMFT1ohToGkgPLNAwsvCWjLkjDNagBfBVNm4La20qWnyb349Ffm1yfrD4ctSwuskuNp7Uzh4IUp41Fz5FYgodIco5ievuqL7nDm63AdCvifURyfq07C4ck6IkGGV9omBlZ8ahQz-3tfQdDuXkkIDKsln-j8pQTiYAA5cnxyzRrdDZKAPFE-nAcd6eB4cSSmMY09NNRAhGs5YRCqXXGKB4rg8QCfDbyNXKbsVbIl5lf9NZ3QOD2WjZhkFDFX0rv2rLzw3FsHRqaNyT-YRCrW_0zWBcn4nYM2r8jngI78F3qjI8LsQOcjXBVa27_OUX4cPEoqAibJW0zJHhKOD20KWDGgE2k6TUiFpMPQ1eHg6A28fWkJsffmFbKXirplWlcEo7iw3oiiUcVpREbcdELBXZ8MiiKIPil6T7if1FH2oBhwKnbyzjiUxo3uIlxos0Yr-xV-3ZA_h5o4JifaCzIFwNYxzT3hqapJw6njG_wUCUfT9z8McN5CzkKNjQc4WxwiMuld1JJbyzB5tjNjAHAht1wirqjrrFBHoG > > > > > 9m2B9eqqIeckhXlTMCaQ3jJBMnLpcnAQ0_wLVL-Ua2U5SX1cXm1n6JorUlG27yxJvUItjuWXE99NnN9qImyxlaWg0Sk-OFOA76cLP5hVv10Vb_BMw5cwVcHLI5cKs5PEHUAX8ua4pV3fLgWR6TERaT8XpKcZhkiBtDD9kmleAOCgfSnjpvlyvFkJAPsoiibP-WhJNDmKE8FP25gZ2qp8nLaffDtB-mnu2rs2dD0XFijEcX-QvOPrqh35JhkYl2_NgXb8yiH8L45RRqqDKQprOF9cdvyeV5Q4P7DBvm8rynoSBWaMTGK5EVWIKI66IJPU5MFNCzoKp1WMbnIH-7EVIVwu6EIh4Zf1RHHWqj9kMABWHUx_FUAxtKJCV-t8IrT2T46yiZ4W5StTXvvKFti9h3fjm5FZnoOlKzmv-2LsBGN_nBQ8t4BLgFUVe-MeSYIwUzWUqs1W-vLqDIu
Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid
On Sat, Aug 13, 2022 at 06:46:02PM -0400, John Levine via mailop wrote: > This showed up today, send to the email of my father who died in 2019. > > Full copy available on request to anyone who has a plausible use for it. Got a few hundred. SendGrid user ID 28413401. Sending IP 167.89.38.98 is on SpamCop, but not on any other major blocklists that I could see, yet. Radix (the registry for .store and a few other new TLDs) has been alerted separately. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> Ideally, a SMTP return code should differentiate the reason for rejection. > There should be a different code for non-existing user, technical problems > (like mailbox full) or policy-based reject. You know, they actually did think of that. https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.3 https://datatracker.ietf.org/doc/html/rfc3463#page-14 > Although I'm not sure if in the > latter case it is possible to differentiate if the policy rejection is > "general" (eg. related to sending IP) or for the particular sender's email > address. Doesn't look like it to me. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> Talking about anti-fraud, anti-spam at self-service ESP level, that's What an excellent writeup. Thank you Simon for this! -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> I would love a way to give those addresses (in a hashed form) to ESPs saying > "Look, if somsone is sending to those, it's a bogus list and does not pass > muster, and you should reject the customer". > > I'd love a way to put those addresses in the DNS as a similar flag. "Do not > allow this address to be added to any mailing lists, promotional marketing, > or @##$*&#ing google groups, period. Attempts to do so are suspect". Objection, assumes a level of interest in due diligence on behalf of mass senders. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> If we agree that IP addresses, email addresses and real names are all PII as > per GDPR, your example is comparable to Cloudflare. The idea that IP addresses could be personal data has always blown my mind, but the GDPR does classify it as such. > The end-user browsing a website is sending PII (its IP address, along with > cookies and whatnot) to CF, which it then forwards to the proxied website. > The visitor that does not know how to block cookies on their browser, also > cannot know it is sending its PII to CF. > > Does this turn CF into a data controller? If CF decides that the end user is > indeed a bot because of data gathered among various CF clients, does it > become a data controller? IANAL, so I freely admit I'm just talking out of my ass here. Cloudflare's own position https://www.cloudflare.com/gdpr/introduction/ is that they are a data processor. The nuances of the situation are slightly different because in the case of ESPs, they are dealing with personal data that their customer (the actual brand or whatever) has deliberately made available to them for the performance of the contracted service. In the case of CF, their customers' "customers", aka website visitors, don't necessarily have any prior relationship with the CF customer, and probably did not deliberately supply an IP address to the CF customer to be included in their record (say, along with name and email address) even if there is a prior relationship and an existing customer file. What does CF do with the collection of IP addresses that it inevitably amasses as a side effect of providing the proxy service to its customers? Does it store them and use them later for some purpose without being ordered to do so by their own customers, or does it either just ditch them after the connection is done, or at most pass it to the origin server in the form of a True-Client-IP: header in the HTTP requests? I don't have anything resembling an answer for you, just musings. > Going back to the example of an ESP, does the hash of the email address > equate the email address as per GDPR? At least from the MSBL EBL perspective (https://www.msbl.org/hashbls.html) it looks as if hashes ought not to constitute personal data. Now I happen to think that whoever is behind the EBL (and everybody who was in Toronto knows it) is not a lawyer, but at the same time, they just might have done their due diligence and have this checked by a competent lawyer. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Hans-Martin Mosner wrote: > Especially in the area of freemailer spam (and somewhat ESP spam, of course), > hashes of spammy mail senders could be used to share reputation among mailops > without handling actual e-mail addresses. Er, I think you mean https://msbl.org/ebl.html which was presented to the public in M3AAWG 41, Toronto, October 2017. Ever since, Spamhaus have also made their own take of the same idea. It is the HBL. The HBL has a wider scope (in addition to email addresses, it also considers file attachments and cryptocurrency wallets), but availability is somewhat restricted whereas the use of the MSBL EBL is free as in free beer. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> I got none of it, and nobody could figure out why for a while. It > finally turned out that the ESP had added our entire domain name to > some sort of global blocklist they have, solely based on my > complaints that the ESP was letting their customers repeatedly send > spam to our role addresses like support@, billing@, and info@. (The > address the large company was trying to send to was not one of those > addresses.) BTDTGTTS. The people who were then on the other side of this incident are probably among mailop readers. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Lem said: > I question your assertion that "bounces for X sender doesn’t mean that it > shouldn’t be mailed for Y sender". Indeed if, say, an address doesn't exist, it doesn't exist whether the sender is X or Y. Also, if the mail platform rejects mail from the sender's IPs or domains, it will probably do that for X and Y alike. According to people who know better than I do, and any M3 member (which would mean at least Laura and Lem) has had the chance to hear them out in person, maintaining a suppression list that is above the level of a single customer makes the ESP a _data controller_ in terms of the GDPR. When they're doing stuff for their customers only, individually (as in, data from customer X does not affect the proceedings for customer Y), they are a _data processor_ and that's where they want to be. Becoming a data controller entails needing a legitimate basis for processing the personal data of the customer's customers, with whom the ESP does not have any kind of a direct business relationship so it's really very hard to justify. You can probably pull the notes on "so, you want to be a data controller" from the past conference proceedings from the members area. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> Many of the ESPs that we certify will require senders with certain types of > lists (size, industry, etc.) to reconfirm a percentage of their list upon > upload. And make no mistake, good ESPs scan uploaded lists for the same > things as do list-washi...er..."list hygiene" services. Anything you can do about list hygiene that doesn't involve being a woodpecker on the mail servers of unrelated third parties is great. Checking for addresses at domains that don't exist involves checking DNS. I believe nobody's going to be bothered about a few DNS queries. Checking for addresses that violate mailbox name syntax as per RFC5322 is another no-brainer that is just a data quality check and doesn't go outside your platform at all. Cheers, -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> Sadly, there is at least one legitimate reasons to allow this: > how else could a customer change ESP ? There is that. But since the new ESP has no immediate way of knowing anything about the legitimacy of the uploaded list, the problem remains. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On Wed, Jul 20, 2022 at 12:41:53PM -0600, Brie via mailop wrote: > So, hey, yeah, Sendgrid and Zoom... > > It's still going on even though it was 'being looked into'. It is. But I looked at the amount of .zoom.us stuff in all the SendGrid output in our traps from January to June and the trend is almost consistently downwards, January 0.35% February0.27% March 0.23% April 0.25% May 0.19% June0.11% YMMV. > Why do you not respect permanent errors when delivering? I've been asking all the ESPs the same question for at least the seven years that Koli-Lõks OÜ has existed. Ever since a respected figure in the industry said that keeping a domain without MX is not quite the same as having it responding 550 5.1.1 to everything, we have been priming all new spamtrap domains by having them respond 550 5.1.1 to everything for at least 12 months. (I disagree with the idea that ESPs should not trust their own systems when they get a NXDOMAIN response, but it's not a big deal for us to do this if it helps. I am not quite convinced it does, based on the results.) Technically, based on the idea that ESPs would actually act on undeliverables the way you suggest, this should lead to our only being able to catch botnet and other thoroughly illegitimate spam and hardly any ESP content at all. You would think so, wouldn't you. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Trouble sending mail to French providers
On Tue, Jul 12, 2022 at 11:59:22AM +, Frietschy, Carlo via mailop wrote: > Since Friday around 12 o'clock we receive 5xx error messages from most major > French mail providers like Orange, SFR, Free, Laposte, Wanadoo, etc. with > messages like: > > - Mail rejete. Mail rejected. OFR_506 [506] > - 5.7.1 Service refuse. Veuillez essayer plus tard. service refused, please > try later. LPN007_510 > - spam detected I bet you've run into Signal Spam somehow. https://www.signal-spam.fr/ Amicalement, A. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Looking for contact at iphmx.com
Hey Sidsel, Bastiaan, On Tue, Jun 28, 2022 at 01:09:45PM +0200, Hetzner Blacklist via mailop wrote: > That error message means your IP has a poor email reputation on Cisco Talos: > https://talosintelligence.com/reputation_center/ Cisco Talos has to be the most opaque reputation service I have come across so far. They also take the word of a third party (SecurityTrails, or whatever their IP intelligence arm is called, in this case) as gospel. Or at least took, some time ago. The good folks at SecurityTrails figured out a few months ago that the presence of the RoundCube webmail product counts as "phishing against the generic brand of email" (I shit you not) and as a result, Cisco proceeded to list all domains operating RoundCube as bad. How do I know? I got hit, that's how. :-D Took me a good deal of time to even figure out who were responsible and how, and probably wouldn't have been possible without M3AAWG contacts. Also, I found out that some parties trusting Cisco Talos intelligence (such as Telia Finland or the government ICT centre of Finland) are so far behind the requirements of their jobs you wouldn't believe they had been hired by anyone. > > Regards > Bastiaan > > Am 28.06.2022 um 12:09 schrieb Sidsel Jensen via mailop: > >Hi > >I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know > >who to reach out to? They don't respond through ab...@enom.com > >mailto:ab...@enom.com (which was the only address whois showed as everything > >else was heavily redacted) > >I'm trying to solve a deliverability problem towards them: > >host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: > >554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been > >rejected due to the sending MTA's poor reputation. If you believe that this > >failure is in error, please contact the intended recipient via alternate > >means. > >I guess mailop applies as "alternate means" ;-) > >Kind Regards, > >Sidsel Jensen > >Architect of Deliverability and Abuse @ Open-Xchange -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net
Cher M CARON > Sorry but I represent OVH email team (not abuse), I have no power and > visibility on stuff out our email offer perimeter. This is understood. > As I say in private, the abuse form https://www.ovh.com/abuse/#!/ permit to > report spam problems. It ensure to abuse team enough information to check and > block. If a ticket system does not allow email input with similar outcomes it has to be considered as broken. I had one that did (Request Tracker v2.x) at a former workplace ever since September 11, 2001 (but I disclaim responsibility for the follow-up effects later that day), and I was late to the game when I installed it then. > Moreover you will receive a ticket number and a notification when it’s close. This should be possible irrespective of whether tickets are opened by webform, email, phoning in, or other channels I didn't even think to mention yet. > To be honest I follow the Dima case but not your case. If I start to handle > abuse cases out of normal process it will be the mess… It is true. However, OVH appears to have somewhat of a systemic problem, and any amount of Mailop'ers writing to you or to Romain does not solve that. The normal process needs to be improved quite a bit. Amicalement, -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Curious, any one seeing fake SpamCop reports over the weekend?
On Mon, Jun 13, 2022 at 08:10:23AM -0700, Michael Peddemors via mailop wrote: > Real strange, fake abuse addresses.. Plenty of the same in the spamtraps. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Help with identifying invalid email domains
On Wed, May 25, 2022 at 03:00:19PM -0400, Omid Majdi via mailop wrote: > Hey all, > > I'm looking to see if anyone has compiled any lists of invalid email domains? > Examples of such would be typo domains and/or domains that accept all > local-part addresses such as gmai.com, gmail.co, googlemai.com, or > proton.com. If there's any resources someone could share for known invalid > domains that would be incredibly helpful. You're looking to identify spamtraps. Don't expect much help from this audience :-D -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] To Sendinblue, Mailjet, SES, ActiveCampaign, and every other
> Don't just remove the addresses from customers' lists, but remove > the customers, as they are obviously using addresses without > consent, You will probably find that just about every ESP operates a single opt-in regime. > which would be against your AUP (you do have an AUP that > requires confirmed opt-in, do you?). They probably don't. I'd also hazard a guess that 100% of the unwanted email Jarland is receiving at the moment is coming from entities generally unrelated to the matter who are being used as hapless conduits for the abuse by whoever goes around forge-subscribing these addresses. I am not particularly interested in defending the practice of using single opt-in for mailing list subscription. I am simply stating that this is likely to be the case and that your assumption that the T&C of ESPs would generally require COI is unrealistically optimistic. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is caniuseapurchasedemaillist.com down?
On Wed, Apr 27, 2022 at 11:00:46AM -0500, Al Iverson via mailop wrote: > Try https://www.shouldiuseapurchasedemaillist.com Excellent job Al. Thanks on behalf of everyone. > > (I tried to keep it brand free, not trying to sell anything there, > other than best practices.) > > Cheers, > Al > > On Wed, Apr 27, 2022 at 10:58 AM Anne Mitchell via mailop > wrote: > > > > > i need this page from time to time. > > > > > > caniuseapurchasedemaillist.com > > > > I know it's not as succinct as caniuseapurchasedemaillist.com ;~), but > > until that site is back up feel free to use: > > > > https://www.isipp.com/blog/can-i-use-this-list/ > > > > Anne > > > > --- > > Outsource your email deliverability headaches to us, and get to the inbox, > > guaranteed! > > www.GetToTheInbox.com > > > > Anne P. Mitchell, Esq. > > CEO Get to the Inbox by SuretyMail > > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing > > law) > > Author: The Email Deliverability Handbook > > Board of Directors, Denver Internet Exchange > > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > > Prof. Emeritus, Lincoln Law School > > Chair Emeritus, Asilomar Microcomputer Workshop > > Counsel Emeritus, MAPS: Mail Abuse Prevention System (now the anti-spam > > division of TrendMicro) > > > > > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > > -- > Al Iverson / Deliverability blogging at www.spamresource.com > Subscribe to the weekly newsletter at wombatmail.com/sr.cgi > DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is caniuseapurchasedemaillist.com down?
On Wed, Apr 27, 2022 at 04:15:20PM +0200, Simon Luger via mailop wrote: > Hi > > i need this page from time to time. > > caniuseapurchasedemaillist.com I love it too. Looks like MailChimp may have forgotten to pay the rent on the Digital Ocean droplet. In the meantime, for the Finnish reader, http://www.voinkokayttaaostettujasahkopostilistoja.com/ Thanks Pekka. > > > > Simon Luger > > sendeffect - mehr erreichen > -- > > WEBanizer AG > Schulgasse 5 > 84359 Simbach am Inn > Telefon: +49 (0) 8571 - 97 39 690 > > Handelsregister: Amtsgericht Landshut HRB 5177 | Ust. ID.: DE 2068 62 070 > WEBanizer AG > > Vorstand: Ottmar Neuburger > Aufsichtsrat: Tobias Neuburger > > https://www.sendeffect.de > https://www.webanizer.de > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The final death of Mailjet
On Mon, Apr 25, 2022 at 03:18:30PM -0500, Jarland Donnell via mailop wrote: > I'd like to encourage other mail providers to begin holding Mailjet > accountable for the spam they send. Today, in reaction to receiving > 1 abuse complaint per spam email sent from their platform, they > finally had enough of hearing about it: > > Reported error: 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient > cont...@mailjet.com not found by SMTP address lookup I most recently submitted a complaint on Feb 23. It was received at Google at that time. [root@mail ~]# zgrep abuse@mailjet /var/log/old/maillog-20220227.gz Feb 23 23:39:24 mail postfix/smtp[25643]: 114E710052430: to=, relay=aspmx.l.google.com[64.233.165.26]:25, delay=2.1, delays=0.11/0.02/0.42/1.5, dsn=2.0.0, status=sent (250 2.0.0 OK 1645652364 z5si683247ljz.173 - gsmtp) I would suspect that this is a case of botched Google to Microsoft migration rather than immediate proof of malicious intent. It is also noteworthy that Mailjet is not an independent operation, has not been for almost a year. https://www.mailgun.com/blog/company/mailgun-acquires-european-competitor-mailjet/ Consequently, writing to abuse@ the new owners might be a thing. I've taken the liberty of pointing this out within the club. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Russian crypto phish campaign via sendgrid to stolen Robinhood account
On Sun, Apr 24, 2022 at 11:02:42PM -0400, John R Levine via mailop wrote: > I've gotten several copies of this phish sent to an address stolen > from a closed Robinhood brokerage account. It's sent from Sendgrid, > with a link to a web host at AWS that does a couple of web redirects > to a web server at 176.113.115.238 in St Petersburg. The web site > purports to be Metamask, which is a crypto wallet. I suppose people > wth Robinhood accounts would be good targets. > > Anyone else seeing this? Yes, the Koli-Lõks spamtraps have the same. Not in great quantities, but some trickled in both yesterday and today. > > Copy of the spam here: http://spample.iecc.com/rvj/23695345 > > R's, > John -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hostkarma Black listing
>> Is there anyone with Hostkarma on this list that could assist me in >> removing an IP. I have put in several delisting requests and tried >> sending some help tickets but I have gotten nothing back. >> >> Thank you all! > > The owner and main(?) operator of junkemailfilter.com passed away a few > years ago. Someone else may have taken over the operation, but if you > don't get any other answer, that's why. Paul Lesniewski (paul@...) took over after Marc Perkel died. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid, what happens when you don't address the root problem (Indeed Phishing)
> You think we would be done with SendGrid conversations two years ago.. No such thing. > And two hours later, a phishing attempt from a SendGrid IP hit the > spam folder... > > Return-Path: > Received: from wrqvndzq.outbound-mail.sendgrid.net (HELO > wrqvndzq.outbound-mail.sendgrid.net) (149.72.45.228) Confirmed, seen here too. > From: Verify 2FA <2...@indeed-verify.com> > Subject: Indeed for Employers - Your Account Required 2FA Verification. > Reply-To: 2...@indeed-verify.com X-Entity-ID: Z9o86N06AN6V9pUxLwsPGQ== (even though "26471268" should be more than enough) > One more reason to flag all of SendGrid shared servers as spam? They're definitely the biggest ESP in our spamtraps, have been for more than a year solid. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
