Re: [mailop] too many bad IP blocked
On Fri, 21 Jun 2024, Jeff Pang via mailop wrote: today I clear up iptables rules, and run fail2ban again. in half of an hour, it blocked 1400+ IPs. $ sudo iptables -L -n|grep DROP|wc -l 1407 it seems the black ips are coming endlessly. most of the bad actions are like this one: postfix/smtps/smtpd[451948]: warning: unknown[211.184.190.87]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 I am afraid too many iptables will slow down the performance of systems. do you have any suggestion for handling this case? n.b. I don't think there's anything to worry about performance-wise. To add to what others have suggested (iptables sets and null routing), I use nftables with a "fail2ban" set, to which addresses get inserted by fail2ban. For "elegance" (as I said, I don't think performance is an issue here), I have set the "auto-merge" flag in my fail2ban set. This "compacts" addresses when inserted/deleted, so that neighboring addresses are turned into CIDR sets. Hope it helps, Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] MTA-STS errors?
On Wed, 6 Mar 2024, Michael W. Lucas via mailop wrote:
Hi,
First time playing with MTA-STS.
I have a test domain, ratoperatedvehicle.com. The mxtoolbox check says
everything exists:
https://mxtoolbox.com/SuperTool.aspx?action=mta-sts%3aratoperatedvehicle.com=toolpage
My reports from Google say they can't find it, however.
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2024-03-05T00:00:00Z",
"end-datetime": "2024-03-05T23:59:59Z"
},
"contact-info": "smtp-tls-report...@google.com",
"report-id": "2024-03-05T00:00:00Z_ratoperatedvehicle.com",
"policies": [
{
"policy": {
"policy-type": "no-policy-found",
"policy-domain": "ratoperatedvehicle.com"
},
"summary": {
"total-successful-session-count": 1,
"total-failure-session-count": 0
}
}
]
}
Any suggestions on what I messed up? Or is this a disguised policy
error?
$ dig _mta-sts.ratoperatedvehicle.com @8.8.8.8 txt +short
"v=STSv1; id=2024030501;"
https://mta-sts.ratoperatedvehicle.com/.well-known/mta-sts.txt has:
version: STSv1
mode: testing
mx: mail.ratoperatedvehicle.com
mx: www.mwl.io
max_age: 43200
Apparently "Google will only process policies with a max_age higher than 86000
seconds. Policies with a max_age of 86000 or lower will be ignored and a daily
no-policy-found report will be sent if TLS-RPT is enabled."
(link: https://www.uriports.com/blog/mta-sts-explained/)
So if you want Google to consider your policy as "valid" you shoud make max_age
86400 or higher. ¯\_(ツ)_/¯
Cheers,
Bernardo___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC processing
On Tue, 19 Dec 2023, Eduardo Diaz Comellas via mailop wrote: I'm starting to deploy DMARC records in all our managed domains, but we don't have any specific tool to parse and extract meaningful information from the reports. Do you have any recomendations? I process such reports using a shell script which unpacks, etc. the received e-mail/attachment and uses dmarc-cat (https://github.com/keltia/dmarc-cat) to provide human-readable output, which is then sent to a specific mailbox/folder, where I can read/check the reports if/when I want. For low volume this is OK (IMHO), but if you have lots of reports you want something that looks at them automatically and maybe alerts you based on the report. Good luck. -- Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
On Tue, 24 Oct 2023, Slavko via mailop wrote: Dňa 24. 10. o 4:04 Ian Kelling via mailop napísal(a): Anyone know how to monitor C-T logs? I looked around a bit and didn't see how to actually do it for let's encrypt certs. I recently installed https://github.com/SSLMate/certspotter Hard to say any opinion yet, as i install it on one my sparse machine with debian old stable, thus somewhat old certspotter version, and it is too soon to know something useful. First result i expect in next week or two, when some of my certs have to be renewed (i don't want to force that). When o tried recent debian's version of it on my desktop, it tooks minimal RAM (~30 MB) and consumes 10-30% of CPU (not permanently, but in waves), thus it is doing something. I will continue to try it... I use certspotter (# apt install certspotter, in debian 12), and it's really a no-brainer. Every time a subdomain of mine gets a new/renewed certificate, I get the notification within seconds (I also use the crt.sh RSS feed, but this is, from the point of view of the user, rather "passive" (polling), while certspotter is, "active"). The good thing is that you can monitor any domain you want, so you learn a lot about internal domains, etc. (think recon).___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GitHub DMARC inbox bounces
On Sun, 15 Oct 2023, Patrick Cernko via mailop wrote: Hi Marcel, hi list, On 13.10.23 12:13, Patrick Cernko via mailop wrote: Hi Marcel, hi list, On 13.10.23 10:55, Marcel Menzel via mailop wrote: sending DMARC reports to dm...@github.com stopped working for me since the 4th of October, anyone experiencing the same? Their (at Google hosted) inbox bounces with: Message blocked Your message to dm...@github.com has been blocked. See technical details below for more information. The response was: Message bounced due to organizational settings. same here on 2023-10-07 and -08. After that, I added them to my exclude list to avoid further dmarc reports and thus annoying bounces. I just removed github.com there again, let's see if it happens again. I got a bounce as described again this night! Anybody else here get these bounces or is it just Marcel and me? To test, I removed github.com from my DMARC-no-reporting list, and soon enough I had a bounce, so I added it again to the list. Some day they'll figure it out, I guess. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses
On Fri, 6 Oct 2023, Gellner, Oliver via mailop wrote: On 06.10.2023 at 20:19 Bernardo Reino via mailop wrote: On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote: I trust that you are applying RFC 7489 section 7.1. where appropriate. If the domain for dmarc reports is not the same as the requesting domain, you must check that the report domain is willing to accept these reports. [..] [*] for an example of a big server not doing this (i.e. not publishing the proper records) see gmx.net, where e.g. gmx.net says that reports should go to dmarcrep...@gmx.net, but the corresponding _report._dmarc TXT record is nowhere to be found. Agreed, except that gmx.net does publish _report records. Not for gmx.net itself, but this is not an external domain, so no _report record is necessary. Oops, you're absolutely right. Thank you! I had in memory that this wasn't the case (I think I even wrote here some time ago about gmx.ch not having a corresponding gmx.ch._report._dmarc.gmx.net TXT record), but apparently this is not the case anymore (kudos to gmx!) Other than that broken DMARC setups seem somewhat common among SMB. Outright rejections as in the case of github.com are at least simple to handle. Worse are receivers who stuff the DMARC reports into ticketing systems or whatever and then come after you with multiple emails about ticket creation, survey requests and reminders. +1 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses
Sorry for the additional noise, but I wrote "DMARC considers" where I meant "RSPAMD considers" :( On Fri, 6 Oct 2023, Bernardo Reino via mailop wrote: This is unrelated, but yes, I believe RSPAMD considers that when deciding when/whom to send the reports. [...] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses
On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote: On Thu, 5 Oct 2023, Bernardo Reino via mailop wrote: On Thu, 5 Oct 2023, Slavko via mailop wrote: Dňa 2. 10. o 18:34 Brandon Long via mailop napísal(a): I've raised a bug to take a look, this looks like a too broad dkim replay rule. I am not sure if that is the same, but in last two days i see these bounces from github's DMARC rua address for my DMARC reports: ** Message blocked ** Your message to dm...@github.com has been blocked. See technical details below for more information. The response was: Message bounced due to organizational settings. The latest one contains in message/delivery-status (if that helps): Reporting-MTA: dns; googlemail.com Received-From-MTA: dns; prvs=064225bada=dmarc_rp...@slavino.sk Arrival-Date: Wed, 04 Oct 2023 18:21:05 -0700 (PDT) X-Original-Message-ID: <84e154c2366c2...@primex.skk> Final-Recipient: rfc822; dm...@github.com Action: failed Status: 4.4.2 Diagnostic-Code: smtp; Message bounced due to organizational settings. Last-Attempt-Date: Wed, 04 Oct 2023 18:21:06 -0700 (PDT) I have the same issue. Unfortunately there's a lot of servers which request DMARC reports, but then outright reject them (or use an invalid address). My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing, slowly. I trust that you are applying RFC 7489 section 7.1. where appropriate. If the domain for dmarc reports is not the same as the requesting domain, you must check that the report domain is willing to accept these reports. This is unrelated, but yes, I believe DMARC considers that when deciding when/whom to send the reports. In this case, $ dig +short TXT _dmarc.github.com "v=DMARC1; p=reject; pct=100; rua=mailto:dm...@github.com; so reports for "github.com" are sent to a @github.com address, so it's not an "external destination" in the sense of RFC7489 [*] It just so happens that the MX for github.com is google, but that should not have any impact -- aside from the fact that google seems to apply "organizational settings" or policies that effectively prevent the report from being delivered, but whether this is google's fault or (in this case) github's is something that I, as a sender, cannot know.. [*] for an example of a big server not doing this (i.e. not publishing the proper records) see gmx.net, where e.g. gmx.net says that reports should go to dmarcrep...@gmx.net, but the corresponding _report._dmarc TXT record is nowhere to be found.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
On Fri, 6 Oct 2023, Slavko via mailop wrote:
Dňa 5. 10. o 9:58 Bernardo Reino via mailop napísal(a):
I have the same issue. Unfortunately there's a lot of servers which
request DMARC reports, but then outright reject them (or use an invalid
address).
My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing,
slowly.
But this is not usual SPAM with fake or misconfigured rua mailbox, it is
domain (github.com) where i send reports for long time and only last days it
returns NDR...
Yes, I also meant github. RSPAMD happens to be, in my case, the tool that takes
care of DMARC reporting.
Its settings is strange in result, as they ask report and then refuse to
delivery it.
Exactly. This happens often with servers (the two latest examples in my
logs are github.com and mailinblue.com) which use a rua hosted at google, which
then reject the messages (DMARC reports) because of a "policy that prohibited
the mail that you sent" or "due to organizational settings".
Others simply don't bother/care and use an invalid rua..
I guess that e-mail is not only getting harder for private servers, but also for
bigger ("professional") ones ¯\_(ツ)_/¯.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
On Thu, 5 Oct 2023, Slavko via mailop wrote: Dňa 2. 10. o 18:34 Brandon Long via mailop napísal(a): I've raised a bug to take a look, this looks like a too broad dkim replay rule. I am not sure if that is the same, but in last two days i see these bounces from github's DMARC rua address for my DMARC reports: ** Message blocked ** Your message to dm...@github.com has been blocked. See technical details below for more information. The response was: Message bounced due to organizational settings. The latest one contains in message/delivery-status (if that helps): Reporting-MTA: dns; googlemail.com Received-From-MTA: dns; prvs=064225bada=dmarc_rp...@slavino.sk Arrival-Date: Wed, 04 Oct 2023 18:21:05 -0700 (PDT) X-Original-Message-ID: <84e154c2366c2...@primex.skk> Final-Recipient: rfc822; dm...@github.com Action: failed Status: 4.4.2 Diagnostic-Code: smtp; Message bounced due to organizational settings. Last-Attempt-Date: Wed, 04 Oct 2023 18:21:06 -0700 (PDT) I have the same issue. Unfortunately there's a lot of servers which request DMARC reports, but then outright reject them (or use an invalid address). My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing, slowly. Cheers, Bernardo___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] DMARC reporting for gmx.ch (via gmx.net)
Hello there, I've noticed that even though @gmx.ch wants DMARC reports: $ dig +short TXT _dmarc.gmx.ch "v=DMARC1; p=none; rua=mailto:dmarcrep...@gmx.net; ruf=mailto:dmarc-...@gmx.net; fo=1" they use a @gmx.net address, which requires an external reporting authorization record (https://dmarc.org/2015/08/receiving-dmarc-reports-outside-your-domain/). However, there is no TXT at gmx.ch._report._dmarc.gmx.de (returns NXDOMAIN), so that effectively gmx.net does not authorize others to send DMARC reports for gmx.ch. If anyone here (Tobias Herkula?) is responsible for that or can ask the relevant people, I'd appreciate it. Thanks, -- Bernardo Reino ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tangent: Banks and imprint requirements in Germany
On Sat, 22 Oct 2022, Slavko via mailop wrote: Dňa Sat, 22 Oct 2022 11:12:28 +0200 Ralph Seichter via mailop napísal: I don't know of any German bank where this is the case. In my experience, banks are quite strict when it comes to account access; one always needs both athentication and authorization. Over the last month, all banks I do business with have also upgraded to 2FA, which I believe is now actually required by law. Thanks, i got one similar response off list, thus i ask daughter again, and he confirmed, that she was able to change phone number (associated with bank account) via phone (from new number) only by providing that information. Of course, we both can not to know, if it is standard or it was "good will" (please approximate that term) from bank employee only... In my experience the on-line banking security (nowadays anyways) is pretty good, due to the requirement of 2FA, etc. The "physical security", i.e. when you go to the bank/counter and want to do something is (IMHO) lower, but it does require a proper identification (password or German identification document, etc.). Obviously, the whole thing depends on whether a forgery (or a stolen document) will be noticed, and the fact that having to be there in person may already be quite a good deterrent. The weakest link is however the so-called "telephone banking", which maybe not all banks offer (but mine does), where you can do /some/ things by merely knowing the account number and a "telephone banking password", which is generally weak and available to the operator in clear text. I remember once I locked myself out (used wrong PIN in on-line banking) and had to phone to get unlocked, which required the phone password, which I had completely forgotten (because, who uses phone banking anyway?). The lady on the phone was kind enough to suggest certain concepts and numbers which refreshed my memory on the spot :) If I could I would disable that, and maybe with time banks will stop supporting this. While IANAL in the end the important thing is where the liability lies, and I'd suspect that if the bank performs some operations based only on this telephone banking (or as you say, birth day & co.) then the liability should be with the bank, but I keep getting surprised by how things work (not only here, but everywhere). Cheers, Bernardo___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On Fri, 21 Oct 2022, michael.zork--- via mailop wrote:
[...]
Here is my story:
[...]
I still didn't know what to do, so I asked again for details.
Two emails later they still didn't tell me what the exact problem was, so I
put my postal address on the website, maybe that helps. It didn't, but I got
this answer:
Die Forderung einer Anbieterkennzeichnung impliziert eine kommerzielle
oder vergleichbare Nutzung. Sie müssten hierfür unter "XXdomainXX"
noch Kontaktdaten zur "schnellen" elektronischen Kontaktaufnahme(*)
hinzufügen.
(*) Das kann entweder eine telefonische Rufnummer oder alternativ
ein Kontaktformular sein, sofern die Reaktionszeit kurz sein sollte.
[...]
That's interesting, because at least it seems to narrow down what they consider
essential in the legal notice ("Impressum"). After having whitelisted my two
servers in the last couple of days, I have removed the postal address in one,
leaving only name, e-mail and telephone number, and also the phone number in the
other, leaving only name and e-mail.
I don't expect any reaction to that, as I don't expect that they will actually
monitor websites/impressum for changes (but who knows :)
Without any more discussion another support guy whitelisted my IP.
Well Germans are not what they used to be :), so maybe that one considered your
insistence enough to whitelist you.. or perhaps the decision of when a server is
commercial or not is not /that/ well-defined for them.
Cheers,
Bernardo___
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 Thu, 20 Oct 2022, Kai 'wusel' Siering via mailop wrote: [...] Basically "Max" states that he needed to put an "simple imprint" at http://his.do.main/index.html, which made t...@rx.t-online.de whitelist his mailserver's IP. Thus, even in December 2020 they were keen on this imprint thingy; why it didn't happen with you before, I cannot tell. Fair enough. Maybe it was just luck.. [...] Since t-online.de is the only "walled garden mail domain" known – at least AFAIK? –, any email to and especially from @t-online.de should be rejected in any default configuration of any MTA. This reflects the discussed fact that one has to register one's mailserver with t...@rx.t-online.de _before_ any mail exchange can happen. It's not a "form of defamation", as Grand Taylor stated, it's the only proper local configuration for the rather special setup used at t-online.de. Our server, our rules -- that's valid too. However, I still find that Postel's law should apply, in any context, and specifically in this one. You want to run an e-mail server and don't want to be blocked, so you should (liberally) accept, instead of "being like them" and block unfairly (for some definition of fairness anyway). After all, this is what we (should) teach our kids, so I'm a bit surprised that some people are proposing (or have already implemented) doing the eye-for-an-eye (or was it a tooth?) to T-Online. *We* can do better, and we should do better ;-) Kind regards, Bernardo PS: I'm afraid that this topic might be uninteresting and/or annoying to those around here working for larger operators, who are (or should be) wholly unaffected by this, so I apologize for my contribution to the increased volume if this is the case..___ 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 2022-10-20 14:51, Jaroslaw Rafa via mailop wrote: Dnia 19.10.2022 o godz. 20:08:30 Bernardo Reino via mailop pisze: > That seems really "interesting". How does that impressum look like, which > has the magical power of transforming a private server into a "commercial" > one? What should it contain? Could you provide a link to yours? Well, now that it's public anyway :) -> www.bbmk.org So basically they require anybody who runs a mail server to put their street address and telephone number online to be publicly available??? Crazy idea. And this is the same country that banned Google Street View (probably as a single country in the world?), on the basis that pictures of individuals' houses were available online for anybody to view? Crazy idea. Yes, also to me (note: I'm not German but count as one for all intents and purposes, including taxes and, unfortunately, electricity and gas price :). I find it OK-ish to post an e-mail address (which is specific to the Impressum), and I find my own name uninteresting :). I also used an unused telephone number (the Deutsche Telekom kindly gives you 3, but I only use one). I'll never receive a call there because it's set to voicemail server-side. But I'm uncomfortable with the street address being there. As I said, I plan to make such information slowly disappear (so at least it won't be so obvious for the casual looker). And maybe to add to what Kai Siering wrote "Deutsche Telekom's policy for accessing the MXes for t-online.de hasn't changed for 10+ years". Maybe the /written/ policy has not changed, but the enforcement of the legal notice (Impressum) certainly happened just now or in the last few days. For years I've been a braver Burger hier politey asking tosa@ to whitelist me, and they did.. until suddenly they blocked me for lack of Impressum. But I'm still waiting for certain blogs and magazines to take this up. If I have time I'll write an e-mail to c't Magazine. I'm sure this requirement will be relaxed, sooner or later. So, hasta la mailbox, siempre! or something :) Bernardo ___ 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 2022-10-20 09:10, Dominique Rousseau via mailop wrote: Le Wed, Oct 19, 2022 at 01:33:04PM +0200, Heiko Schlittermann via mailop [mailop@mailop.org] a écrit: (...) (translation by me): Sorry, we only accept messages from proven commercial or similiar servers. Please use the SMTP relay of your hoster or your ISP. How is "proven" defined ? Do they use a very strict whitelist ? Or some other criteria ? From what we're gathering here, a sine qua non is that the server belongs to a commercial provider (as opposed to private/personal/whatever), and this is —by their definition— based on the presence of an impressum (or lack thereof) in the web site associated with the e-mail domain (which is in itself a bit unclear, but OK). This is in section 4.1 of https://postmaster.t-online.de/, where you also see that FcrDNS is a must, etc. The whitelist seems to be managed by them (though surely they have some pre-approved providers), and if you're not there you can, upon request, get in the list. Obviously this doesn't mean that anyone with an impressum can spam their users at will (at least I hope so), so whatever further spam measures they have will still apply. The above is what I've understood from the available experiences (including mine) and from the link quoted above. Maybe a DT representative will speak up (if needed). Cheers, Bernardo ___ 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 2022-10-20 01:40, Ángel via mailop wrote: On 2022-10-19 at 21:28 +0200, Bernardo Reino via mailop wrote: Yup. I have another server for which I have to request whitelisting.. but it's a bit more difficult because the front page of the domain is the webmail (roundcube), so I have to figure out how to inject the Impressum there. Assuming you are using the defualt skin (larry), edit skins/larry/templates/login.html and add your html link above Thanks a lot for the suggestion! I'll see if get around to doing this later today or in the weekend, and I'll keep in mind to test what happens when I "de-publish" the Impressum a few days later. Deutsche Telekom: if you're reading this: please be reasonable ;-) Good luck, Bernardo ___ 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 2022-10-20 08:48, Florian Effenberger via mailop wrote: Hello, I actually ran into a similar problem last year after a mail server migration. Here's what I documented back then in my blog: "Deutsche Telekom, respectively T-Online, by default blocks IP addresses that haven’t been used for sending e-mails to their servers for a certain amount of time. You can test if you are blocked by connecting to their mail server on port 25 – if the blocking is active, the connection will get immediately dropped with an 5xx error message, that lists a contact address to request unblocking from. To test, run the following command from your mail server: [...] I wasn't aware of the timing aspect, so thank you for this! I will prepare a cron job to send an e-mail to my @t-online.de address (which is pretty much dormant) very week or so, in case this prevents my servers from dropping off the whitelist.. Cheers, Bernardo ___ 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, Kai 'wusel' Siering via mailop wrote: Am 19.10.22 um 21:28 schrieb Bernardo Reino via mailop: On Wed, 19 Oct 2022, Renaud Allard via mailop wrote: If you try deleting the impressum, please share your experience on what happens with t-online. Yup. I have another server for which I have to request whitelisting.. but it's a bit more difficult because the front page of the domain is the webmail (roundcube), so I have to figure out how to inject the Impressum there. Once I've managed that and they whitelist it, I'll try to remove the Impressum there (it's a less critical server I manage for a friend, so hopefully he won't notice..). Hopefully I can report in a few days :) You are aware that people responsible for t-online.de do participate on this list, too? ;-) I assume that, and that's OK.. .. if only in the interests of advancing knowledge ;-) ___ 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, Kai 'wusel' Siering via mailop wrote: Which OTOH means that Deutsche Telekom is still whitelisting mailservers that comply with their request to be able to identify the other side. And which means that the subject is false, nothing has basically changed besides the response sent by Deutsche Telekom. Thank you for the update! Already some years ago I had had my server whitelisted by sending an e-mail to tosa@. Suddenly (I assume today) the IP was not in the whitelist anymore, so from my perspective something did change. In the past an e-mail to tosa@ would suffice. Now they explicitly request the Impressum.. -- Bernardo ___ 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, Renaud Allard via mailop wrote: On 10/19/22 20:08, Bernardo Reino via mailop wrote: I wonder what happens if I delete the "Impressum" in a few days, but who knows, maybe they do add some monitoring for *that* ¯\_(ツ)_/¯ If you try deleting the impressum, please share your experience on what happens with t-online. Yup. I have another server for which I have to request whitelisting.. but it's a bit more difficult because the front page of the domain is the webmail (roundcube), so I have to figure out how to inject the Impressum there. Once I've managed that and they whitelist it, I'll try to remove the Impressum there (it's a less critical server I manage for a friend, so hopefully he won't notice..). Hopefully I can report in a few days :) Bernardo___ 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, Kirill Miazine via mailop wrote: • Bernardo Reino via mailop [2022-10-19 14:51]: On 2022-10-19 14:25, Stefano Bagnara via mailop wrote: 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? It happens while connecting, so it's blocking on the IP address. Even though I'm a tiny "provider" (4 users :), I've sent an e-mail to postmas...@rx.t-online.de (note the "rx", which you need if you are being blocked from contacting the usual postmas...@t-online.de address), to let them know that their users will be missing a lot of e-mails (Germany is quite "diverse" ISP-wise). Maybe they'll reconsider (not because of my e-mail, but because of the flood of complaints that should be — surely? — arriving :). I've sent t...@rx.t-online.de an email and asked to clarify why my fullu compliant mail server on TransIP network is being blocked and what kind of problem has occured. We'll see.. We'll see... I'd say this is a net neutrality issue. Have Germany adopted some rules on net neutrality? TBH I don't think this has anything to do with net neutrality, but the term is (ab)used for many purposes and sometimes even with opposite meanings. I think this is just Deutsche Telekom going Microsoft. But instead of rejecting (or silently dropping after accepting) after DATA they block the connection itself (so at least you know what hit you and when..) To me it's a case of "their server, their rules" but also a clear case of "shooting yourself in the foot" or if my German doesn't fail me now "sich ins Knie schießen". They'll learn.. Bernardo___ 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, Jaroslaw Rafa via mailop wrote: Dnia 19.10.2022 o godz. 18:56:17 Bernardo Reino via mailop pisze: After I contacted them they told me that they only accept e-mail from commercial servers, so in my case (private/family server) I would have to add an "Impressum" (to the associated www site) in order to make it "commercial" (some logic here). That seems really "interesting". How does that impressum look like, which has the magical power of transforming a private server into a "commercial" one? What should it contain? Could you provide a link to yours? Well, now that it's public anyway :) -> www.bbmk.org BTW they replied an hour ago with: "Wir werden veranlassen, dass die Reputation dieser IP-Adresse bei unserem System resettet wird. Bitte berücksichtigen Sie, dass es bis zu 24 Stunden dauern kann, bis die Änderung wirksam wird, erfahrungsgemäß dürfte es allerdings in ein bis zwei Stunden erledigt sein." which means they'll whitelist the IP address (can take up to 24h). I wonder what happens if I delete the "Impressum" in a few days, but who knows, maybe they do add some monitoring for *that* ¯\_(ツ)_/¯ Cheers, Bernardo___ 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 19/10/2022 17:16, Renaud Allard via mailop wrote: On 10/19/22 16:10, Kai 'wusel' Siering via mailop wrote: On 19.10.22 15:55, Renaud Allard via mailop wrote: They blocked at least my non commercial mail server until I added an impressum. So, I guess they now block everyone without an impressum. But that's the status quo for several years. Question is: do they still adhere to that, or would they reject an appliction from you for a new sending IP because you're a non commercial mail server. Actually, I had to contact them and show them the impressum page to be whitelisted, so this seems at least partially manual. So, you might need to contact them for any new IP. But I hope they are smart enough to store the domain names in databases where they can verify the legitimacy in a more automated way. After I contacted them they told me that they only accept e-mail from commercial servers, so in my case (private/family server) I would have to add an "Impressum" (to the associated www site) in order to make it "commercial" (some logic here). They said once I've done that I should let them know (I just did) and they'll add the address to the whitelist. It does look like they check that manually. So regardless of the requirements or logic they may be applying, they do seem to be responsive. Cheers, -- Bernardo Reino ___ 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 2022-10-19 14:25, Stefano Bagnara via mailop wrote: 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? It happens while connecting, so it's blocking on the IP address. Even though I'm a tiny "provider" (4 users :), I've sent an e-mail to postmas...@rx.t-online.de (note the "rx", which you need if you are being blocked from contacting the usual postmas...@t-online.de address), to let them know that their users will be missing a lot of e-mails (Germany is quite "diverse" ISP-wise). Maybe they'll reconsider (not because of my e-mail, but because of the flood of complaints that should be — surely? — arriving :). We'll see.. Bernardo ___ 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 2022-10-19 13:33, Heiko Schlittermann via mailop wrote: Hello, I'm not sure how to complain and where. But I hope that here we can start a discussion again. I'm quite upset. Is this the new world? 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. … The sending IP belongs to a rented host (rented from a major German hoster). The answer he (the owner of that host) got was about like this: [...] I just tested and can confirm the same issue. My server is also hosted @Hetzner. The 554 occurs while connecting, so they really reject only based on the IP/range, which is indeed quite brutal. Hopefully this is just a misconfiguration (or a badly interpreted/implemented policy). Cheers, Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Odd DNS-cache avoidance queries (Spam Assassin / Unbound / AWS)
On 13/09/2022 07:55, Cyril - ImprovMX via mailop wrote: Hi everyone! > [...] > Here's the Unbound configuration: https://pastebin.com/Bn7B3uCv (expires in a month). > [...] > 1. The first issue is that it seems that we are querying URIBL using random lower/upper case domains. We had queries such as: - SoMeDoMaIn.cOM._custom_id.dF.URIbl.cOM - AnOtHeRDoM.ApP._custom_id.dF.UrIbL.COM - etc You have set the use-caps-for-id option in unbound: "Use 0x20-encoded random bits in the query to foil spoof attempts. This perturbs the lowercase and uppercase of query names sent to authority servers and checks if the reply still has the correct casing. Disabled by default. This feature is an experimental implementation of draft dns-0x20." 2. The other issue is even weirder. SA is trying to validate the domains by trimming the left part up to the gTLDs : - some.domain.com._custom_id.df.uribl.com - domain.com._custom_id.df.uribl.com - com._custom_id.df.uribl.com <-- wtf? Somehow, something is trying to check up to the top TLD, where it's useless. Again, I can't understand why SA would do that. This is probably unbound doing what it does, recursive resolving (from TLD all the way down). Hope that helps, -- Bernardo Reino ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Talking DOXING of spammers on this mailing list..
On Wed, 1 Jun 2022, Anne Mitchell via mailop wrote:
I *really* want to see the original email to which MDR is replying, however,
ironically, our default install of rspamd rejected it (which is saying a lot
because to be rejected by the default install you have to amass 15 points or
more...). :-\
I see that the top points were for:
DBL_SPAM (6.5)
RSPAMD_URIBL (4.5)
DCC_REJECT (2) [bulk Body=many Fuz1=16 Fuz2=many rep=71% ]
ABUSE_SURBL (1.5)
..in case that helps the original poster.
There a bunch of domains in common for the first two, but I won't paste them
in here as it will likely trip lots of spam filters.
Anne
The general recommendation to relax the filters for e-mails coming from
mailop@mailop.org, due to the very nature of the content posted here.
In my /etc/rspamd/local.d/settings I have this:
--<<--
# no spam filtering for mailop@mailop.org
mailop {
priority = medium;
from = "mailop-boun...@mailop.org";
apply {
symbols_enabled = [ ];
}
}
-->>--
which does the job just fine (you may want to tweak that if/as needed), e.g.
instead of disabling all symbols as above, you could use:
groups_disabled = [ "rbl", "surbl" ];
Cheers,
Bernardo
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact at Contabo?
On 31/05/2022 07:26, Hans-Martin Mosner via mailop wrote: Hello, does anybody have a working contact at Contabo? Mail to abuse@ does not seem to have an effect. Cheers, Hans-Martin I would try with supp...@contabo.com (and/or supp...@contabo.de) I'm a Contabo customer, but before that I contacted them at that address, and they are quite responsive (also for technical questions). Cheers, Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Thu, 5 May 2022, Alessandro Vesely via mailop wrote: On Fri 29/Apr/2022 18:24:04 +0200 Bernardo Reino wrote: On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. Sorry to be late... Note that example.com should set rua=mailto:dm...@example.com; that is, they should receive reports at their own domain. If they setup a recipient to an external domain, the latter must acknowledge that setting. I don't know if that is a requirement. But I have cases like e.g. with @discourse.org, where the rua is dmarc-repo...@discourse.org, so that would be "OK" as per your comment above. However, the MX for that domain is aspmx.l.google.com et al. which is what causes the/a problem. My last event was this very morning, with: : host aspmx.l.google.com[108.177.14.27] said: 550-5.7.1 [65.108.69.105 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. y32-20020a2ebba000b0024f06a6a250si945257lje.307 - gsmtp (in reply to end of DATA command) so that is Google rejecting the DMARC report that discourse.org ASKED FOR, because it considers it to be "unsolicited". (OK, I originally mentioned non existent addresses, but being rejected as a spammer is even worse than that, in my book). I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. There /are/ a couple of positive effects for reporters. One, for small senders, is to contribute scraping out a minimal footprint. If that "minimal footprint" ends with meaning "Google thinks I send unsolicited e-mails during the night to addresses that may or may not exist" then I'd rather live without that footprint ;-) I currently have 14 (manually added) domains in my "no DMARC reporting list". When I reach 20 I'll just stop reporting altogether ¯\_(ツ)_/¯ Cheers, Bernardo PS: I notice this is derailing off the original topic, which was the nice DMARC reflection attack.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: Heho, This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. In an ideal world, people setting DMARC records would make sure the addresses exist and work, but hey, who am I to give advice :) Cheers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from BNETZA.DE ?
On Tue, 29 Mar 2022, Glowfish Domainadministrator via mailop wrote: Even when I try to telnet the servers from a totally different network I get a connection refused: telnet 194.156.223.27 25 Trying 194.156.223.27... Connected to 194.156.223.27. Escape character is '^]'. 554 5.7.1 SMTP connection rejected Connection closed by foreign host. However I can send mail to bnetza.de from Google Mail just fine. Is there a mailadmin of the “Bundesnetzagentur / bnetza.de” around here ? Or if the error is clearly on our side – I would appreciate a hint or help with that I just tried from my home IP address (Deutsche Telekom) and the connection was rejected, but from my root server @Hetzner I could connect. So they seem to have a very restrictive whitelist? Cheers.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 reverse DNS from office365
On Thu, 10 Feb 2022, Tim Bray via mailop wrote: Hi, Is anybody else having trouble relaying email out of office365. I think they have broken their reverse DNS. Our method to trust *.outbound.protection.outlook.com 2022-02-10 09:51:46 H=(GBR01-LO2-obe.outbound.protection.outlook.com) [2a01:111:f400:7e15::200] When we receive from 2a01:111:f400:7e15::200 this reverse lookups to mail-lo2gbr01lp20200.outbound.protection.outlook.com. but when you forward check mail-lo2gbr01lp20200.outbound.protection.outlook.com. it resolves to ::1 Which is when I think exim goes `I'll ignore than DNS record` I'm just interested if anybody has the same problem. A new problem that started sometime since 2022-02-09 20:39:38 UTC. (our users don't send much email over night in UK time. I can confirm that there's something weird with their DNS with IPv6. $ dig +short GBR01-LO2-obe.outbound.protection.outlook.com 2a01:111:f400:7e15::200 $ dig +short -x 2a01:111:f400:7e15::200 mail-lo2gbr01lp20200.outbound.protection.outlook.com. $dig +short mail-lo2gbr01lp20200.outbound.protection.outlook.com ::1 Using A (IPv4) records there's no issue. Cheers.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google considers DMARC reports to be unsolicited mail :(
On Wed, 9 Feb 2022, Patrick Ben Koetter via mailop wrote: * Bernardo Reino via mailop : Dear all, I have already experienced Google ratelimiting DMARC reports every now and then, which may be OK if they want it like that.. but this is new (to me): [snip] Diagnostic-Code: smtp; 550-5.7.1 [65.108.69.105 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. e21si14404251ljg.437 - gsmtp I guess there's nothing to do, but I find this irritating.. I mean, they could just stop requesting DMARC reports instead of requesting and refusing them? :) What makes you believe they reject the content of your message and not your mail systems regardless of what it sends? So far I've never had e-mails rejected by Google, including DMARC reports (which could be treated differently than other e-mails). So my assumption is that something in the content triggered the rejection. Maybe if they check for bad IPs or domain names *within the content/body* (like many spam filters do unless instructed otherwise) then a DMARC report (or daily server logs, or messages in this list including spammer IPs, etc.) should be exempted from that, as otherwise these e-mails cannot achieve their very purpose of reporting such things. But anyway.. just sayin', in case Google may want to do something about this. Cheers, Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Google considers DMARC reports to be unsolicited mail :(
Dear all, I have already experienced Google ratelimiting DMARC reports every now and then, which may be OK if they want it like that.. but this is new (to me): Reporting-MTA: dns; katara.bbmk.org X-Postfix-Queue-ID: 3D2D71BE02E2 X-Postfix-Sender: rfc822; rep...@dmarc.bbmk.org Arrival-Date: Wed, 9 Feb 2022 07:01:03 +0100 (CET) Final-Recipient: rfc822; mailauth-repo...@google.com Original-Recipient: rfc822;mailauth-repo...@google.com Action: failed Status: 5.7.1 Remote-MTA: dns; aspmx.l.google.com Diagnostic-Code: smtp; 550-5.7.1 [65.108.69.105 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. e21si14404251ljg.437 - gsmtp I guess there's nothing to do, but I find this irritating.. I mean, they could just stop requesting DMARC reports instead of requesting and refusing them? :) Cheers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google not sending DMARC Aggregate Reports
Hello, On Fri, 8 Oct 2021, Al Iverson via mailop wrote: You're not alone. Both Google's DMARC reports and Google Postmaster Tools updates stopped, last update / last notification sent seems to be around October 3rd. I blogged about this just a few hours ago: https://www.spamresource.com/2021/10/google-postmaster-tools-and-dmarc.html I'm hearing second hand that it's a known issue and being worked on; if that applies to both DMARC and GPT, or just GPT, I'm not 100% sure, but I suspect both. Cheers, Al Iverson FWIW I have received two DMARC reports from google this night (October 9th), with "from=" So maybe it's been fixed already? Cheers, Bernardo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail putting messages to spam
On Tue, 21 Sep 2021, Jaroslaw Rafa via mailop wrote: Dnia 20.09.2021 o godz. 14:17:27 Jaroslaw Rafa via mailop pisze: I want to return to an old issue, which repeatedly happens again and again, that is, Google putting emails from me to recipient's spam folder. What's absurd, this happens not only to Gmail addresses to which I am writing for the first time, but also to recipients with whom I have previously corresponded and who marked my messages as non-spam. It even happens when I'm replying to a message I got from a Gmail user, which is totally absurd! It can even happen in a middle of an email exchange - ie. I have once exchanged a few messages with a Gmail user without problems, then suddenly one of my subsequent messages in the conversation went to Spam. Well, Gmail is a comedy :). I also manage an email account of some organization that I am a member of, which is on Gmail. Just today I found out that Gmail has dropped to Spam a few *replies from other Gmail users* (our members) to messages that we sent out from that account to them! Regular replies, to regular messages, *from Gmail user to Gmail user*. If that is not a whole new level of absurd, then what is...? You want absurd? :) : host aspmx.l.google.com[173.194.76.26] said: 550-5.2.1 The user you are trying to contact is receiving mail at a rate that 550-5.2.1 prevents additional messages from being delivered. For more 550-5.2.1 information, please visit 550 5.2.1 https://support.google.com/mail/?p=ReceivingRatePerm e10si1566563wrq.336 - gsmtp (in reply to RCPT TO command) This is Google saying "we want those DMARC reports", $ dig +short TXT _dmarc.gmail.com "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-repo...@google.com; .. but then refusing to receive them ¯\_(ツ)_/¯___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Low Volume Senders
On Mon, 20 Sep 2021, Brielle via mailop wrote: On Sep 20, 2021, at 9:05 AM, Florian Effenberger via mailop wrote: seems rspamd supports this: https://rspamd.com/doc/modules/dmarc.html (see "Reporting" section). Didn't try it myself though, I don't send reports yet. Hah, that makes it easy doesn’t it. I love rspamd - so glad I took the time to change over a few years ago. I’ll try it out and report back. I can confirm that rspamd does a fine job sending the DMARC reports :) You just have to take care of running "rspamdadm dmarc_report" with the frequency you need (I do it daily with a cronjob, but my server is really low volume..)___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] UCEPROTECT and Gmail (was Re: When RBLs go bad)
On Tue, 16 Feb 2021, Vittorio Bertola via mailop wrote: Il 14/02/2021 07:42 André Peters via mailop ha scritto: Hi, Have you guys already read this? https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html I have seen the discussion and found it fits. Will you remove UCL from your servers? I am wondering if Gmail is actually using UCEPROTECT in any way. I was just told by a Gmail user that my messages started to be delivered into the spam folder, and AFAIK the only thing that changed in the last few days is that my VPS provider (Contabo) is now listed in the UCEPROTECT level 2 list as well (not just on level 3 - apparently, they just did an upgrade to their attempts to force people into paying them money). On the other hand, my reputation in the postmaster tools panel is good, etc. - no other visible issues. I also use Contabo, which is listed (Level 3) already for a couple of weeks, but I'm not listed either in Level 1 or 2. Level 2 seems to apply when a number of Level 1's within a given subset (in my case it shows a /20 subnet) reach a certain level. It (still) does not bother me, and I (still) have not noticed any consequences (and specifically not when sending to gmail, but my volume of e-mail is extremely small (family server)) of being part of the Level 3 entry. Cheers.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] t-online.de outage?
On Wed, 10 Jun 2020, Ralph Seichter via mailop wrote: * Hetzner Blacklist via mailop: For the past few years, T-Online have been moving to a system where they block all unknown IPs. [...] This statement matches what I experienced. Freshly installed mail servers (with matching SPF entries) were unable to send email to T-Online until I contacted the e-mail address listed in the rejection message and asked for unblocking. That never took longer than two business days. FWIW this matches my experience too. After setting up a new server (with an IP not present in any known list) the first time an e-mail was sent to a @t-online.de address I received the 554 error message. I sent an e-mail (March 17th) and the response + unblocking came 6-7 hours later. Note that they don't refer to a "blacklist" (or "denylist" in newspeak..) but, in original version: "Wir werden veranlassen, dass die Reputation dieser IP-Adresse in unseren Systemen resettet wird." so they "reset the reputation" :) Scalable or not, the system works and they respond nicely and quickly. Cheers. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] mail.com rep on the list?
Hello, On Tue, 28 Jan 2020, Kenneth Vedder via mailop wrote: Was wondering if there was anyone representing mail.com on the list. It appears that I've been blacklisted and can't get a response from the usual channels. The error you show below is from gmx and not from mail.com (?) (host mx01.gmx.net[212.227.17.4] refused to talk to me: 554-gmx.net (mxgmx101) Nemesis ESMTP Service not available 554-No SMTP service 554-IP address is black listed. 554 For explanation visit https://postmaster.gmx.net/en/error-messages?ip=64.246.100.11=bip) Anyone have any advice on how to reach a real person there? I've tried a couple of different forms, but got nothing back. According to the link you received with the 554 your sending IP is on some blacklist. Unfortunately it doesn't say which. But it does tell you (cf. https://postmaster.gmx.net/en/faq-administrator#RBL) that you should contact the BL operator (and not gmx, presumably), suggesting you check at www.dnsbl.info. Did you do that? Thanks, Ken Good luck. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
