Re: [mailop] Need help with finding cause for Microsoft Error Code / IP SMTP Blocklist S3150
On Mon, 14 Oct 2024 at 11:51, Benoit Panizzon wrote: > How and where were you able to open a ticket with Microsoft? > Recently I stopped trying to deal with the support as it was a waste of time (i had to repeat the same things dozen times and in the end I never got any useful information): in rare occasion after a few loops I obtained a "mitigation" but of course this is useless if you don't know what caused the issue and you don't have issues with other providers. I guess I used this (I reach it from my SNDS homepage): http://go.microsoft.com/fwlink/?LinkID=614866 Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Need help with finding cause for Microsoft Error Code / IP SMTP Blocklist S3150
On Mon, 14 Oct 2024 at 11:20, Benoit Panizzon via mailop wrote: > 550 5.7.1Unfortunately, messages from [157.161.12.69] weren't sent. > Please > contactyour Internet service provider since part of their network is > on our > blocklist (S3150). You can also refer your provider to > http://mail.live.com/mail/troubleshooting.aspx#errors. [Name=Protocol > Filter Agent][AGT=PFA][MxId=11B9D54E88BF532F] [...] > Has anyone a clue, what might be the cause and how to resolve? > Can't help with the cause, I doubt Microsoft actually know them ;-) , but I found that I have to stop sending to microsoft using the IP for at least 24 hour, otherwise the block doesn't go away. In my case before I get the S3150 (perm error) I always get some S775 (temp error): I stop sending for 1 hour every time I see an S775 and this made the S3150 to almost disappear. I desperately tried to find the cause opening ticket to Microsoft many times in the past years, but you know you only get templated answers even when you are able to escalate the ticket. At most you get a mitigation but no one need a mitigation as if they don't know what caused the issue then it will apear again over and over again. Also I saw those errors are not related to SNDS IP color nor to JMRP reports: you can get that block for green IPs and have red IPs sending without issues. I'm not even convinced the green/red are related to the spam folder ratio. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Delivery issues with libero.it / virgilio.it (IOL)
Hi Claudio, About Libero (IOL) try to use a single connection. I got that error by using 2 concurrent connections from the same IP: you can send very fast but you can only use a single connection. I've never been able to get in touch with a Libero postmaster recently. About Yahoo from what I saw they have an hourly rate limiting that is being reset at the 30 minute of each hour and a daily limit that resets at 3 in the night (CET): the 2 limits depend on your IP reputation, so you can try delaying 1 hour for the first retries and 1 day for the next ones, until yahoo learn your IP reputation. Yahoo postmaster is here in the list. Stefano On Thu, 4 Apr 2024 at 01:07, Claudio Faoro via mailop wrote: > > Hi everyone, > > a couple of weeks ago I configured a new Postfix server, it's used > exclusively by a newsletter service with 2 subscribers. > The newsletter service has been active for more than 10 years on a very old > server running qmail. > Unfortunately, I had to decommission the old qmail server in a few days, > replacing it with the new one. It was not possible to keep the same IP > address. > I've correctly configured the SPF, DKIM, DMARC and PTR records > (mail-tester.com gives me 10/10). > The first few days, I had problems delivering mail to several providers due > to the amount of messages. I guess it's partly due to the new IP. > For example: > > Mar 30 15:37:00 mx1 postfix/smtp[2021]: 6940F7FF09: to=, > relay=mx-eu.mail.am0.yahoodns.net[188.125.72.74]:25, delay=3473, > delays=0.47/3472/0.71/0.04, dsn=4.7.0, status=deferred (host > mx-eu.mail.am0.yahoodns.net[188.125.72.74] said: 421 4.7.0 [TSS04] Messages > from REDACTED temporarily deferred due to unexpected volume or user > complaints - 4.16.55.1; see https://postmaster.yahooinc.com/error-codes (in > reply to MAIL FROM command)) > > After a few mailings, the situation seems to have stabilized, Yahoo no longer > gave me problems. > Unfortunately, a good percentage of our subscribers use an email address from > Italiaonline/IOL (libero.it, virgilio.it, iol.it, inwind.it, etc...). > Most of the emails to IOL get bounced: > > Mar 30 00:15:40 mx1 postfix/smtp[51700]: 509762617D: to=, > relay=smtp-in.libero.it[213.209.1.129]:25, delay=116950, > delays=116848/101/0.09/1.1, dsn=4.0.0, status=deferred (host > smtp-in.libero.it[213.209.1.129] said: 451 too many messages, slow down. > [smtp-22.iol.local; LIB_650] (in reply to end of DATA command)) > > The limit is triggered very quickly and it's removed after several hours. > I tried to throttle the sending to IOL addresses on Postfix > (destination_concurrency_limit = 2 and destination_rate_delay = 300s), but I > keep getting capped after a while. > I don't have much information regarding the old qmail server, but it seems > that there were not all these problems (there wasn't even DKIM and DMARC > configured!). > > I don't understand how to resolve these problems with the libero.it mailboxes > (and more generally, with all Italiaonline mailboxes). Do you have a contact > in Italiaonline who can help me? > Any info would help me, thanks in advance. > > Regards, > Claudio -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop wrote: > Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761: > to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp, > pri=5370980, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.7.28, > reply=421 4.7.28 Gmail has detected an unusual rate of unsolicited mail > originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual > rate of unsolicited mail originating The full message from Gmail gives you more hints about the problem: it may be a rate limiting for the DKIM signing domain, for the SPF domain, for an URL included in the email, for the sender and so on. E.g. the full message could be like this: 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating 421-4.7.28 from your DKIM domain [#redacted# 36]. To protect 421-4.7.28 our users from spam, mail sent from your domain has been temporarily 421-4.7.28 rate limited. For more information, go to 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to 421 4.7.28 review our Bulk Email Senders Guidelines. #redacted# - gsmtp The SPF tempfail error starts with the same words, too. The URL one have a different prehamble. I don't know how many other errors you can get, but if you want to investigate you need the full error. > It was only this message. Why don't they reject them with 5xx when they > treat the mail as unsolicited? They give you a tempfail because it is a rate limiting: so if you try later it usually will work. > It was only this mail, my server wasn't abused by spammers. > > Although, I send only a very small amount of mail to Google. Do they > use that to calculate the rate? You need the full message to make a better guess, but, for example, if Google is receiving a lot of spam with a given URL domain in the body it may start rate limiting that content from every source, including you. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Love how people use SPF records.. Just for a chuckle..
On Tue, 12 Mar 2024 at 00:01, Michael Peddemors via mailop wrote: > save.ca descriptive text "v=spf1 ip4:70.33.236.0/25 mx a > include:sendgrid.net include:thestar.ca include:thestar.com > include:spf.google.com include:spf.protection.outlook.com > include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all" > [...] > I assume someone that likes spamming set THAT one up.. there is a good > reason that SPF have a maximum DNS amount of queries.. Their record requires 35 DNS lookups to be completely evaluated :-) The "include:thestar.ca" alone uses 15 DNS lookups (I wonder if they suggest anyone to use this include or if this is a mistake from save.ca). Anything after include:thestar.ca (and also part of this included record) will be ignored and result in permerror, so their record equals to "v=spf1 ip4:70.33.236.0/25 mx a include:sendgrid.net include:thestar.ca -all". Maybe the RFC could have defined to return *fail* instead of permerror when you can detect the record will need more than 10 DNS lookups just looking at it (like this one: you don't even need to recurse into the includes to know this record requires more than 10 lookups). I don't think this is an indicator of a spammy sender: spammer are usually good at understanding how to propertly authenticate their emails. I saw similar SPF records with too many lookup and invalid hosts in many domains where the sysadmin probably saw a couple of SPF records and thinks he master SPF and fixes any deliverability issues by adding new include there, as it worked the first time. Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
On Mon, 11 Mar 2024 at 18:10, Alexandre Dangreau via mailop wrote: > I see the issue is solved, but I’m interested of the solution you found. The solution was writing to peer...@mcbone.net (the address I found in the RIPE DB for their AS). The email had also n...@ovh.net as a recipient. When they replied to me they also replied to n...@ovh.net. Today I also received a feedback from postmas...@freenet.de (he probably was not aware about my email to peer...@mcbone.net and their reply). > If an OVHcloud’s customer have any network issue, he can contact the support > team. > They know how to make network test to identify if it’s network issue (e.g. : > peering) > or other issue (e.g. : blacklist) and can escalade to the right team if > needed. Did youù > contact the support team ? If yes, please provide me the ticketID and I’ll > check what they did. Sure, the ticket number is 9397742. I closed the issue when I got the reply from freenet, including the reply from freenet. Stefano > -- /n > Alexandre Dangréau > Head of Trust & Safety > VU.Ethics & Compliance > M : +33 (0)669337320 > https://twitter.com/ovhcloud | https://www.linkedin.com/company/ovhgroup/ | > https://www.ovhcloud.com/fr/ > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
On Fri, 8 Mar 2024 at 17:47, Stefano Bagnara wrote: > > Poking a few people, this looks like a return path issue on Freenet's > > side; So they likely fnorded something on their side. > > Guess the only way to get this fixed is for them to realize the issue. > > ;-) > > I wrote an email to peer...@mcbone.net (I found it in their AS record at RIPE) I just got an answer from them that the issue is fixed. Thanks to everyone! -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
On Fri, 8 Mar 2024 at 17:18, Tobias Fiebig via mailop wrote: > Moin, > to get a bit back to the networking part of things... :-) > Poking a few people, this looks like a return path issue on Freenet's > side; So they likely fnorded something on their side. > Guess the only way to get this fixed is for them to realize the issue. > ;-) I wrote an email to peer...@mcbone.net (I found it in their AS record at RIPE) I also did some tests here: https://bgp.he.net/traceroute/ I put in the first field 194.97.8.138 (freenet NS) or one of my IPs at OVH Then in the second field I put AS13335 (cloudflare) and select one of the US probes. The traceroute to my IP works, while the traceroute to 194.97.8.138 doesn't work. This test does not even involve OVH, so I guess the OVH issue is just because OVH route traffic for freenet through Cloudflare. This is not even a generic Cloudflare-Freenet routing issue as from my office connection (italy) my traceroute to 194.97.8.138 works even if it goes throught Cloudflare, too. BTW my netwoking knowledge is very low, so I don't know if this helps identifying the issue. > So if somebody can poke netops of AS5430,... > Will try posting to denog to see if that helps. Thank you! Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
Well, I undestand you all hate OVH, but this really doesn't look like an intended block. I tested that when I log to my @freenet.de email I am not able to write emails to any domain whose DNS are hosted by OVH. I know plenty of italian companies whose domain zone is at OVH: even if their email is at Google Workspace or somewhere else they currently cannot receive emails from @freenet.de and you are telling me this is something freenet.de done by purpose beucase they didn't want OVH spam? I'll believe that once a freenet.de people will confirm it. Considering OVH is the biggest registar in europe they are not delivering email to most european domains. So, if they blocked the whole OVH ASN at their SMTP server I could even get that (even if I'm not aware of anyone else doing that), but I really don't believe they blocked bidirectional routing between 2 ASN just because freenet thinks OVH is spammy. We hardly see a similar block when there is a war between 2 countries. Stefano On Fri, 8 Mar 2024 at 14:49, Yuval Levy via mailop wrote: > > On 2024-03-08 07:48, Stefano Bagnara via mailop wrote: > > On Fri, 8 Mar 2024 at 13:04, Mark Alley wrote: > >> Have you considered they may be blocking OVH ASNs on their firewall? > > > > Well, blocking the whole ASNs even to their NS sounds something very > > unexpected. > > Extreme, yes. Unexpected? I disagree. It is just another logical > escalation step towards the inevitable, but nothing new. Think of a > collision between the internet's echo chambers and the Great Firewall: > one side wants to control what the other side receives; and the other > side wants to control what it does not receive. > > Simple Venn diagram. When the intersection between the two circles > (agreement on what both sides want to send/receive) has less net value > than one of the two separate half-moons, the concerned side may as well > block the whole ASN: the cost of sacrificing the intersection is lower > than the benefit from allowing the communication less the > filtering/sanitation cost. > > Once one side decides that it gets less benefits than cost from the > communication, the other side has three strategic choices: giving more > value; causing less cost; or accepting the disconnect. They are now at > the accepting the disconnect, waiting to see who blinks first. If > no-one blinks, the disconnect becomes permanent. > > The problem is compounded by aggregation on the two sides: well behaved > senders will put pressure on their side; the rats may abandon ship and > raid the next ISP with weak policies. Affected recipients will put > pressure on their side to remove the filter. The question is where > those pressures will burst. My hope is that someone at OVH will wake up > and mop up the neighborhood that they control. > > Personally, I am still looking for the ideal firewall: block all ASNs > unless permitted. And even after that, the next battlefields are > already in sight: wireless network traversal. > > Yuv > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
On Fri, 8 Mar 2024 at 13:04, Mark Alley wrote: > Have you considered they may be blocking OVH ASNs on their firewall? Well, blocking the whole ASNs even to their NS sounds something very unexpected. This mean any service (not only email) that is hosted in OVH (in europe is the biggest provider) thinks their domains don't even exists. Also, freenet.de users are not able to write emails to anyone having the DNS hosted at OVH (millions of domains): sounds like burning your house to protect it from thieves :-D Seems like AS5430 and AS16276 are not talking at all, but I don't know how confirm it and how to check where is the issue in more detail. > Their NS and zone seems resolvable and reachable from pretty much everything > else on the internet according to DNSchecker.org. Here you can see their NS IP is not reachable from 7 on 30 location being tested from western europe: https://www.host-tracker.com/en/ic/3/189c2804-114d-4be7-94e5-716f131bc458 So, I think the issue is more on freenet side than OVH side, but I'd need someone who knows or have powers to check. Now I also wrote an email to the noc/peer emails for both ASN. Stefano > On Fri, Mar 8, 2024, 5:54 AM Stefano Bagnara via mailop > wrote: >> >> Hi, >> >> I'm experiencing routing issues to freenet.de MX since almost 3 days. >> >> I can't even lookup the domain as I cannot reach their NS, but the >> same happens even if I try to ping their email server IP address: >> >> 194.97.8.138 >> 195.4.92.217 >> >> From my servers @OVH they are not reachable at all. >> >> I checked the IPs at https://check-host.net/check-ping and I see both >> IP pings from most places but a netherland one, hong kong and 4 >> russians sources (by comparison my own IPs are reachable from all of >> those sources). >> >> Failing traceroutes from check-host.net and from my IPs stuck at a >> Cloudflare IP: >> >> # traceroute 194.97.8.138 >> traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets >> 1 MYIP 0.373 ms 0.484 ms 0.590 ms >> 2 10.17.50.74 (10.17.50.74) 0.356 ms 10.17.50.72 (10.17.50.72) >> 0.396 ms 0.458 ms >> 3 10.73.17.68 (10.73.17.68) 0.101 ms 10.73.16.116 (10.73.16.116) >> 0.107 ms 10.73.17.70 (10.73.17.70) 0.134 ms >> 4 10.95.64.142 (10.95.64.142) 1.027 ms 10.95.64.156 (10.95.64.156) >> 0.424 ms 10.95.64.136 (10.95.64.136) 0.421 ms >> 5 par-gsw-sbb1-nc5.fr.eu (54.36.50.228) 3.949 ms 3.825 ms 3.821 ms >> 6 10.200.2.85 (10.200.2.85) 4.079 ms 10.200.2.77 (10.200.2.77) >> 71.136 ms 71.123 ms >> 7 * * * >> 8 172.71.120.4 (172.71.120.4) 4.689 ms 141.101.67.52 >> (141.101.67.52) 4.538 ms 4.578 ms >> 9 172.71.133.105 (172.71.133.105) 3.842 ms 172.71.129.237 >> (172.71.129.237) 4.226 ms 172.69.187.98 (172.69.187.98) 4.214 ms >> 10 172.71.133.23 (172.71.133.23) 5.352 ms 172.71.117.70 >> (172.71.117.70) 4.631 ms 172.71.121.67 (172.71.121.67) 4.512 ms >> 11 * * * >> 12 * * * >> 13 * * * >> >> I thought it was a peering issue, but 3 days should be enough for >> someone to detect and fix it. >> >> It doesn't look like a blacklisting issue as I cannot even query their >> authoritative NS and I can't do that even from IPs that never sent >> emails. >> >> I also checked OVH looking glass and they fail routing to freenet from >> all of their DCs: >> https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138 >> >> I also tried using OVH hosted email to write an email to a freenet.de >> domain and it resulted in a "Domain not found" error, so to confirm >> the whole OVH network can't reach the freenet.de NS. >> >> I opened a ticket to OVH but they closed it telling me the traceroute >> show the problem in outside their network (last working hop is a >> cloudflare IP). >> >> Peering/routing is not my field, so I'm looking for other people with >> problems sending emails to freenet.de and for suggestions on how/who >> to contact to fix the issue (maybe I should look for an NOC-op mailing >> list?) . >> >> Stefano >> >> -- >> Stefano Bagnara >> Apache James/jDKIM/jSPF >> VOXmail/Mosaico.io/VoidLabs >> ___ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
On Fri, 8 Mar 2024 at 13:17, Marco Moock wrote: > Can you access their website on freenet.de from OVH? No. I can't even reach their NS from OVH network. So I can't resolve www.freenet.de: but if I try with the IP, then I can't ping it. > > From my servers @OVH they are not reachable at all. > > OVH is known to host spammers. Maybe they blocked the entire AS in > their firewall. I know, but I don't think this is the case. If I go to my free @freenet.de inbox I can't write email to any recipient having their DNS hosted at OVH because of this connection issue between the 2 ASN. E.g. from my @freenet.de inbox I cannot write to my email address @bago.org because my NS is at OVH (while my email is at Google Workspace). So, if they did it by purpose because of spam I guess they blocked a bit too much :-) > > I opened a ticket to OVH but they closed it telling me the traceroute > > show the problem in outside their network (last working hop is a > > cloudflare IP). > > That is something OVH indeed can't fix. Of course it if is a blacklisting it is not something OVH can fix (or at lease, not easily). But if the issue is unwanted or a peering issue maybe someone can do something! > Maybe ask their postmaster from a public freemail service like gmx or > gmail. I wrote to postmas...@freenet.de too as not only they are not able to receive from OVH but they are not able to delivery to any domain with the DNS or email servers in the OVH network. The fact that they NS can't see each other let me think this is not something done by purpose, but I don't know how to investigate it to understand how is responsible for the issue and who can fix it. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
Hi, I'm experiencing routing issues to freenet.de MX since almost 3 days. I can't even lookup the domain as I cannot reach their NS, but the same happens even if I try to ping their email server IP address: 194.97.8.138 195.4.92.217 From my servers @OVH they are not reachable at all. I checked the IPs at https://check-host.net/check-ping and I see both IP pings from most places but a netherland one, hong kong and 4 russians sources (by comparison my own IPs are reachable from all of those sources). Failing traceroutes from check-host.net and from my IPs stuck at a Cloudflare IP: # traceroute 194.97.8.138 traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets 1 MYIP 0.373 ms 0.484 ms 0.590 ms 2 10.17.50.74 (10.17.50.74) 0.356 ms 10.17.50.72 (10.17.50.72) 0.396 ms 0.458 ms 3 10.73.17.68 (10.73.17.68) 0.101 ms 10.73.16.116 (10.73.16.116) 0.107 ms 10.73.17.70 (10.73.17.70) 0.134 ms 4 10.95.64.142 (10.95.64.142) 1.027 ms 10.95.64.156 (10.95.64.156) 0.424 ms 10.95.64.136 (10.95.64.136) 0.421 ms 5 par-gsw-sbb1-nc5.fr.eu (54.36.50.228) 3.949 ms 3.825 ms 3.821 ms 6 10.200.2.85 (10.200.2.85) 4.079 ms 10.200.2.77 (10.200.2.77) 71.136 ms 71.123 ms 7 * * * 8 172.71.120.4 (172.71.120.4) 4.689 ms 141.101.67.52 (141.101.67.52) 4.538 ms 4.578 ms 9 172.71.133.105 (172.71.133.105) 3.842 ms 172.71.129.237 (172.71.129.237) 4.226 ms 172.69.187.98 (172.69.187.98) 4.214 ms 10 172.71.133.23 (172.71.133.23) 5.352 ms 172.71.117.70 (172.71.117.70) 4.631 ms 172.71.121.67 (172.71.121.67) 4.512 ms 11 * * * 12 * * * 13 * * * I thought it was a peering issue, but 3 days should be enough for someone to detect and fix it. It doesn't look like a blacklisting issue as I cannot even query their authoritative NS and I can't do that even from IPs that never sent emails. I also checked OVH looking glass and they fail routing to freenet from all of their DCs: https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138 I also tried using OVH hosted email to write an email to a freenet.de domain and it resulted in a "Domain not found" error, so to confirm the whole OVH network can't reach the freenet.de NS. I opened a ticket to OVH but they closed it telling me the traceroute show the problem in outside their network (last working hop is a cloudflare IP). Peering/routing is not my field, so I'm looking for other people with problems sending emails to freenet.de and for suggestions on how/who to contact to fix the issue (maybe I should look for an NOC-op mailing list?) . Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
On Thu, 29 Feb 2024 at 12:09, Benny Pedersen via mailop wrote: > > I think I wrote here too early: from further investigation seems like > > the issue has gone and now those emails are not refused anymore. > > https://totaluptime.com/kb/cname-and-mx-for-the-same-host-name/ > > dont use cname for email or even mx Why? The page you reported is correct as you cannot have CNAME and MX for the same host, but I don't need CNAME and MX on the same host because the spec cleary say that the domain can be a CNAME and in that case you have to follow the CNAME before looking for the MX records. This is the main reason CNAMEs exists: isn't it? The opposite way, an MX pointing to a CNAME, is invalid according to the SPEC, but that's another thing. If you have RFC pointers about this "dont use cname for email or even mx" I'd be happy to double check this and be corrected. From https://datatracker.ietf.org/doc/html/rfc5321 2.3.5. Domain Names > For example, a domain may refer to an alias (label of a > CNAME RR) or the label of Mail eXchanger records to be used to > deliver mail instead of representing a host name. > [...] > In other words, names that can > be resolved to MX RRs or address (i.e., A or ) RRs (as discussed > in Section 5) are permitted, as are CNAME RRs whose targets can be > resolved, in turn, to MX or address RRs. So, not only they are not prohibited by the spec, but they are explicitly permitted. Do you understand something different from RFC5321? (I'm not a native english speaker, but "as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs" seems pretty straightforward). Of course I could stop using the CNAMEd domain and use my shared domain for all of my customers but this way I'd loose SPF alignment so I refrain from doing that because of some uncompliant receivers and subdomain delegation is not something 99% of my users/customers would be able to do. > and lastly cname breaks dnssec, dont do this, is tlsa not something you > care about ? I only receive bounces to those addresses, TLS is good enough. The real replies are sent to domains not using CNAMEs. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
Well, I think I wrote here too early: from further investigation seems like the issue has gone and now those emails are not refused anymore. According to the logs the issue lasted around 5 hours from 28/02/2024 07:00 CET to 28/02/2024 11:40 CET. I had no answer from their postmaster, so I don't know if they simply found the new rule was too aggressive or if it was a test and they will enable the rule in future. Stefano On Thu, 29 Feb 2024 at 10:00, Stefano Bagnara wrote: > Hi, > > we are an ESP (a very small italian alternative to Mailchimp). > > Today an italian mailvox provider started refusing our emails with this > message > > 550 5.1.0 sender rejected: > domain does not have neither a valid MX or A record > > The "e.#customerdomain" is a CNAME record that points to app.mailvox.it > and app.mailvox.it has both A and MX records. > > I guess Tiscali is checking only the A and MX records for the sending > domain without following the CNAMEs: in many years this is the first time I > see something similar and I thought that many services sending email use a > CNAME like us as the alternative (zone delegation) is a lot more complex to > be setup. > > I just wrote email to Tiscali postmaster to understand if they will > consider this "a bug in the new feature" or a "feature of the new feature", > but in the mean time I wanted to share the issue as I think other senders > use the same CNAME solution. > > We use that CNAME host in order to align the SPF authentication of emails > sent by our customers but our email are also DKIM aligned, so I could > simply use @app.mailvox.it instead of the customer CNAME in the > return-path and emails would still pass DMARC via DKIM. > > Do you know other receivers refusing emails because the sender (smtp mail > from) domain is a CNAME? > > -- > Stefano Bagnara > Apache James/jDKIM/jSPF > VOXmail/Mosaico.io/VoidLabs > -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
Hi, we are an ESP (a very small italian alternative to Mailchimp). Today an italian mailvox provider started refusing our emails with this message > 550 5.1.0 sender rejected: domain does not have neither a valid MX or A record The "e.#customerdomain" is a CNAME record that points to app.mailvox.it and app.mailvox.it has both A and MX records. I guess Tiscali is checking only the A and MX records for the sending domain without following the CNAMEs: in many years this is the first time I see something similar and I thought that many services sending email use a CNAME like us as the alternative (zone delegation) is a lot more complex to be setup. I just wrote email to Tiscali postmaster to understand if they will consider this "a bug in the new feature" or a "feature of the new feature", but in the mean time I wanted to share the issue as I think other senders use the same CNAME solution. We use that CNAME host in order to align the SPF authentication of emails sent by our customers but our email are also DKIM aligned, so I could simply use @app.mailvox.it instead of the customer CNAME in the return-path and emails would still pass DMARC via DKIM. Do you know other receivers refusing emails because the sender (smtp mail from) domain is a CNAME? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain
On Fri, 16 Feb 2024 at 05:02, Evan Burke wrote: > It sounds like you're looking for a technical solution to a non-technical > problem. This bounce code is quite rare, occurring for a fraction of a > percent of the senders in my dataset. When it happens, it's a pretty strong > sign the sender has a spam problem and needs to do some cleanup; adding > rate limiting on your end won't change that. > No, your conclusions don't match my experience. It's weird somehow people think the only cause for issues is spam :-) Turns out the issue occours also to very good senders the first time they authenticate their flow with their own domain, so the first time their email pass from being signed with the ESP dkim to being signed with both the ESP dkim and their own domain dkim (and being aligned). So, it is not about unsolicited, but about "new flow" that Google does not recognize (they probably don't get the double dkim signature to keep track of the reputation in this change). In fact the very same senders after a first time they get this error starts sending without any issue: if it was about "a spam problem" the issue would occour every time (or multiple times). This is happening to us a lot because in the past months (after the Yahoogle announce) we forced many of our customers in the 3-20K daily email to authenticate so to pass DMARC. Previously they passed SPF and DKIM but with a shared ESP domain, and not DMARC because there was no alignment, but this worked fine (and still works fine, even for big senders, even if we don't know how long: maybe this is because of the established good reputation of our shared domain). Considering the error from Google is not recognized as "special" our mta retries sending to every google mx every 10 minutes and the whole email (the error occours at ".") is transmitted 5 times per attempt. So sometimes a single email is transmitted hundreds of times before it finally gets delivered. We also have indicators that even if the emails are delayed for hours at the end they land the inbox and not the spam folder (open rates at gmail are in the 40%). Now we implemented a special MTA code that will recognize the specific error and will delay for 1 hour every email with the same auth domain of the email that received the error and we are fine: this way we still have delays in sending that email flow, but we have almost zeroed retransmissions (temp fails): this means many millions temp fail. And it was a technical solution to a technical problem :-) Also, Google acknowledged the missing domain indication in the refuse message is not expected: who knows, maybe the fact they are not able to handle the reputation transition from the shared DKIM to the additional sender dkim is somehow related to this. Another technical problem. Stefano > On Tue, Feb 13, 2024 at 9:30 AM Stefano Bagnara via mailop < > mailop@mailop.org> wrote: > >> On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas >> wrote: >> >>> On 05.02.24 14:56, Stefano Bagnara via mailop wrote: >>> >we are a small ESP and every email sent from our system has SPF+DKIM >>> >authentication from our system and most email also have a second DKIM >>> >signature (one signature with our domain, one with the domain of the >>> >sender). >>> >>> is bago.org that domain? >>> >> >> No, it's not :-) bago.org is my personal domain and does not send bulk >> emails. >> >> A Google person already contacted me and identified the logs with the >> missing dkim domain indication. I guess they consider it (the missing >> domain indication in the error) a bug but I had no updates since then. >> >> Considering the email are signed with 2 different DKIM signatures they >> told me which one the error is about, and it is the "customer one" and this >> is enough for me. >> >> Unfortunately when I move a customer from "not authenticated" to >> "authenticated" seems like Google is not able to recognize the consistent >> DKIM signature on my own domain and starts rate limiting the new additional >> DKIM signature for the customer. This is creating delay issues for some >> customer in the first days after the authentication, but I understood >> there's nothing I can do to improve this. >> >> >>> - it does not have DMARC, perhaps this is you problem? >>> >> >> No >> >> - it has some redundant SPF records: >>> >> >> I'm not aware of issues with redundant SPF records, as long as I stay in >> the 10 lookup: what are you talking about? >> >> >>> I'm just not sure if I should advise you to drop >&
Re: [mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain
On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas wrote: > On 05.02.24 14:56, Stefano Bagnara via mailop wrote: > >we are a small ESP and every email sent from our system has SPF+DKIM > >authentication from our system and most email also have a second DKIM > >signature (one signature with our domain, one with the domain of the > >sender). > > is bago.org that domain? > No, it's not :-) bago.org is my personal domain and does not send bulk emails. A Google person already contacted me and identified the logs with the missing dkim domain indication. I guess they consider it (the missing domain indication in the error) a bug but I had no updates since then. Considering the email are signed with 2 different DKIM signatures they told me which one the error is about, and it is the "customer one" and this is enough for me. Unfortunately when I move a customer from "not authenticated" to "authenticated" seems like Google is not able to recognize the consistent DKIM signature on my own domain and starts rate limiting the new additional DKIM signature for the customer. This is creating delay issues for some customer in the first days after the authentication, but I understood there's nothing I can do to improve this. > - it does not have DMARC, perhaps this is you problem? > No - it has some redundant SPF records: > I'm not aware of issues with redundant SPF records, as long as I stay in the 10 lookup: what are you talking about? > I'm just not sure if I should advise you to drop "include:spf.mailvox".it > or > replace "include:spf.void.it" with "include:_spf.google.com" > No, I need that because spf.void.it may change in future. > note that void.it also does not have DMARC and mailvox.it, while having > SPF record for "spf.mailvox.it" does not have SPF for "mailvox.it". > Everything is expected. mailvox.it does not send emails, only subdomains of mailvox.it sends email and they have SPF records. BTW none of those domains are involved in the issue I have with google :-D And here are my attempt to answer my own questions: > My questions: > 1) is it expected that the error does not report the DKIM domain but only > [ 36]? > It is a bug from Google. > 2) how much is the "rate limit"? Does the rejected attempt count in this > rate? > Starts as low as 1000/2000 emails per hour and looks like an hourly limit. > 3) when, how often, how long does Google expects we retry the delivery > after a 421-4.7.28 ? I don't know but I changed the retry schedule for those flows so to wait 1 hour when I see that error. I also think this is not about "Unsolicited rate" but simply about "rate limiting" a dkim domain they don't recognize: it is unfortunate that they don't keep trusting the other DKIM domain when they see 2 DKIM signatures and one is well known to them, but given this seems to happen once per customer we'll work around it. Stefano > > > >Since the past november we started seeing some UnsolicitedRateLimitError > >temporary error and while some of them refer to an SPF domain ( "... from > >your SPF domain [$domain$ 35] ..." ) we also see a lot of "... from > >your DKIM domain [ 36]. ..." where no domain is in brackets, but only > >the number 36. > > Google started rolling increased requirements since last year, perhaps > they applied > stricter requirements for your domain sooner. > > > >The email being tempfailed are signed with multiple keys for multiple > >domains, so I don't know what to "rate limit" (and how). > > > >Here is the full error received at the "." after sending the full body: > >> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail > >originating > >> 421-4.7.28 from your DKIM domain [ 36]. To protect our users from > >spam, > >> 421-4.7.28 mail sent from your domain has been temporarily rate limited. > >For > >> 421-4.7.28 more information, go to > >> 421-4.7.28 > https://support.google.com/mail/?p=UnsolicitedRateLimitError > >to > >> 421 4.7.28 review our Bulk Email Senders > > > >Given it is a temporary failure our system keeps retrying very often, > >resending the full message dozens times before it's accepted. > > > >Our Google Postmaster Tools (for our main domain signing every email) > >doens't show anything problematic: > >- Spam rate is < 0.2% > >- IP reputation good for every IP > >- Domain reputation is good > >- "Feedback Loop" is completely empty (we have a token for each sender but > >our sende
[mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain
Hi all, we are a small ESP and every email sent from our system has SPF+DKIM authentication from our system and most email also have a second DKIM signature (one signature with our domain, one with the domain of the sender). Since the past november we started seeing some UnsolicitedRateLimitError temporary error and while some of them refer to an SPF domain ( "... from your SPF domain [$domain$ 35] ..." ) we also see a lot of "... from your DKIM domain [ 36]. ..." where no domain is in brackets, but only the number 36. The email being tempfailed are signed with multiple keys for multiple domains, so I don't know what to "rate limit" (and how). Here is the full error received at the "." after sending the full body: > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating > 421-4.7.28 from your DKIM domain [ 36]. To protect our users from spam, > 421-4.7.28 mail sent from your domain has been temporarily rate limited. For > 421-4.7.28 more information, go to > 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to > 421 4.7.28 review our Bulk Email Senders Given it is a temporary failure our system keeps retrying very often, resending the full message dozens times before it's accepted. Our Google Postmaster Tools (for our main domain signing every email) doens't show anything problematic: - Spam rate is < 0.2% - IP reputation good for every IP - Domain reputation is good - "Feedback Loop" is completely empty (we have a token for each sender but our senders are small: what's the volume required to show up here?) - Authentication is 100% for SPF/DKIM/DMARC - Cryptography is 100% TLS - Delivery errors is shaky, most days is zero, but sometimes is 80%, because of the tempfails above My questions: 1) is it expected that the error does not report the DKIM domain but only [ 36]? 2) how much is the "rate limit"? Does the rejected attempt count in this rate? 3) when, how often, how long does Google expects we retry the delivery after a 421-4.7.28 ? Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reaching out to GMAIL
On Tue, 21 Nov 2023 at 12:54, Ralf Hildebrandt via mailop wrote: > We're running the postfix-users ML on list.sys4.de, and all over a > sudden we're being tempfailed by GMAIL: I saw something similar happening on a couple of my IPs recently. I thought Google is slowly applying more restrictive rules/enforcement: in my case the block persisted for few hours each time. What's your abuse rate on the Postmaster Tools? Maybe this is related to an abuse rate over 0.3%: https://support.google.com/mail/answer/81126?visit_id=638361648208381724-1833007315&p=UnsolicitedRateLimitError&rd=1#spam-rate&zippy=%2Crequirements-for-sending-or-more-messages-per-day - Spam rate - Regularly monitor your domain's spam rate in Postmaster Tools. - Aim to keep your spam rate below 0.10%. - Avoid a spam rate of 0.30% or higher, especially for any sustained period of time. - > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To protect > 421-4.7.28 our users from spam, mail has been temporarily rate limited. Please > 421-4.7.28 visit > 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to > 421 4.7.28 review our Bulk Email Senders Guidelines. > s8-20020adfea8800b0032fba209e8esi6123538wrm.543 - gsmtp (in reply to end > of DATA command) > > SPF, DKIM, DMARC, douoble-opt-in, valid forward and reverse DNS > records are all in place, and it's been working ok for quite some time > -- so it's a bit unclear what has changed here or what caused the > block... > > And since it's the postfix-users mailinglist, we're dead sure it's not > spam we're sending! Check in the Postmaster Tools as, even if it's hard to accept/believe, people report as abusive even emails with tickets they just bought on some online store. Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!
On Tue, 9 May 2023 at 04:10, John Levine wrote: > It appears that Stefano Bagnara via mailop said: > >Sounds like our standard senders using @e.example.com domain in their > >RFC5321 are able to deliver to Yahoo while italian municipalities > >using, e.g., @e.comune.bardolino.vr.it (so 2 more levels) don't work. > > Well, yeah, because vr.it is in the PSL. Same exact problem. What would be the fix for this case? Where should we try to add the missing SOA record? (I'm not sure we can do that, but at this time I don't even get which SOA record should be added to which host in order to fix the issue). #1 host -t soa e.comune.bardolino.vr.it e.comune.bardolino.vr.it is an alias for app.mailvox.it. #2 host -t soa app.mailvox.it app.mailvox.it has no SOA record #3 host -t soa comune.bardolino.vr.it comune.bardolino.vr.it has SOA record dns.technorail.com. hostmaster.comune.bardolino.vr.it. 1 86400 7200 2592000 3600 #4 host -t soa bardolino.vr.it bardolino.vr.it has no SOA record #5 host -t soa vr.it vr.it has no SOA record #6 host -t soa it it has SOA record dns.nic.it. hostmaster.nic.it. 2023050909 10800 900 604800 3600 I guess it is not the missing SOA at #2 because all of our senders share that step and most of them show no issues. So maybe the issue are the missing SOA at #4/#5, but this would be out of control by me or my customer (che municipality of Bardolino). Maybe Yahoo has to whitelist us somehow? I wrote them. -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Yahoo: SOA record per subdomain required?!
On Mon, 8 May 2023 at 20:50, Marcel Becker via mailop wrote: > I can't speak for the Yahoo of over a decade ago, but I can assure you that > the Yahoo of today will respond and try to help you if you actually reach out > to us having a problem delivering your mail people actually want. We think we see this SOA issues for our italian municipalities senders. Sounds like our standard senders using @e.example.com domain in their RFC5321 are able to deliver to Yahoo while italian municipalities using, e.g., @e.comune.bardolino.vr.it (so 2 more levels) don't work. (I have a lot of cases confirming both working and not working cases: the non working are all the "*.comune.*.[a-z][a-z].it"). RFC5322 domain, instead, is @example.com / @comune.bardolino.vr.it (no "e." subdomain). How should we contact you? Am I expected to fill https://senders.yahooinc.com/contact#sender-support-request using the data of my customer? In both cases (working and not-working) the "e" subdomain is a simple CNAME to an host in A/MX records: where I am expected to add a SOA record? In both cases SOA queries to the "e" subdomain will simply find the CNAME to an host without a SOA while the SOA to the remaining domain works. -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On Wed, 19 Oct 2022 at 13:32, Heiko Schlittermann via mailop wrote: > A given mailhost (ran privately for smaller entities) can't send > messages to T-Online anymore. > > 554 IP=168.119.159.241 - A problem occurred. … Do you get this error at the connection or after you transmitted the message? If you get the error after the "DATA" and "." then maybe you just need DKIM+DMARC compliance for your emails. In this case look for an old thread here: "DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)" by florian.kun...@telekom.de (Apr 6 2021) -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Timeouts to Microsoft?
Hi, Since 4 hours we are experiencing slowness (e.g. connections timing out, very slow responses), to Microsoft both sending to their SMTP and reading via IMAP, from europe (checked from 4 different datacenters in europe). Do you see the same? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)
On Fri, 16 Apr 2021 at 11:45, Florian.Kunkel--- via mailop wrote: > the requirements posted before only apply to ESPs (email service providers | > mass mailers | ... mailhosters). > Mailing lists should not be concerned as far as I can tell from our stats. > [] > that's the reason we didn't start with DMARC policy enforcement so far. > it's to gamy to adhere the domain policy without regard of the source IP you > see the message from. Hi Florian, do you have any update about this DMARC enforcement "experiment" @t-online.de ? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] USGOabuse.net?
On Thu, 30 Sept 2021 at 09:26, Thomas Walter via mailop wrote: > I have just received an abuse report from USGOabuse.net regarding an > incident that happened on July 6th and was resolved immediately: > I had an issue with usgoabuse, too, in past. They first sent to our abuse@ email an FBL formatted abuse report. This was about a single opt-in confirmation email that resulted to be unsolicited (probably part of a distributed subscription bombing, but was only a single email from our infrastructure). The email asked to simply ackknowledge the issue otherwise they could have blocked the IP. We did ack and we are sure no more emails have been sent to them, but the next day they sent a new copy of the same abuse report and this time the report said the IP was blacklisted. > They want me to acknowledge the report by going to > http://m.USGOabuse.net/_AbuseAck and ask for some strings. Otherwise > "Repeated reports regarding the same source that are unacknowledged will > eventually result in blacklisting" - which it already did according to > the summary above? > I was not sure about what was happening and I wanted to understand if there was a bigger issue I didn't identify, but the reports were from noreply addresses, so I sent an email to ab...@usgoabuse.net ab...@usgo.net ab...@usfamily.net and they promptly answered that they blacklisted my IP because one of their recipient was victim of subscription bombing and flooded by thousands of subscription bombing email and *one* of those emails were from our network. I suggested that I did not find fair to send 2 *automated* emails to an abuse department, using noreply, asking for the abuse department to acknowledge the issue and saying contrasting/confusing things (we may block if the issue is not fixed => we blocked you anyway), expecially if the abuse to be reported is a single COI request and not a malware/virus/whatelse. Months after that episode I received another similar abuse report from them: I forwarded the report to our "FBL processing agent" but I didn't ack it, as I found it was a waste of time. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Technical Contact to paddle.com mail platform operator?
On Mon, 5 Jul 2021 at 11:02, Benoît Panizzon via mailop wrote: > We have a customer who orders software licenses via paddle.com > > He should get keys via Email. But they never arrive. I also don't see > any trace of those emails in our logs. Hi had an issue with missing email from them to me. No one was able to fix it until I found the email were, in fact, delivered, but they were delivered to a wrong email address (the first one the merchant sent to paddle when they created my account and not the one I used through the merchant when I bought) and the email were delivered in spam, so I didn't see them in the wrong account. When I found this I used GDPR rights to ask them what data they had about my "old email address" (the one receiving the email) and they answered my email address was not in their system, LOL. I sent them the header of the email received 2 days before and they insisted that they sent that email to another email address (the one that should have receveid the email, in fact) but email headers don't lie. So, I don't know, but maybe they do something weird with email addresses updates, so maybe the email you're looking for have been delivered to a different email address ;-) My last 2 messages have been sent from Postmark ( mta197a-ord.mtasv.net. [104.245.209.197] and mta216a-ord.mtasv.net. [104.245.209.216] ). Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message
On Tue, 1 Jun 2021 at 21:39, John Levine via mailop wrote: > No, it's to deliver the mail that the users want. One point that bulk > mailers often miss is that, while the recipients at large providers do > not object to getting the bulk mail, they also do not really want it. I received Microsoft Office 365 invoices in the Junk folder of my untrained/verbatim Office 365 inbox, because of SmartScreen. No one likes invoices, i guess... -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Registered @ Microsoft JMRP - blacklisted without feedback received
We recently saw that "S3150" on 3 IPs part of 3 larger netblocks. For all of them we opened a ticket and they "mitigated the IP": I tried collecting more info to no avail, of course :-( . Weird thing is at least one of them has always been *green* on SNDS and had not abuse reports at all in the recent months. That IP is part of a 9IP shared pool, so sending the same emails of the other neighbour IPs and it is the only one that was blocked with that error. That IP was a low volume IP (200-400 daily email) and I randomly picked few emails from the days before the block and I have not been able to identify spammy emails. I asked in the ticket if they could give some hint about the issue as I can't find spammy emails, I didn't receive abuses and SNDS says everything was good before (and everything is still good for the twin IPs) but they simply mitigated and ignored my questions. So, +1 to your questions. Stefano On Tue, 11 May 2021 at 14:07, Benoit Panizzon via mailop wrote: > > Dear List > > One of our main smtp outbound ip addresses is blocked by microsoft. > > host outlook-com.olc.protection.outlook.com[104.47.10.33] said: 550 5.7.1 > Unfortunately, messages from [157.161.12.84] weren't sent. Please > contact > your Internet service provider since part of their network is on our > block > list (S3150). You can also refer your provider to > http://mail.live.com/mail/troubleshooting.aspx#errors. > [DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com] (in reply to MAIL > FROM command) > > I checked our JMRP entries. This IP is listed as one of our > mailservers. The complaint rate is < 0.1% but it had 2 'trap' hits and > is in status red. > > Our abuse desk email address is registered for the ARF feedback loop > for the ip range in question. > > We usually get a lot of feedback loop emails, mostly false positives of > Mirosoft users mixing up 'junk' with their trash folder or similar, or > moving all their old mail to 'junk' causing an avalanche of complaints > being sent. I opened several cases with Microsoft about this, but never > got any solution offered (as a sidenote rant) > > But no, there were no complaints about: 157.161.12.84 received. > > Does anyone know, how to get hold of the emails that caused this > blocking? > > Mit freundlichen Grüssen > > -Benoît Panizzon- -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received
On Wed, 12 May 2021 at 05:08, Michael Wise via mailop wrote: > S3150 is throttling. > Open a ticket and ask for a more realistic hourly/daily throttle limit. Can you confirm? This is weird because SMTP error is: "550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [DB8EUR05FT023.eop-eur05.prod.protection.outlook.com]" The SNDS message in the "View IP status" was: "Blocked due to user complaints or other evidence of spamming" Also, the IP was unable to send a single message for days until the mitigation and the message volume for the days before the block was very low (<500 messages per day). It really didn't look like "throttling", but the next time it will happen I'll try that request to the support. -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received
On Tue, 11 May 2021 at 19:31, Michael Wise via mailop wrote: > JMRP doesn’t send every email reported as spam to the sender. > Last I heard, it was 1 in 1,000 or some such. > This is to prevent listwashing, as should be obvious. But what about SNDS "Complaint rate" and "Trap hits"? Are they about all of the reports you collect or about the 1/1000 you send via JMRP? In my case there was nothing at all in SNDS (green , complaint <0.1%, no trap hits for every day in the SNDS history), but still I got that S3150. I've been mitigated when I opened the ticket but I have no clue what was the issue so I can't fix anything. If you have abuses that you don't want to shared (and I understand the listwashing issue) I would expect you to put the counters in SNDS anyway: am I wrong? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Outlook domain here.
On Thu, 29 Apr 2021 at 11:14, vsai--- via mailop wrote: > Outlook is blocking mails that are auto-forwarded from my domain. Open a ticket here: http://go.microsoft.com/fwlink/?LinkID=614866 PS: email forwarding nowadays is a PITA and maybe there's no fix to your issue but stop forwarding. -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid is giving others anti-abuse/security advice? Wow!
On Thu, 11 Feb 2021 at 18:49, Rob McEwen via mailop wrote: > These questions! WOW! IS THIS FOR REAL? Don't get me wrong, I like Len > Shneyder > and I think he's a good person TRYING to do the right thing - but - > considering what is coming > FROM SendGrid in recent years, is this the right time to be giving OTHERS > anti-abuse/security > advice? Just... wow! I think they should instead consider trying to "lead by > example". > The world would certainly become a MUCH better place! > https://martechseries.com/mts-insights/tech-bytes/len-shneyder-twilio-sendgrid/ I didn't read anti-abuse and security advices in the article. He's just talking about how DMARC evolved and the role of social engineering in phishing. He's not even trying to let people guess Sendgrid is good at preventing abuses. no "Wow" here :-) Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is it something to worry about?
On Thu, 21 Jan 2021 at 18:16, Jim Popovitch via mailop wrote: > > Maybe you'll grasp the issue only when they will list Ramnode :-) > > Or maybe you'll be happy to pay or to move to another ASN until they catch > > up... > > You seem to be under the assumption that uceprotect is just looking for > providers to list. I think, and I know, that Ramnode is a responsible > hosting provider. They take abuse report seriously, and act swiftly. > If you read the details about the ASNs that uceprotect list, it's clear > that those ASNs do not. No assumptions here: http://www.uceprotect.net/en/rblcheck.php?asn=3842 "ATTENTION Increased Listingrisk" OVH was in "ATTENTION Increassed Listingrisk" until UCEPROTECT lowered 10 fold their thresholds, so I wouldn't bet you are safe there. Let's say you chose an almost shady provider :-) Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is it something to worry about?
On Thu, 21 Jan 2021 at 17:37, Mary via mailop wrote: > Linode blocks port 25 on all new accounts/servers. You need to talk to them > and explain who and what you are, before they open it manually for you. But this was not enough to prevent them being listed in level-3: http://www.uceprotect.net/en/rblcheck.php?asn=63949 217 level-1 in the last 7 days on 510.000 IPs. I see Oracle is in level-3 too: http://www.uceprotect.net/en/rblcheck.php?asn=31898 267 level-1 in the last 7 days on 1.2 millions IPs. I guess most small ASN are not in level-3 just because of the "at least 10 level-1" requirement. Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is it something to worry about?
On Thu, 21 Jan 2021 at 15:04, Jim Popovitch via mailop wrote: > > "Pay us for protection", when it really means "pay us or we'll [break > > your knees|set your house on fire|break your windows...]" isn't > > insurance, and can get you arrested. > > Neither of those situations describe the reality of what uceprotect is > doing. They are saying that if you choose to operate in a shady area, > they will, for a payment, whitelist your address so that you can send > email. Historically, email delivery was always tied to knowing who the > sender was. This has been going on for decades, even with folks like > Barracuda. It's never been about the $$, it's always been about > identifying the responsible party. > This make me think to the "First the came..." thing: saying that around 1 million OVH customers *chose* to operate in *shady area* is a strong statement. Maybe you'll grasp the issue only when they will list Ramnode :-) Or maybe you'll be happy to pay or to move to another ASN until they catch up... Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On Wed, 20 Jan 2021 at 20:05, Simon Arlott via mailop wrote: > On 20/01/2021 10:50, Stefano Bagnara via mailop wrote: > > I'm looking for brainstorming and updated industry "standards" from > people > > handling outgoing SMTP services or ESP exporting APIs to "request > > subscriptions" (confirmed opt-in). > > How about a web-based process to confirm opt-in? > > Domains could opt into it by a DNS TXT record providing the URL of a > confirmation service. This would function something like OpenID and the > result would be a confirmation or rejection of the subscription. > OpenID itself would already work, I guess: in fact some of our users already skip the confirmation email using the "register with google" function for @gmail.com users. Of course a DNS method to let domains opt-in to such a generic system would be cool, but unless we think 100% of domains will adopt openid we'll still have the subscription bombing issue around, for every form not using this "new method" and every recient on a domain not using this method. So I like your proposal, but I was looking for best practices to deal with what happens now: forms being abused to fill email inboxes of innocent victims. It would take time to be adopted but it would put an end to "enter your > email address" forms accepting anything that is entered. > I think we'll be able to see something similar only if browsers directly implement some kind of openid support to deal with user/profile management more easily. Considering this is not happening for website authentication I doubt the confirmed opt-in world will push this ;-) Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] subscription bombing prevention best practices
Hi all, I'm looking for brainstorming and updated industry "standards" from people handling outgoing SMTP services or ESP exporting APIs to "request subscriptions" (confirmed opt-in). Not every website uses CAPTCHA and also webforms using CAPTCHA are being abused as even reCAPTCHA have been cracked by some botnet. So, we implemented per-recipient "antiflood" measures and sender throttling, we implemented a distributed near-real-time "recipients black list" in order to identify victims across our infrastructure ASAP and stop the flow. We also implemented some smart solution on the webforms we directly manage with different CAPTCHAs optionally proposed depending on internal and public blacklists of abusive IP/networks and webform filling behaviours: this works fine, but this is only a part of the outgoing flow and we can't do the same on transactional requests submitted via API or sent via authenticated SMTP. We require transactional email to provide us the IP of the user that triggered the email, so we can use our blacklists for them, too, but in this case we can't provide a CAPTCHA in an API or the SMTP conversation, so balancing false positives and false negatives is harder. The bigger the infrastructure the bigger the dataset of abuses adn the more efficient this kind of blacklists works, that's why IP blacklists have been made public and "shared", but I guess a "current subscription bombing victims DNSBL" does not exists and is not even easy to think how it could work at a global scale. Of course one option is to get in touch with every single sender, as soon as we recognize a single request as subscription bombing and explain them how to change their website in order to protect it but this is a big PITA considering most time they use CMS they don't even understand, and because the user is multiple steps away from us (whitelabel services and resellers), but before taking this path I preferred to ask here. One of our transactional IPs have been recently blacklisted by one provider because of a *single* "subscription confirmation request" transactional email received by one of their recipients targeted by a subscription bombing issue. The protections on our side didn't trigger as it was a single request from a clean IP for a recipient we never seen before and there was nothing suspicious in the request to decide to block it. I don't care of that specific blacklisting, but I'd like to be responsible and understand what most of us (postmasters) expect from each other in the real world (where a system with 0 false-negatives does not exists). How do you deal with this issue? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is it something to worry about?
On Wed, 20 Jan 2021 at 11:54, Jim Popovitch via mailop wrote: > For me, it's "appreciate never seeing those emails". I outright block > level 2 and level 3, and high score level 1. I've been doing that for > years now and have never seen a reject log message that wasn't already > listed in Zen, Sorbs, or Psbl. > If this was true then it would be pointless to use UCEPROTECT if you already use Zen, Sorbs, Psbl ;-) E.g: OVH is currently in UCEPROTECT level-3, I have a few IPs there, none of them is in Zen, Sorbs, Psbl, but, of course, are in UCE L3 right now. Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Automatic abuse reports from Simply.com
Hi all, we received few automated abuse reports from Simply.com. The abuse report is an email from "Simply.com abuse team < abuse-rep...@robot.simply.com>" with subject "Abuse report for #IPredacted# (#Providername# / #ASNUMBER#)" > Hi > > This is a complaint regarding spam received from #IPredacted# / #hostredacted#. > Mail originating from this IP, has actively been marked as spam/junk by the receiver. > > We ask that you take immediate action against the offending IP-address. > > For forensic purposes, the offending email is attached to this mail (along with other > report > formats). Below are some key headers from the mail: > > Date: #redacted# > Message-Id: <#redacted#> > From: <#redacted#> > Return-path: <#redacted#> > > #IPredacted# has received degraded delivery-reputation as a result of the report. In one case the message terminated with a > For good meassure, the List-Unsubscribe URL in the mail has already been triggered by us. The "weird" things are 2: 1) at least 2 abuses have been sent also to the abuse desk of a different datacenter from the one from which the email have been sent. I'm not sure but it seems they got in touch with the abuse desk of the datacenter hosting the website connected to the return-path of the email (not even it's MX, but the IN A, but maybe something else, I only have a couple of sample to make my guess). 2) one of the abuses was reporting the transactional email confirming to the recipient his unsubscription was completed, but the unsubscription have been triggered programmatically by them: I guess that their user that didn't unsubscribe from the email is surprised by the "unsubscription confirmation" and report it as abusive. I checked the logs and sounds like they automatically did a GET request to the List-Unsubscribe url and the a POST request to the List-Unsubscribe url via the "List-Unsubscribe-Post" protocol we support. I understand the ratio of a similar behaviour but I was not expecting the list-unsubscribe or the list-unsubscribe-post could be triggered without the recipient asking explicitly from unsubscription. Of course their server their rules, but I'd like to know if other abuse desks started receiving this kind of automated simply.com reports and what's your opinion about this practice. In the end for (still under investigation) 2 emails sent to their users we received like 8 abuse reports, some directly, some through the abusedesks of our datacenter, some for the original email and some more for the unsubscription confirmation email, so I'm guessing if your abuse desks are flooded by this or there's something so bad about those 2 emails (again, under investigation, I can't tell by looking at the content and I'm waiting for answers from the sender). Sounds like this kind of automation belongs to FBL streams, but I'm here to hear your opinions! Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SNDS "No data for specified IPs on this date" for the last 3 days
for the past 3 days SNDS show "No data for specified IPs on this date": does it work for you? (I can see data for the previous days) Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Attention Michael Wise - need your assistance
On Thu, 18 Jun 2020 at 13:00, Abuse via mailop wrote: > It is clear, but what must we do when the front door is closed too? > I used the Support Funnel but didn't get any responses, not even the first > response from the robot giving me the SRX#. We use an outlook.com/hotmail.com email address to open requests to microsoft services as they often had issues delivering email to our own business domain. So if you didn't try yet, you may want to try this way. Of course this won't fix the issue with their funnel ignoring you after 2-4 templated replies, but maybe will fix your current issue. Stefano > It is not a spam classification issue, I have checked the postfix logs and > found no email coming from @css.one.microsoft.com. > Same problem to add an IP to the SNDS program : the status remains "pending > initial verification" (since Friday) because Microsoft doesn't send the > validation email. > Important detail: all these problems occur with IPs beginning with 212.83, > which suddenly all got blocked overnight. > > Thanks. > Franck Schwartz > OXEMIS > > De : mailop [mailto:mailop-boun...@mailop.org] De la part de Michael Wise via > mailop > Envoyé : vendredi 5 juin 2020 23:45 > À : mailop@mailop.org > Objet : Re: [mailop] [EXTERNAL] Re: Attention Michael Wise - need your > assistance > > > For OLC, aka "Hotmail" issues... > > You know the answer to that, Al: No. > > Now if something is broken with the process, like no follow-up with the > automatic mitigation, or if it's an issue with Office365, I can see what I > can do, but for, "Why can't my IP be unblocked for sending to Hotmail" ... NO. > > > > I get spanked for it. > > So no, for those sorts of issues, no, I am not an escalation point. > > There is *NO* escalation point outside of the Support Funnel, which if one > has an SRX# already, one is already in. > > I can't handle escalations for a service that has half a billion customers, > sorry. > > > > Not happening. > > Doesn't scale. > > There is no secret back door person who can unblock stuff. > > And if one attempts to appeal to Senior Leadership … we may just get a > request to block the petitioner at the edge. > > There is no, “Appealing Unto Caesar”. > > > > Aloha, > > Michael. > > -- > > Michael J Wise > Microsoft Corporation| Spam Analysis > > "Your Spam Specimen Has Been Processed." > > Open a ticket for Hotmail ? > > > > -Original Message- > From: mailop On Behalf Of Al Iverson via mailop > Sent: Friday, June 5, 2020 2:20 PM > To: mailop > Subject: [EXTERNAL] Re: [mailop] Attention Michael Wise - need your assistance > > > > Hey Michael, > > > > Are you an escalation point for Microsoft issues? > > > > Is Mailop? > > > > On Fri, Jun 5, 2020 at 3:58 PM Rauf Guliyev via mailop > wrote: > > > > > > Hey Michael, > > > > > > I haven't gotten any response from you either (did my emails end up in the > > Spam folder? ;-) and there is nothing with the cases I have submitted > > either (SR1500907063 and SR1501411372). I'd appreciate a response. > > > > > > Thanks, > > > Rauf > > > > > > On Fri, Jun 5, 2020 at 1:42 PM Marc Goldman via mailop > > wrote: > > >> > > >> Hi Michael, > > >> > > >> I sent you an email the other day (that may have been overlooked) > > >> > > >> Have a case (SRX1502275554ID) that I asked you to check on for me that was > >> denied mitigation even though we just took over this 1 IP a week ago. > > >> > > >> You can contact me off list for anything you need. > > >> > > >> Thanks! > > >> > > >> Marc Goldman > > >> > > >> ___ > > >> mailop mailing list > > >> mailop@mailop.org > > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchi > > >> lli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02% > > >> 7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b > > >> 4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342& > > >> ;sdata=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3D&reserved= > > >> 0 > > > > > > ___ > > > mailop mailing list > > > mailop@mailop.org > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchil > > > li.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02%7C > > > 01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7 > > > C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342&sda > > > ta=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3D&reserved=0 > > > > > > > > -- > > Al Iverson // Wombatmail // Chicago > > Song a day! > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wombatmail.com%2F&data=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342&sdata=2G0X5pEAhqgQwHFRlFIwbK0utpnIE89Lt2AV4I0%2Bdzs%3D&reserved=0 > > Deliverability! > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspamresource.com%2F&data=02%7
Re: [mailop] Which ESP forces double opt in?
On Mon, 8 Jun 2020 at 11:33, Laurent S. via mailop wrote: > Which ESP does 100% (double/confirmed) opt in? > > I am looking for an ESP that will, in every case, send a confirmation > link without ever trusting their clients about the consent status of > lists they import? AFAIK no one. You can find ESPs that are forcing confirmed opt-in for emails collected using their forms (instead of allowing or defaulting to single opt-in). Some of them don't even require "consensus based mailings": many of them require consent in their ToS but they trust the customer unless they have something to not believe him. > I am aware this means some recipients might never click the link and get > another 2nd mail. I am also aware this doesn't block every abuse, as > Laura mentioned (I've seen those too): I'm not sure this would be a great idea as sending a "massive single-opt in request" is anyway a massive email. An opt-in request email should be sent only when the user just compiled the form. So, you have 3 kinds of lists: 1) spam lists: the ESP would send the opt-in email to all of them and this would be spam anyway. 2) single-opt-in-lists: the ESP would send a massive email (the confirmation request) and for some of them this will be spam for some other ignoring the message this will mean stopping receiving something they asked to receive) 3) confirmed opt-in lists: like #2 but only the bad parts. IMHO - if an ESP has a way to understand the customer will do spam then they should not send anything, not even a reconfirm email. - otherwise once they send their first email the ESP will collect some data and usually detect a spammer sender better than sending a reconfirm email. If every ESP requested a reconfirmation email customers would be stuck in their ESP and every ESP could increase prices 10x as customers will never accept to reconfirm their whole already confirmed lists just because they don't want to accept their new ESP prices. Spammers, instead, would happily load their scraped/purchased lists to every ESP, running a subscription bombing to their lists and using each ESP against the parts that confirmed the opt-in on that specific sender. Furthermore forcing COI is not enough for a real consent-based mailing: the ESP should also require reconfirmations for every email that has not been mailed for more than 6-12 months and maybe they should also require reconfirmation when the sender email changes or the contents for the messages are changed or the mailing frequence changes (as consent is not just a "yeah, drop whatever you like in my mailbox"). One of the worst customers we kicked for spam was in fact using confirmed opt in but the users were not really asking him to receive the emails he finally sent them. He did a lot of "win an ipad" forms and then redirected the users to our COI forms: then he was sending them car insurance or easy credit access or anything else. Technically this may be COI, but without a real consent. So COI would not solve ESP issues anyway. So if you think that enforcing COI will give you a better reputation ESP then I'd reconsider this. So, I'm a great COI fan (IMHO "single/unconfirmed opt-in" is almost equal to "no opt-in"), but I'm not sure that expecting ESP to force reconfirmation so to only send COI emails would really fix any issue. I know you asked for a list and not a COI discussion, but I think/hope the above explains why you probably won't find such a list. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine
On Tue, 26 Nov 2019 at 14:30, Benjamin BILLON via mailop wrote: > ItaliaOnline is rolling out new rules, including the necessity of having a > DMARC record (and also a valid DKIM signature), among other things. > I believe those kind of delivery placement (on p=none) is a side effect of > what they're trying to do. UPDATE: sounds like since yesterday everything came back to normal and email are not marked as spam any more for a failed dmarc check with p=none. Now the DMARC header correctly says: "X-IOL-DMARC: fail_monitor con il dominio msn.com" So, I guess you were right and it was an unwanted side effect. Thank you, Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine
On Tue, 26 Nov 2019 at 14:13, Paul Smith via mailop wrote: > On 26/11/2019 12:41, Stefano Bagnara via mailop wrote: > > I don't know if ItaliaOnLine postmaster follow this list and if they > > consider this new behaviour a feature or a bug, but I wanted to share > > this finding/news with you. > > > > What do you think about this? Do you know other providers making this > > "deliberate guess"? > > It's bad for an ISP to do that. 'p=none' is often used for the case of > "we've just started using DMARC and don't know if we've got it set up > correctly yet", so treating it as p=quarantine is going to lead to lots > of false positives. > > On the other hand, if this is JUST for mail from msn.com, they may have > decided that that domain is established enough that hopefully the admins > know what they're doing, so may have an exception to treat mail FROM > THAT DOMAIN as p=quarantine (similarly with gmail.com, which also has > p=none) My test confirmed it happens also with one of my own domains where I activated p=none as a test. Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine
Hi all, We noticed that since 3 days, ItaliaOnLine is delivering to Junk every email failing a DMARC check, even when the sender domain publish a p=none rule. You can check the "reason" in the headers: "X-IOL-DMARC: fail_quarantine con il dominio msn.com" This is expected for p=quarantine rules, but unexpected for p=none rules, but this is happening for msn.com, gmail.com and less common domains using p=none, too, whenever the DMARC check is failed. I don't know if ItaliaOnLine postmaster follow this list and if they consider this new behaviour a feature or a bug, but I wanted to share this finding/news with you. What do you think about this? Do you know other providers making this "deliberate guess"? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Hotmail delivery issues
On Sun, 17 Nov 2019 at 19:22, Jan-Philipp Benecke via mailop wrote: > currently we've delivery problems to hotmail/outlook/... O365 looks good. > SNDS shows us just red for all our IPs since end of September. > We haven't changed anything neither some crappy mailings nor new spamming > customers. > We've done, with our abuse department, also a random review of the mailings. > No results. > Our complaint rate is below 0.1% and just a few spamtrap hits, but compared > to the sending amount this is minimal. I never had confirmations from Microsoft, but in my experience the complaint rate provided via SNDS/JMRP is almost useless: I speculate that when your IP have a low reputation (or maybe when the IP is red/yellow) for Microsoft, then they won't send you the FBL or maybe they only send a percentage based on reputation. In fact I guess Microsoft doesn't send all the complaints collected to anyone: we always saw FBL/open rate much lower (half or less) than other FBL enabled providers. Also, I see our "worst IPs" are the ones for which we receive less FBL from Microsoft: in fact we use FBL from other providers to identify bad senders because microsoft seems to send us only FBL from good senders (that's weird, and probably more complex than this, but this was my "take away"). I also "guess" the whole thing slightly depends also on the network you use and maybe some large IP class (or maybe ASN level) reputation: what is your range? where are the IP "hosted" (routed)? I say this because we had an IP range sending in "round robin" the same emails of another IP range and one of the 2 turned red in July and we had no way to understand why: we tried anything and we slowling stopping using that range for microsoft (same emails from the other range are happily delivered and the IPs are always green). How do you allocate IPs? Are they shared-IPs or dedicated ones? > We do not have a clue what this has caused. > I've already contacted the deliverability support (multiple times), but more > than "do not qualify for mitigation at this time" or "At this point, I would > suggest that you review and comply with Outlook.com's technical standards." > as a reply i do not get. It is just ticket ping pong. Same here: I bet they also tells you it's "based on the recommendations of the SmartScreen® Filter" and "Because of the proprietary nature of SmartScreen® and because SmartScreen® Filter technology is always adapting and learning more"... "it is not possible for us to offer specific advice". I never understood how much they can really "debug" SmartScreen decisions: for sure they don't share a single bit about them. The only technical recommendation I can give is: make sure your emails pass a "SenderID-PRA auth check" (change the SPF for the mime-from domain or add a "Sender" header using the same domain you use in the return-path so to fallback to "simple" SPF): everything failing this check will go to Junk and bring you to the "yellowish" side of SNDS and the more your IPs stay Yellow, the more your range is at risk of this kind of "range block" (check "X-SID-Result" and "auth:" in the "X-Microsoft-Antispam-Mailbox-Delivery" headers) Please note I'm just speculating as no one from Microsoft ever answered me anything useful to identify issues nor confirmed my speculations (the only interesting things came from Micheal Wise, here, but of course we can't expect him to check every single issue that is not handled by Microsoft ticketing staff). One more thing I "fear" causes issues with Microsoft is engagement based sending behaviours: when you stop sending to inactive users then your open rate will improve, but your abuse rate will raise too and maybe "smartscreen" doesn't like this. I evaluated this thing because we started collecting issues with Microsoft when we started suggesting/educating/forcing customers to slow down sending to inactive users (on the other side, Gmail liked this a lot). Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail Postmaster IP reputation shift on July 2nd
On Fri, 5 Jul 2019 at 10:17, Mathieu Bourdin via mailop wrote: > We just saw that Gmail Postmaster’s Tools shows a very unusual amount of our > IP’s as « bad » in the graphs. > Domain reputation seems unaffected, but basically we see around 50% of our > IPs for July 2nd and 75% for July 3 going from green to red. > I saw no changes in sending habits from the various customers I checked (as > they all have dedicated IPs it’s fairly straightforward). I can confirm the same thing from July the 2nd and we are a small italian ESP. We (our customers) never had deliverability issues with Gmail. Openrate (30%+) does not seem to be affected. Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
