According to reports, any query for *.spamcop.net resulted in an A reponse to a
landing page (there were no NXDOMAINs), so when not specifically checking for
127.0.0.2 but just for a positive reply, any query would be seen as a hit. As
such, the incident would have only impacted misconfigured
Moin,
on 02.02.21 03:34, Noel Butler via mailop wrote:
>
> postfix reported nothing, so must check for appropriate response codes, and I
> certainly hope it checks 127.* not just .2, as we are not to know every
> DNSBL's response codes.
>
The point was to check the _actual_ _response_ instead
Moin,
on 19.10.22 13:33, Heiko Schlittermann via mailop wrote:
I'm not sure how to complain and where. But I hope that here we can
start a discussion again. I'm quite upset.
Personally I doubt any discussion on whatever mailing list would make Deutsche
Telekom change their mind about this.
On 19.10.22 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
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
On 20.10.22 18:50, Grant Taylor via mailop wrote:
On 10/20/22 10:32 AM, Jaroslaw Rafa via mailop wrote:
I consider this being purely a connectivity thing.
Except that it's not a /connectivity/ thing. At least not on any OSI layer.
The rejection that you are advocating for is sent across /
On 20.10.22 17:31, Bernardo Reino via mailop wrote:
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)
On 19.10.22 18:21, Gellner, Oliver via mailop wrote:
It looks more like t-online.de blocks incoming connections from the whole
world, except from a list of IP addresses they maintain internally. To get
added to this list you have to a) contact them manually and b) fulfill
arbitrary rules that
On 19.10.22 14:28, Bernardo Reino via mailop wrote:
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).
No, it isn't. It's the way Deutsche
On 19.10.22 17:49, Carsten Schiefner via mailop wrote:
Having read up the entire thread now, I wonder if this issue might be worth
raising with Germany‘s federal regulator for (inter alia) postal and telco
services, BNetzA.
I wonder what would happen if the owner of a 20-storey apartment
On 19.10.22 18:25, Michael Peddemors via mailop wrote:
On 2022-10-19 08:38, Carsten Schiefner via mailop wrote:
Grant & all -
if it‘s a .de domain name one does not need a privacy service any longer since
2018(?) as the GDPR (or its interpretation) mandates that holder data must not
be
On 19.10.22 18:16, Marcel Becker via mailop wrote:
Just like nobody can force you to accept any emails from any sender into your
systems, you can not force others either.
Might be true in general, but the t-online.de case is different. They happily
do send to any MXable domain. They do not
On 19.10.22 18:43, Alessandro Vesely via mailop wrote:
Do you get this error at the connection or after you transmitted the message?
$ telnet mx00.t-online.de 25
Trying 194.25.134.8...
Connected to mx00.t-online.de.
Escape character is '^]'.
554 IP=378.294.445.288 - A problem occurred. (Ask
Am 20.10.22 um 23:07 schrieb Lena--- via mailop:
T-Online clearly states in their terms and conditions that they will
block servers who perform sender verfication towards them.
Well, that's why you separate your MXes from your Sending servers; the
MX can do anything from it's IP, any fingering
Am 21.10.22 um 00:33 schrieb Graeme Fowler via mailop:
No. There will be no changes to the Exim default configuration
So sad. It's up to the packagers then to fix the shit that hits the fan.
-kai
___
mailop mailing list
mailop@mailop.org
Am 20.10.22 um 21:29 schrieb Michael Rathbun via mailop:
On Thu, 20 Oct 2022 20:47:40 +0200 (CEST), Bernardo Reino via mailop
wrote:
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
Am 20.10.22 um 21:44 schrieb Grant Taylor via mailop:
There's no problem with the phone line / connection. The pone line /
connection is working well enough for someone to rudely say something to you
and hang up.
Ah, you're saying I mustn't be as rude to a specific caller as it is to me?
Am 21.10.22 um 02:23 schrieb Grant Taylor via mailop:
On 10/20/22 4:49 PM, Kai 'wusel' Siering via mailop wrote:
Another rule from an earlier era outlines one of the fundamental principles of
the Internet Agreement: I will accept your traffic, *subject* *to* /my/
*policies* and agreements
Am 21.10.22 um 04:59 schrieb Hal Murray via mailop:
That's the industry standard: block after abuse. Instead, t-online.de uses
block-and-maybe-unblock-after-contact. This is not how email is supposed to
work.
I thought the standard was your server, your rules.
As long as the _default_
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
Am 19.10.22 um 22:41 schrieb Slavko via mailop:
Dňa 19. októbra 2022 17:38:27 UTC používateľ Kai 'wusel' Siering via mailop
napísal:
Might be true in general, but the t-online.de case is different. They happily
do send to any MXable domain. They do not accept all responses to the email
Moin,
am 19.10.22 um 22:42 schrieb Wolfgang Rosenauer via mailop:
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
Am 20.10.22 um 00:04 schrieb Kirill Miazine via mailop:
In the German Net Neutrality report 2020/2021, published by
Bundesnetzagentur, section 24, they say:
In several cases end-users could not receive incoming emails. They
believed that internet access providers were blocking emails
Am 19.10.22 um 22:58 schrieb Martin Neitzel via mailop:
My private Mailserver never ran into problems delivering to
@t-online.de recipents. And there's no impressum for it -- not
even a matching web server.
Then I supppose you're using IP space tagged with your name, which
trumps the imprint
Moin,
am 20.10.22 um 01:40 schrieb Ángel via mailop:
On 2022-10-19 at 11:37 -0700, Michael Peddemors wrote:
I am not going to go into whether operating a service on the internet
is a 'right' or a 'privelege', but coming into my home sure is..
Well, precisely. Providing an address should be no
Moin,
am 19.10.22 um 20:08 schrieb Bernardo Reino via mailop:
Well, now that it's public anyway -> www.bbmk.org
BTW they replied an hour ago with:
[…]
which means they'll whitelist the IP address (can take up to 24h).
Which OTOH means that Deutsche Telekom is still whitelisting
Am 23.10.22 um 01:05 schrieb Sebastian Nielsen via mailop:
The article you linked to, was very clear (when running it through google
translate) that the imprint requirement only required if it was a PAID service,
requiring some compensation to use.
Seemingly this requirement moved into §18
Moin,
am 22.10.22 um 23:33 schrieb Jaroslaw Rafa via mailop:
Dnia 22.10.2022 o godz. 19:06:25 Sebastian Nielsen via mailop pisze:
That’s why, running a PAID online service usually requires permission from
the government too, so the government can do regular visits and checks to
ensure you do
We're quite diverging from the topic ...
Am 23.10.22 um 01:30 schrieb Sebastian Nielsen via mailop:
a htaccess wont discharge you from being a "public service".
Yes, no, maybe. German courts seem to be ok with an .htaccess to keep the
general public out for you to not need an imprint page
Am 23.10.22 um 02:00 schrieb Sebastian Nielsen via mailop:
When a service is provided totally for free, no strings attached, no
requirements, nothing.
Then its not a "service offered for remundiation" and thus, according to that
§5, its not a telemedia.
§1 TMG has a definition what it thinks
Am 22.10.22 um 23:55 schrieb Sebastian Nielsen via mailop:
Germany and Sweden do not. And only paid online services require a imprint,
free OR personal online services do not in germany.
Seems like §18 Medienstaatsvertrag disagrees. (»(1) Anbieter von Telemedien,
die nicht ausschließlich
Am 21.10.22 um 09:39 schrieb Florian Effenberger via mailop:
I am neither a package maintainer nor a mail server developer, so my voice
likely is just a very small one - but last year I've been gone through a lot of
the pain with setting up a new mail server on a new IP address and getting
Moin,
am 21.10.22 um 08:02 schrieb Johannes Posel:
Am 21.10.2022 um 04:01 schrieb Kai 'wusel' Siering via mailop
:
I dont't talk about Reply-To; it's an irrelevant twist. The real world szenario is that
some...@t-online.de mails to i...@verein.de ("verein" means associa
Am 21.10.22 um 00:33 schrieb Graeme Fowler via mailop:
No. There will be no changes to the Exim default configuration, nor should
there be.If the suggestion was made of a commercial product with thousands of
people behind it, it would likely result in costly litigation.
Am 21.10.22 um 10:08
On 20.10.22 14:51, Jaroslaw Rafa via mailop wrote:
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
Moin,
trying to sum things up so far:
Am 19.10.22 um 13:33 schrieb Heiko Schlittermann via mailop:
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
Am 14.09.22 um 03:32 schrieb Jarland Donnell via mailop:
I can't block Gmail IPs, at all. It's on average 48% of who my clients
communicate with. While they may be sympathetic to the fact that an IP of
theirs sent spam, they will not hold anyone accountable for their missed email
but me. So
Moin,
on 15.09.22 15:37, Gellner, Oliver via mailop wrote:
[…]
The full blogpost can be read here:
https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html
To get back to the original topic: In my opinion many of the
Am 04.08.22 um 00:03 schrieb Bill Cole via mailop:
A MTA that can't get STARTTLS to work will retry (or even continue in the same
session) without encryption, as it SHOULD per the standard.
Erm, no, it doesn't. And that's not how RFC 3207 defines things, anyway:
After receiving a 220
Moin,
am 03.08.22 um 13:34 schrieb Sidsel Jensen via mailop:
We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
MTA to MTA communication, and based on the numbers we've seen so far, it
doesn't look that far fetched.
[…] but have you also disabled it for MTA to MTA
40 matches
Mail list logo
