date:20221020


On 10/20/22 9:53 PM, Jyri J. Virkki via mailop wrote:

None of the three analogies is really comparable (phone call, postal
mail, taxi) because in each case the person doing the rejecting is the
intended recipient. Who certainly has the moral right to reject.


All three scenarios can be extended in effectively the same way that you 
did:


 - phone call - you make outgoing calls, but return calls are routed to 
a switchboard / screened.
 - postal mail - inbound postal mail passes through a mail room that 
screens.

 - tax - door man exactly as you outline.


Try this: You live in an apartment and invite a friend over for dinner
(message sent by you and received by your friend).  They take the taxi
over to your place and arrive (response email IP packet reaches
t-online). But, your building has a cantankerous doorman who doesn't
like how your friend looks and slams the door in their face. The
doorman doesn't check whether you wanted this visitor and doesn't even
tell you what they just did. So, you sit in your apartment all night
waiting and wondering why the friend isn't arriving but you will never
know.


I believe that building owners should have the ability to post a doorman 
to do exactly that.


I would certainly have a well known and clearly published policy 
explaining this to tenants.  --  If $SOMETHING is not done, non-tenants 
don't get in.  Where $SOMETHING is tantamount to a guest pass.


I see exactly this type of behavior in multiple buildings.

I've seen /automated/ forms of this via alarm / access control systems. 
If you don't have a badge or an access code you don't get in.


This type of security is often referred to as "gated communities".


That's a good analogy for t-online. Both the sender and recipient are
innocent victims of t-online's oddball behavior.


If the pizza delivery driver doesn't have a gate code, then they don't 
get into the gated community.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Industry standards

2022-10-20 Thread Benny Pedersen via mailop


Kai 'wusel' Siering via mailop skrev den 2022-10-21 05:23:

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_ configuration from now on ensures that any
mail from @t-online.de is rejected, I frankly do not care.

If you change that default: fine by me.


i just added t-online.de to rpz so it get domain not found in mta stage, 
that means 2 tings btw, 1: i dont accept mail from this domain, 2: i 
dont send mail to that domain


and subdomain is still not on my rpz zone, so my custommers can still 
ask how to get on the "allow" list


sadly it is so until there is a better world of not so much political 
problems to solve, i do not want to break gdpr at all, but others might 
still do it or don't care at all

___
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 10/20/22 9:14 PM, Kai 'wusel' Siering via mailop wrote:

But their "policy" does not adhere


Yes, T-Online /does/ adhere to T-Online's policy of only accepting email 
from senders that T-Online considers to be blessed.


No. They 554 anyone, including me from any of my 1k+ v4 IPs except for 2 
of them.


No, T-Online doesn't 554 /anyone/.  T-Online quite obviously 250s many 
blessed senders.


Let me compute 2/1000, I came up with 0. Please correct my math, 
really, really please …


The math doesn't matter /because/ T-Online /does/ 250 blessed senders.

Granted. OTOH, nothing states that _that single outcast_ shouldn't be 
properly casted in the default configuration of any mailserver there is.


I believe there have been multiple others beside myself that think that 
T-Online should NOT be shunned in MTA /default/ configurations.


As has been pointed out before, doing so *does* increase deliverability, 
*does* increase transparency.


No.  It makes deliver-ability *WORSE*.

As pointed out before, your choice to refuse to accept email from 
T-Online means that *you* break communications between a T-Online user 
and /you/ wherein the T-Online user sends a Reply-To: set to their Gmail 
address.  /You/ *WOULD* be able to communicate with them /without/ 
sending any email to T-Online.  But /you/ have chosen to block that 
email at /your/ server.



Sure. Totally agree.

But: IF it is a KNOWN FACT that they DO NOT ACCEPT MAIL FROM ANY SERVER 
except those where they previously whitelisted it's IPv4, AND THEY ARE 
THE SINGLE ONLY MAILSERVICE ON PLANET EARTH to do so, THEY MUST BE 
MARKED AS SUCH.


I suspect that there are *MANY* Business-to-Business email servers that 
use similar filtering and only allow /specific/ previously white listed 
addresses to communicate.  That's the exact same thing that T-Online is 
doing.  The only difference is that T-Online has a more public user base.


As anything else leads to broken communication. I'm okay with you being 
okay with that, but you cannot chance sides afterwards. And this is not 
over yet.


I have no problem receiving messages from T-Online.  I will honor a 
Reply-To.  Or I'll put an impressum on my web site and ask T-Online to 
white list me.  --  I have no problem with what T-Online is doing.  It's 
their server(s) and thus their rules.



I made that clear multiple times already; feel free to check the archives.


No.  You have made it abundantly clear that you strongly disapprove of 
what T-Online is doing.  You have not provided justification for why 
MTAs should alter their default configuration to banish T-Online.


You're apparent vehement dislike for T-Online is not in and of itself 
justification for banishing them.


Years ago a few email servers started requiring reverse DNS PTR records. 
 People wanted to shun the first few that required such as outliers. 
Now the PTR record is SOP.


As stated above, there are many B2B email servers that only allow white 
listed peers.


Do you also want to identify those B2B email servers and equally banish 
them?


If not, why not?  Why do you think that T-Online deserves anything 
different than other B2B email servers?


Anyone's policy has to work within the parameters of the choosen 
protocol and it's policies, otherwise interoperability is not possible.


T-Online *IS* working within the parameters of the SMTP protocol. 
Servers that are white listed can speak bog standard SMTP / ESMTP to 
T-Online without a hint of a problem.  Hence T-Online is using standard 
protocols.


As such, t-online.de's policy is not compatible with how the SMTP 
protocol is supposed to work: 554'ing basically anyone is NOT the way to 
go.


It may not be a /good/ way to go.  It might even be a /bad/ way to go. 
But it is still within the SMTP specification.


Besides, mx*.t-online.de don't comply to RFC 5321, Section 3.1: "a 
554 response MAY be given in the initial connection opening message 
instead of the 220. A server taking this approach MUST still wait 
for the client to send a QUIT […]". They don't. And they aren't 
Joe Random following a bad HowTo. t-online.de is deliberately 
breaking standard's track RFCs to, as it seems, gain a competative 
advantage. This mustn't hold.


I understand why you might think that.

However RFC 5321 § 3.8 -- Terminating Sessions and Connections -- states:

"""
An SMTP server MUST NOT intentionally close the connection under normal 
operational circumstances (see Section 7.8) except:

...
  o  After a timeout, as specified in Section 4.5.3.2, occurs waiting 
for the client to send a command or data.

"""

The letter of RFC 5321 § 4.5.3.2 -- Timeouts -- talks about /command/ 
timeouts.  I believe that the initial greeting / hello banner is within 
the spirit and can leverage timeouts.  Thus the server can time out 
connected clients in an extremely short interval and naturally close the 
connection.


RFC 5321 § 7.8 -- Resistance to attacks -- also goes into more details 
about what

Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders

2022-10-20 Thread Jyri J. Virkki via mailop

On Thu, Oct 20, 2022 at 01:44:56PM -0600, Grant Taylor via mailop wrote:
>
> Try this:  Does the taxi fail to take you to someone's house if the
> person opens their front door, sees it is you, and then slams the
> door in your face?  --  Did the taxi fail to get you to the person's
> front door in any way?

None of the three analogies is really comparable (phone call, postal
mail, taxi) because in each case the person doing the rejecting is the
intended recipient. Who certainly has the moral right to reject.

Try this: You live in an apartment and invite a friend over for dinner
(message sent by you and received by your friend).  They take the taxi
over to your place and arrive (response email IP packet reaches
t-online). But, your building has a cantankerous doorman who doesn't
like how your friend looks and slams the door in their face. The
doorman doesn't check whether you wanted this visitor and doesn't even
tell you what they just did. So, you sit in your apartment all night
waiting and wondering why the friend isn't arriving but you will never
know.

That's a good analogy for t-online. Both the sender and recipient are
innocent victims of t-online's oddball behavior.

-- 
Jyri J. Virkki - Santa Cruz, CA

-- 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Industry standards


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_ configuration from now on ensures that any
mail from @t-online.de is rejected, I frankly do not care.

If you change that default: fine by me.
-kai

___
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

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, if you will accept mine, *subject* *to* /your/
*policies* and agreements.

Yes, but as t-online.de fundamentally breaks with this principle,

No they do not.

Oh, they certainly do.

/Their/ /policy/, which they have published on the Internet, is /their/
prerogative.

But their "policy" does not adhere to "I will accept your traffic, *subject* *to* /my/
*policies* and agreements, if you will accept mine, *subject* *to* /your/ *policies* and
agreements." They just *do* *not* accept my traffic whatsoever => party's over, t-online.de is
out. End of story.

What's more is they /are/ /accepting/ your email *subject* *to* /their/
*policies*.

No. They 554 anyone, including me from any of my 1k+ v4 IPs except for 2 of
them. Let me compute 2/1000, I came up with 0. Please correct my math, really,
really please …

Nothing states that anyone has to approve their policy or that they have to
adhere to anybody else's policy.

Granted. OTOH, nothing states that _that single outcast_ shouldn't be properly
casted in the default configuration of any mailserver there is.

As has been pointed out before, doing so *does* increase deliverability, *does*
increase transparency.

Each and every single email administrator (or organization) is free to run
their email server(s) as they choose to.

Sure. Totally agree.

But: IF it is a KNOWN FACT that they DO NOT ACCEPT MAIL FROM ANY SERVER except
those where they previously whitelisted it's IPv4, AND THEY ARE THE SINGLE ONLY
MAILSERVICE ON PLANET EARTH to do so, THEY MUST BE MARKED AS SUCH.

As anything else leads to broken communication. I'm okay with you being okay
with that, but you cannot chance sides afterwards. And this is not over yet.

giving a 554 to *any* IP per default, they should be single cased out for good
by default.

What grounds do you think that T-Online should be singled out?

I made that clear multiple times already; feel free to check the archives.

How are they not operating their email server subject to their policy?

Anyone's policy has to work within the parameters of the choosen protocol and it's
policies, otherwise interoperability is not possible. As such, t-online.de's policy is
not compatible with how the SMTP protocol is supposed to work: 554'ing basically anyone
is NOT the way to go. Besides, mx*.t-online.de don't comply to RFC 5321, Section 3.1:
"a 554 response MAY be given in the initial connection opening message instead of
the 220. A server taking this approach MUST still wait for the client to send a QUIT
[…]". They don't. And they aren't Joe Random following a bad HowTo. t-online.de is
deliberately breaking standard's track RFCs to, as it seems, gain a competative
advantage. This mustn't hold.
-kai
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Industry standards

2022-10-20 Thread 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.

It's fine to whine and rant here, but that isn't going to change anything.

Fighting spam is expensive.  Receivers have to filter out the crap.  Senders 
have to get through the filters.

Does anybody have any suggestions for how a help small sites?


-- 
These are my opinions.  I hate spam.



___
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


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
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders


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 to the remote MX as it
likes — it will never ever rely on being able to relay a message to
remote's MXes :) OTOH, MX refusal due to frivolous behaviour hasn't
been implemented yet ;-)

Yes, I'm a big fan of sender-address-verification and other "abusive"
techniques. Be my guest: My domain, my rules.


Then a different check:


I don't speak smail3^Hexim anymore, but I assume it's somewhat similar to

telnet $mx 25
if 2xx send quit
if 5xx set fuckem=1 && send quit || ignore errors
if $fuckem<1 die in_peace else wreck havoc

?
___
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

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?

Nah, doesn't compute.

Well, some...@t-online.de would now know, if that would have been a real SMTP
session.

It will prevent responses written into the void. That's a Good Thing™.

I'm not convinced of that. There are plenty of ways that someone could
(inadvertently) cause one of your users to try to send a message to T-Online.
The Reply-To: header comes to mind.

And someone may find the formula for love and peace for anyone — that's not the
point.

---8<---
Betreff: Undelivered Mail Returned to Sender
Von: mailer-dae...@mailout10.t-online.de (Mail Delivery System)
Datum: 20.10.22, 22:18
An: some...@t-online.de

This is the mail system at host mailout10.t-online.de.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

: host mx.uu.org[192.251.226.74] said: 554 5.7.1
: Sender address rejected: Sender domain not setup
to receive mail from here; contact t...@rx.t-online.de to whitelist the
sender IPs for this domain. (in reply to RCPT TO command)
--->8---

_That_ is the point: if something like that would become the default for any
new installation of Exim or Postfix (is Sendmail still a thing?), lost
communication *would* *effectively* be reduced: the t-online.de customer would
be informed of limited communication, read: they see their mail didn't make it
and would react in one way or another.

It's not the final solution. But it's a much better situation compared to now,
where above mail would make it to the receipient, and the _receipient_ would
not be able to reply, leaving the initial sender without the requested
information, considerung the receipient lazy, rude, whatever — email, unless
sent from monitoring systems, is usually a two-way-communication. t-online.de
does not allow for that per default, so one just shouldn't accept their
messages.

t...@rx.t-online.de is there to help T-Online users in these cases.

And who is to help your users when they send a message to T-Online?

In the proposed setup, mail to @t-online.de bounces back with a message pointing to the
local postmaster with a similar message ("have your postmaster to contact tosa@rx…
to mutually agree on terms for mail exchange").

Yeah, so what you are saying is: because t-online.de has 12 millions more
mailboxes, it is OK for them to mail my users but to block my user's responses
at the same time? I disagree.

Nope. That's not at all what I said. Nor is it what I implied. I'm confident
that you knew that too.

Then you are in error, therefore please explain what you meant with:

Even if the sender is clued into what is happening on a technical level, you are still left with the mismatch in size of companies, the larger company tends to have an advantage (at least) as large as the size discrepancy. Senders will almost always say "well I can send to others so it can't be on my side thus it must be on the recipient's side".

With the very specific message at hand ... they still might ignore the facts. BUT: THEY
got the error message, THEY know the message didn't make it to the receipient. And THEY
can immediately choose other means of communication since "mail is broken
again" (courtesy of t-online.de, I'd love to add).

Less lost mail in my view _is_ better,

Lost tends to imply accidental.

As for the sender that is blocked by t-online.de, it feels as being accidental
— we know it's not, but this does not help anyone.

Conversely, you are consciously preventing email in an additional direction.
So my opinion is that you are making things worse than they already are.

Your opinion is flawed from my point of view. I only put those things right
which t-online.de's policy breaks, that's the basic idea.

The flip side of the Reply-To: is someone sending to one of your users from
their T-Online address and setting their Reply-To: to something else; maybe
Proton Mail or Gmail.

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 association, club,
…), verein.de does run it's own mailserver as it's cheaper than using some SP for it.
verein.de runs basically default settings – which usually are good –, thus *not* blocking
mails from @t-online.de, hence i...@verein.de receives the mail and reponds to it. *BÄM*
554.

If Exim, Postfix, ... *properly* would _reject_ mails from @t-online.de _by default_ –
unless

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders


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, if you will accept mine, 
*subject* *to* /your/ *policies* and agreements.


Yes, but as t-online.de fundamentally breaks with this principle,


No they do not.

/Their/ /policy/, which they have published on the Internet, is /their/ 
prerogative.


What's more is they /are/ /accepting/ your email *subject* *to* /their/ 
*policies*.


Nothing states that anyone has to approve their policy or that they have 
to adhere to anybody else's policy.


Each and every single email administrator (or organization) is free to 
run their email server(s) as they choose to.


giving a 554 to *any* IP per default, they should be single cased 
out for good by default.


What grounds do you think that T-Online should be singled out?  How are 
they not operating their email server subject to their policy?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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


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
blocked, so you should (liberally) accept, instead of "being like them" and
block unfairly (for some definition of fairness anyway).


Yes and no. I don't want to be blocked by arbitrary rules that aren't based
on industry standards.
If my servers sent out spam, fine, block me and let's work on it case-by-case
(usually the root cause is failing spam detection – running non-profit or even
private mailservers, I cannot afford commercial services like expurgate – so
that the few spam content which rspamd with RBLs, Bayes- and Fuzzy-filters
doesn't detect is relayed via mailing lists or ticket systems to external
addresses).

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.

"Fairness" isn't my concern; the policy of t-online.de is creating bounces
at potentially a shitload of mailservers out there, because of a totaly
arbitrary setup.
This leads to lost communication — something no mail provider should stimulate.
Anything that helps to mitigate these effects is A Good Thing™, IMHO.


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.


While it looks like an eye for an eye, this is only a side effect. Sitting on
the receiving side of t-online.de mails, I'm faced with users confused why
"that @t-online.de address I just replied to isn't valid anymore". Of course
it isn't, the error code is not 550 but 554 ...

Is there a quick solution? No, see the discussion here.

Is it my fault? No.

Will my users resent their message in a few days time, after this issue is
resolved, hopefully? Unlikely.

Does t-online.de care? Nope.

Do t-online.de's users understand who is causing the issues? Highly unlikely.

And last but not least: is t-online.de's setup significantly reducing the amount
of spam received by it's users in 2022? Highly unlikely — if t-online.de would
be run according to industry standards. But then 
https://postmaster.t-online.de/index.en.html#t3.5 reads:


 *

Do t-online.de systems use greylisting, SPF or DKIM for e-mail filtering?


Greylisting is generally understood to mean that every incoming e-mail is
initially rejected temporarily and only accepted after a renewed delivery
attempt. This is based on the assumption that only authorized e-mail
systems initiate renewed delivery of rejected e-mails. As greylisting cannot
actually identify unauthorized e-mails and also hinders the delivery of
legitimate e-mails, Telekom systems do not use this procedure.

The Sender Policy Framework, SPF for short, can enable a check to determine
whether the sending IP address is authorized to send e-mails for the domain
in question. This procedure has numerous vulnerabilities that cannot be
compensated for, including those that are described here 
. Therefore, Telekom
does not use SPF either passively (when receiving e-mails) or actively (for
sending) by creating corresponding DNS resources.

Until now, we have neither used nor evaluated DKIM signatures. (An exception
is the "Trusted Dialog" project, which uses DKIM signatures for "inbox
branding".)



Tja ... Since one cannot properly compute the validity of emails from 
t-online.de,
seriously, what's the point of accepting from that doamin anyway?


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, if you will accept mine, subject to your policies and
agreements.


Yes, but as t-online.de fundamentally breaks with this principle, giving a 554
to *any* IP per default, they should be single cased out for good by default.
They can always apply for being re-enabled bilaterally on any mailserver — as 
per
their view on how email works.

Regards,
-kai
___
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

2022-10-20 Thread Graeme Fowler via mailop


Just for completeness here, and wearing both my Exim and Mailop hats:

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.


To suggest that an open source project - one with a shrinking developer 
group behind it, despite our best efforts - should do this, could be 
financial suicide for those developers.


Be sensible. The elephant in the room is a commercial ISP who've made a 
decision based on their own economics. Target that.


Graeme
___
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

2022-10-20 Thread Lena--- via mailop

> T-Online clearly states in their terms and conditions that they will
> block servers who perform sender verfication towards them.

Then a different check:

 deny condition = ${if or{\
{eqi{$sender_address_domain}{t-online.de}}\
.ifdef _HAVE_LOOKUP_DNSDB
{forany{${lookup dnsdb{>: defer_never,mxh=$sender_address_domain}}}\
   {match{$item}{\N^mx\d+\.t-online\.de$\N}}}\
.endif
   }}
  condition = ${if match{${readsocket{inet:\
.ifdef _HAVE_LOOKUP_DNSDB
${reduce{${lookup dnsdb{>: defer_never,mxh=$sender_address_domain}}}\
{}{$item}}\
.else
mx00.t-online.de\
.endif
:25}{}{2s}}}{^554 IP=}}
  message = We checked that $sender_address_domain blocks us. \
So we do not accept a message we cannot reply to.
# The server admin may change "deny" to "warn" and
# "message =" to "control = fakereject/"
# but few admins will want that (or notice and bother).

___
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 10/20/22 1:22 PM, Kai 'wusel' Siering via mailop wrote:

Well, it's both at the SMTP layer:

Same level.


You are obviously as free to run your server(s) as you want as T-Online 
is to run their servers as they want.



I don't get your point, as that is what t-online.de is effectively doing.


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.


Try this:  Does the taxi fail to take you to someone's house if the 
person opens their front door, sees it is you, and then slams the door 
in your face?  --  Did the taxi fail to get you to the person's front 
door in any way?


Similarly, did the postal service fail to deliver a letter if the 
recipient sees who it's from and immediately tosses it into the trash?


Well, some...@t-online.de would now know, if that would have been a real 
SMTP session.


It will prevent responses written into the void. That's a Good Thing™.


I'm not convinced of that.  There are plenty of ways that someone could 
(inadvertently) cause one of your users to try to send a message to 
T-Online.  The Reply-To: header comes to mind.



t...@rx.t-online.de is there to help T-Online users in these cases.


And who is to help your users when they send a message to T-Online? 
Perhaps via replying to a message from somewhere other than T-Online 
that had a Reply-To: directed to T-Online.


Yeah, so what you are saying is: because t-online.de has 12 millions 
more mailboxes, it is OK for them to mail my users but to block my 
user's responses at the same time? I disagree.


Nope.  That's not at all what I said.  Nor is it what I implied.  I'm 
confident that you knew that too.


I do agree on that. Hence the move to make sure future postmasters will 
not be bothered _unless_ _their_ users initiate the conversation. It's, 
after all, not their fault that t-online.de is setup north-korean style.


Less lost mail in my view _is_ better,


Lost tends to imply accidental.

Conversely, you are consciously preventing email in an additional 
direction.  So my opinion is that you are making things worse than they 
already are.


The flip side of the Reply-To: is someone sending to one of your users 
from their T-Online address and setting their Reply-To: to something 
else; maybe Proton Mail or Gmail.


therefore I completely disagree with your counting. See my reply to 
an test email I sent yesterday from @t-online.de to a test server of 
mine wait for expiry ...


# mailq
-Queue ID-  --Size-- Arrival Time -Sender/Recipient---
098221201B0  916 Thu Oct 20 21:07:45  some...@testmail.uu.org
(host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 
IP=931.620.721.400 - A problem occurred. (Ask your postmaster for help 
or to contact t...@rx.t-online.de to clarify.))

  some...@t-online.de


Nice IP address lookalike.  ;-)

How long is that message going to sit in your queue?  Given that it has 
a 554 response, I would have expected your MTA to have sent a DSN already.


This would have been prevented if some...@t-online.de would not have 
reached that mailbox in the first place. Getting the bounce directly 
that they cannot sent there, they might use another known email address 
of the receipient or revert to other means of contact. Or even reach out 
to tosa@rx to clarify the situation with testmail.uu.org's postmaster.


That assumption is predicated on the T-Online sender 1) receiving a DSN 
with your error message, 2) the sender understanding it, and 3) the 
sender being able to take other action.


As t-online.de is not likely to change their setup, the sanest approach 
is to limit the overall damage, which is to reject mail from t-online.de 
_unless_ they whitelisted one's sending IPs (as per SPF, most likely).


That is your opinion.  It happens to be an opinion that I disagree with.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

2022-10-20 Thread 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 
>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 ;-)

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, if you will accept mine, subject to your policies and
agreements.

As noted in the .sig below, things don't entirely work in this world as they
are assumed to work in the other.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
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 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 / over / through the 
established connection.  So, no, I don't believe it's a /connectivity/ thing.


Well, it's both at the SMTP layer:

t-online.de to me:

$ telnet mx00.t-online.de 25
Trying 194.25.134.8...
Connected to mx00.t-online.de.
Escape character is '^]'.
554 IP=478.944.843.488 - A problem occurred. (Ask your postmaster for help or 
to contact t...@rx.t-online.de to clarify.)
Connection closed by foreign host.

Me to t-online.de:

$ telnet mx.uu.org 25
Trying 192.251.226.74...
Connected to mx.uu.org.
Escape character is '^]'.
220 mx.uu.org ESMTP Proxmox
helo something.uu.org
250 mx.uu.org
MAIL FROM:
250 2.1.0 Ok
rcpt to:
554 5.7.1 : Sender address rejected: Sender domain not 
setup to receive mail from here; contact t...@rx.t-online.de to whitelist the sender 
IPs for this domain.
quit
221 2.0.0 Bye
Connection closed by foreign host.

Same level.


Do you call the pone company to report a problem calling a phone number when they answer 
the call, say "I'm not talking to you.", and hang up on you?


I don't get your point, as that is what t-online.de is effectively doing.


The proposed configuration change only makes this visible and clear,


I disagree that it will make it visible.


Well, some...@t-online.de would now know, if that would have been a real SMTP 
session.


I doubt that it will make it clear.


It will prevent responses written into the void. That's a Good Thing™.


First and foremost, that relies on the rejection notice, and details 
thereabout, to make it back to the sender.  What's more is that it requires the 
sender to have (access to someone with) a modicum of understanding.


t...@rx.t-online.de is there to help T-Online users in these cases.


Even if the sender is clued into what is happening on a technical level, you are still 
left with the mismatch in size of companies, the larger company tends to have an 
advantage (at least) as large as the size discrepancy.  Senders will almost always say 
"well I can send to others so it can't be on my side thus it must be on the 
recipient's side".


Yeah, so what you are saying is: because t-online.de has 12 millions more 
mailboxes, it is OK for them to mail my users but to block my user's responses 
at the same time? I disagree.


Maybe over time their will consider changing their "default block" approach.


Isn't there some rule / guideline / law that states that the longer that 
something has been in place the longer it is likely to stay in place? Seeing as 
how T-Online has purportedly had this in place for a decade, I doubt that it's 
going to change any time soon.


I do agree on that. Hence the move to make sure future postmasters will not be 
bothered _unless_ _their_ users initiate the conversation. It's, after all, not 
their fault that t-online.de is setup north-korean style.


P.S. Reach for / strive for better, don't settle for what we have.  If at all 
possible don't make things worse.


Less lost mail in my view _is_ better, therefore I completely disagree with 
your counting. See my reply to an test email I sent yesterday from @t-online.de 
to a test server of mine wait for expiry ...

# mailq
-Queue ID-  --Size-- Arrival Time -Sender/Recipient---
098221201B0  916 Thu Oct 20 21:07:45  some...@testmail.uu.org
(host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 
IP=931.620.721.400 - A problem occurred. (Ask your postmaster for help or to 
contact t...@rx.t-online.de to clarify.))
 some...@t-online.de

-- 0 Kbytes in 1 Request.

This would have been prevented if some...@t-online.de would not have reached 
that mailbox in the first place. Getting the bounce directly that they cannot 
sent there, they might use another known email address of the receipient or 
revert to other means of contact. Or even reach out to tosa@rx to clarify the 
situation with testmail.uu.org's postmaster.

As t-online.de is not likely to change their setup, the sanest approach is to 
limit the overall damage, which is to reject mail from t-online.de _unless_ 
they whitelisted one's sending IPs (as per SPF, most likely).
-kai
___
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

2022-10-20 Thread Jarosław Rafa via mailop

W dniu czw, 20.10.2022 o godzinie 22∶01 +0300, użytkownik Lena--- via
mailop napisał:
>   set acl_m_ton = checkdefer
>   !verify = sender/callout=10s
>   set acl_m_ton = $acl_verify_message

T-Online clearly states in their terms and conditions that they will
block servers who perform sender verfication towards them.

So that's not a good idea.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
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

2022-10-20 Thread Lena--- via mailop

Kai Siering wrote on [mailop]:

> how about starting internal discussions within that community
> to include a default rejection of any mail from @t-online.de
> in Exim's default configuration?

> As nearly no-one who is deploying Exim
> (or Postfix, Sendmail for that matter)
> will be able to *send* to @t-online.de due to their policy,
> it is only logical to not *accept* any mail from them, too.

I propose to include in default Exim config (in rcpt ACL)
a code which checks whether the server is blocked by t-online.de:

 warn set acl_m_ton = notton
  condition = ${if or{\
{eqi{$sender_address_domain}{t-online.de}}\
.ifdef _HAVE_LOOKUP_DNSDB
{forany{${lookup dnsdb{>: defer_never,mxh=$sender_address_domain}}}\
   {match{$item}{\N^mx\d+\.t-online\.de$\N}}}\
.endif
   }}
  set acl_m_ton = checkdefer
  !verify = sender/callout=10s
  set acl_m_ton = $acl_verify_message

 deny condition = ${if !eq{$acl_m_ton}{notton}}
  condition = ${if !eq{$acl_m_ton}{checkdefer}}
  message = sender verify failed: $acl_m_ton

 deny condition = ${if eq{$acl_m_ton}{checkdefer}}
  message = We checked that $sender_address_domain blocks us. \
So we do not accept a message we cannot reply to.
# The server admin may change "deny" to "warn" and
# "message =" to "control = fakereject/"
# but few admins will want that (or notice and bother).

___
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 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) 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.

Well, I usually am not polite after being blocked _again_ (about every other
year, maybe too few mails sent?), but got the whitelisting nonetheless. It's a
PITA, nonetheless.

But no, if you feed "t...@rx.t-online.de impressum" into the next Google search
widget, you should at least find
https://blog.rolandmoriz.de/2020/09/21/t-online-blockiert-mails-fuer-kunden/ from 2020, where
a comment dated 2020-12-06 states (cut & paste into the translator of you choice):

Hallo Roland,

ich habe die gleiche Erfahrung gemacht. T-online hat alle Mails von meinem
Mailserver grundsätzlich abgelehnt, obwohl dieser allen aktuellen Standards
entspricht. Bei Nachfrage wurde auf die besagte Liste technischer
Vorraussetzungen verwiesen und zusätzlich angemerkt, dass t-online keine Mails
von anonymen Anbietern annehmen möchte. Ich habe unter meiner Domain eine
index.html mit Verweis auf ein simples Impressum hinterlegt und anschließend
dem Support mitgeteilt.

Ender der Geschichte, ich wurde relativ schnell freigeschaltet und die Mails in
meiner mail queue sind direkt rausgegangen. Ich war auch tierisch genervt
davon, dass so ein Verfahren notwendig ist um in heutiger Zeit eine Mail senden
zu können. Hiermit möchte ich aber dem ein oder anderen Hoffnung geben und
aufzeigen, dass eine Freischaltung möglich ist!

LG, Max

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.

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.

Does "later" include "never"? Then I'd agree ...

Even c't would have to do a realiy check here and concede that the percentage
of email dropped by Deutsche Telekom's policy decision for t-online.de is next
to none, compared to what they do receive on a daily basis. I'm not even sure
Deutsche Telekom would answer a request from c't for a comment on that unique
policy — but if they would, I'd love to see it.

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.

FTR, mx*.t-online.de's use of 554 does violate RC5231, as they ignore the MUST
clause regarding the wait for QUIT. But that's a different story.
-kai
___
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

2022-10-20 Thread Andrew C Aitchison via mailop


On Wed, 19 Oct 2022, Jaroslaw Rafa via mailop wrote:


Dnia 19.10.2022 o godz. 18:55:29 Kai 'wusel' Siering via mailop pisze:


It would be less of an issue if t-online.de would take care _not_ to send
to domains they don't take the replies from; but they happily sent emails
to any MX in the world (anything else would upset _their_ users), but then
eagerly reject the replies.


So, as they don't do it themselves, the other party has to do it, as I
already wrote in my previous email. Anybody who receives email from T-Online
but has experienced rejection when trying to send to them, should reject any
messages from T-Online as well, with the error message stating exactly that
"We reject messages from t-online.de because you reject messages from us".


If sender-verify-callback was still considered acceptable,
that would resolve the issue automatically and accurately.

However, I would want to give fair warning before rejecting mail from 
innocent senders.

Pity I can't see a way use a temporary reject or greylisting to
get a message back to sending user but still delivering the message.

I suppose I could deliver the email but give a permanent reject
message saying that we believe the recipient will not be able to reply
to T-Online senders.

But of course, sending a clear and accurate reject or bounce message
to T-Online is no guarantee that it will reach the sender.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
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

2022-10-20 Thread Slavko via mailop

Dňa 20. októbra 2022 16:50:56 UTC používateľ Grant Taylor via mailop 
 napísal:
>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 / over / through the 
>established connection.  So, no, I don't believe it's a /connectivity/ thing.
>
>Do you call the pone company to report a problem calling a phone number when 
>they answer the call, say "I'm not talking to you.", and hang up on you?

Interesting. When the other side will be machine, which is expected
to "talk" with me, i will consider to complain.

IMO you are wrong about "not on any OSI layer" as SMTP is L7,
and rejecting connection is against RFC5321 (without good --
i understand attack/abuse -- reason, see sect 7.9).

IMO the rest  depends on point of view, my is that because whole
rejection is IP based, it is L3 thing, and doesn't matter that it
happens in L7. Other point of view can be, that it is L7 thing,
as all previous layers was success. Sameone other can consider
the connection as SMTP stage, before client sends EHLO, etc...

But that doesn't matter, as it is wrong at all.

...

But yes, you changed my mind about t-online.de blocking. You
are right, that i drop to their (bad) level by that.

regards

-- 
Slavko
https://www.slavino.sk/
___
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 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 / over 
/ through the established connection.  So, no, I don't believe it's a 
/connectivity/ thing.


Do you call the pone company to report a problem calling a phone number 
when they answer the call, say "I'm not talking to you.", and hang up on 
you?



T-Online customers can send mail to any mailserver and they aren't aware of
the fact that they can't get a reply because T-Online has a "default block"
policy, unless whitelisted. They are harming connectivity in a way that is
invisible to their users, doing in fact misservice to those users.


I agree completely.


The proposed configuration change only makes this visible and clear,


I disagree that it will make it visible.  I doubt that it will make it 
clear.


First and foremost, that relies on the rejection notice, and details 
thereabout, to make it back to the sender.  What's more is that it 
requires the sender to have (access to someone with) a modicum of 
understanding.


Even if the sender is clued into what is happening on a technical level, 
you are still left with the mismatch in size of companies, the larger 
company tends to have an advantage (at least) as large as the size 
discrepancy.  Senders will almost always say "well I can send to others 
so it can't be on my side thus it must be on the recipient's side".


introducing also default blocking in the reverse direction (unless 
whitelisted, which you can always do). I think that a block you know 
about is "better" than a block you don't know about.


I believe such a block is setting things up for a self fulfilling 
feedback loop.  --  Once two parties start "doing something because the 
other is doing it to them" there is no exit / end / termination of the 
loop without external influence.



T-Online customers trying to send mail to other mailservers will hit that
block, and if the reject message will exactly specify the reason - something
like "We block mail from T-Online because they block mail from us" - and the
customer forwards this message to T-Online support, I assume they'll at
least have to explain the situation to the (probably angry) customer.


I seriously doubt that's going to work out satisfactorily for anyone 
other than T-Online.


Maybe over time their will consider changing their "default block" 
approach.


Isn't there some rule / guideline / law that states that the longer that 
something has been in place the longer it is likely to stay in place? 
Seeing as how T-Online has purportedly had this in place for a decade, I 
doubt that it's going to change any time soon.


Finally, I feel like the old adage of two wrongs don't make a right 
comes to mind.  After all, I think most of us can agree that what 
T-Online is doing is wrong.  And you're advocating that more of us make 
the same wrong choice.  What's more is that you're advocating to 
codifying this wrong choice in default configuration for multiple MTAs. 
I think that's an order of magnitude worse than the original wrong.


So now I think we're up to 12 wrongs; T-Online's default block is 1st, 
your reactionary default block is 2nd, and  your desire to codify this 
is another ten.


P.S.  Reach for / strive for better, don't settle for what we have.  If 
at all possible don't make things worse.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

Dnia 20.10.2022 o godz. 09:32:15 Grant Taylor via mailop pisze:
> 
> Aside:  I wonder if having a provider blocked by default is a form of
> defamation.

I consider this being purely a connectivity thing.

T-Online customers can send mail to any mailserver and they aren't aware of
the fact that they can't get a reply because T-Online has a "default block"
policy, unless whitelisted. They are harming connectivity in a way that is
invisible to their users, doing in fact misservice to those users. The
proposed configuration change only makes this visible and clear, introducing
also default blocking in the reverse direction (unless whitelisted, which
you can always do). I think that a block you know about is "better" than a
block you don't know about.

T-Online customers trying to send mail to other mailservers will hit that
block, and if the reject message will exactly specify the reason - something
like "We block mail from T-Online because they block mail from us" - and the
customer forwards this message to T-Online support, I assume they'll at
least have to explain the situation to the (probably angry) customer. Maybe
over time their will consider changing their "default block" approach.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
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 10/20/22 9:17 AM, Jaroslaw Rafa via mailop wrote:

+1

Could you please repost this to appropriate Exim and Postfix mailing lists?


-1

I believe providing a config which is enabled by default that rejects 
email from a provider is a disservice to the industry at large and will 
only promote fracturing things.


Having the config there but remarked / commented out is something different.

Let's promote being inclusive.  We already have enough things working 
against us, see the recent oligarchies thread for an example.  Let's not 
choose to divide things even more.


Aside:  I wonder if having a provider blocked by default is a form of 
defamation.  I suspect multiple lawyers could retire on such a question 
/if/ we were to pay them to decide.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders

Dnia 20.10.2022 o godz. 17:10:40 Kai 'wusel' Siering via mailop pisze:
> 
> But, as you ARE an Exim developer, how about starting internal discussions
> within that community to include a default rejection of any mail from
> @t-online.de in Exim's default configuration?
> 
> As nearly no-one who is deploying Exim (or Postfix, Sendmail for that
> matter) will be able to *send* to @t-online.de due to their policy, it is
> only logical to not *accept* any mail from them, too.  Those who did
> whitelist their server could remove that config, but for the majority of
> the users, this small config change will solve the issue.  Same should
> happen with Postfix, and the Package Maintainers at Debian, Ubuntu,
> RedHat, etc.  should look into changing their default configuration in a
> similar way as well.
> 
> This is the only reasonable approach, as, as we learned yesterday,
> t-online.de's MXes are configured in a way that do not let any mailserver
> connect — unless it's postmaster arranged a whitelisting with them
> upfront.
> 
> The setup of t-online.de's mailservers is, AFAIK, unique, and therfore it
> should be preconfigured appropriately in mailserver packages, so no more
> postmasters drop into that pitfall.

+1

Could you please repost this to appropriate Exim and Postfix mailing lists?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
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

Dnia 20.10.2022 o godz. 15:51:13 Kai 'wusel' Siering via mailop pisze:
> > such data online is perfectly valid for companies, for individuals it's
> > nothing more than an endorsement for criminal activity.
> 
> Well, just use your ISP's submission service, problem solved.

By ISP you mean hosting provider here? Because the actual ISPs, ie.
companies that provide Internet connectivity (either to your home or to your
hosting provider) usually don't offer any submission services. They *may*
offer an additional email service, but it's by no means a rule.

As for hosting provider, my provider for example does offer a submission
service only as a part of their mail service. If you sign up for their mail
service, you can use their submission service - but of course for sending
mail from *their* domain, not yours.

If you have a VPS (or even a physical server) hosted by them, with your own
domain, they don't offer you any submission service (or equivalent, like a
relay). After all, you have your own server where you can run your own mail
service for your domain (which is exactly what I do).

> Or pay someone to MX you domain, problem solved.

You probably mean provide outgoing SMTP for my domain, not MX? There is no
problem with *receiving* mail from t-online on any server.

But again, this makes no sense. I'm already paying for a server which is
fully capable of doing outgoing SMTP, why should I pay for another service
only to be able to send mail to some provider with shitty policy?

> > If some madman does not like what I write anywhere on the Internet (for 
> > example
> > on my blog,
> 
> As a German, you have to have an imprint on anything that is considered a
> "service", yes, even on your personal, non-monetized blog. It the law ;) And
> also off-topic here.

As a German. But as I mentioned, people who run mailservers and may want to
send mail to t-online are not necessarily Germans. Therefore the fact that
German law requires an imprint is actually completely off topic when it
comes to imprint as a requirement to be available to send mail to t-online.

> Well, it's a kind of non-written contractual agreement: you want your
> mailserver to be able to sent to t-online.de, they want to know who you are.

And I have no objection against giving that information to *them*. But to
*them* only, not to the whole world!

Plus, as I already stated, it's not information "who you are". I
deliberately mentioned my website as an example that perfectly (and in a
very detailed way) describes who I am, but does not fulfill their
requirements. They don't want to know "who I am", they want to know two very
specific things: my street address and telephone number. This is in no way
equivalent to "who I am". "Who I am" is my name, and this is available on my
website. And not only *they* want to know this specific information (as I
said, I have nothing against it); they want that the whole world knows it -
and that is an utterly absurd requirement.

> You're free not to agree to the terms, so where's law involved anyway?

I only mentioned the law because some people (you too) bring up the
non-relevant fact that all German websites are required by law to have an
imprint. Which is, as said, completely non-relevant here.

> And, to point this out again: the subject of this thread already has been
> disproven — t-online.de/Deutsche Telekom/t...@rx.t-online.de is still white-
> listing personal mailservers, as long as the criteria on their postmaster
> page are met.

That is, as long as you have that particular information on your website,
that I'm writing all about here :)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders


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 from a major German
hoster). The answer he (the owner of that host) got was about like this:


Today we learned the complete message reads (thanks to Kirill Miazine):

Thank you very much for your message.

We only allow evidently commercial or similar operators to connect to
our mailservers. So, please use an SMTP relay or e-mail gateway of your
hoster or ISP, that you can use as part of your contract with them.
Their support will surely help you to configure your system accordingly.

However, from our point of view, a host would be evidently commercial if
it fulfills all the requirements an recommandations from the first two
paragraphs of section 4.1 of our FAQ; see
.


As of yesterday, the setup around 168.119.159.241 didn't match any to section 
4.1, except matching DNS.

Yesterday we also learned from Bernardo Reino that Deutsche Telekom is still 
whitelisting any mailservers to connect to the t-online.de MXers — IF they 
comply with section 4.1 of the rules on postmaster.t-online.de.

So, to put it in a nutshell: Deutsche Telekom's policy for accessing the MXes for 
t-online.de hasn't changed for 10+ years. Their wording seemingly has, see above, but 
they still provide ways for "new" mailservers to be able to sent to 
@t-online.de (details on https://postmaster.t-online.de/index.en.html#t4.1).


Personally I consider this quite rude, and as a smaller ISP I'll be hit
sooner or later.


I do agree. (Being my own ISP, I've been hit by this BS about every second 
year.)


As an Exim developer I'm asking myself why they
(T-Online) assume that I shouldn't run my own mail service.


This only Deutsche Telekom can answer.

But, as you ARE an Exim developer, how about starting internal discussions 
within that community to include a default rejection of any mail from 
@t-online.de in Exim's default configuration?

As nearly no-one who is deploying Exim (or Postfix, Sendmail for that matter) 
will be able to *send* to @t-online.de due to their policy, it is only logical 
to not *accept* any mail from them, too. Those who did whitelist their server 
could remove that config, but for the majority of the users, this small config 
change will solve the issue.
Same should happen with Postfix, and the Package Maintainers at Debian, Ubuntu, 
RedHat, etc. should look into changing their default configuration in a similar 
way as well.

This is the only reasonable approach, as, as we learned yesterday, 
t-online.de's MXes are configured in a way that do not let any mailserver 
connect — unless it's postmaster arranged a whitelisting with them upfront.

The setup of t-online.de's mailservers is, AFAIK, unique, and therfore it 
should be preconfigured appropriately in mailserver packages, so no more 
postmasters drop into that pitfall.

Regards,
-kai

___
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


Hello,

Grant Taylor via mailop wrote on 20.10.22 at 16:06:
Please forgive ~> humor my ignorance, but what does the imprint / 
impressum (?) /need/ to have in it?


not sure what Telekom actually asks for - but (as you can imagine, it's 
Germany :) things are quite regulated in the law. Depending on the kind 
of business, you have to provide various information, that could include 
VAT number, your chamber or supervisory authority etc.


There are actually websites offering "imprint generators" so you don't 
miss anything. It _is_ quite obscure and an everlasting legal discussion.


What I would assume, without knowing, is that Telekom would be happy 
with a name, street address (PO boxes are likely not accepted), phone 
number and e-mail address.


Not defending any policies or laws here, just trying to shed some light.

Florian
___
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


Hello,

Kai 'wusel' Siering via mailop wrote on 20.10.22 at 15:51:


As a German, you have to have an imprint on anything that is considered a
"service", yes, even on your personal, non-monetized blog. It the law ;) 
And

also off-topic here.


I agree, this part of the discussion will likely lead to no conclusion. 
The regulations here in Germany are a bit weird, but it's something we 
can hardly ignore. Experience tells me that other jurisdictions have 
other "strange" regulations too.


Obviously the intersection with the imprint mandate on one hand, and the 
GDPR rules (and how public data can be misused) on the other hand is an 
interesting one, but that's more of a legal, less of a technical problem.


I totally understand for non-Germans this imprint stuff is just super 
irritating, for us it's sadly somehow "normal", which doesn't mean we 
don't find it stupid... :-)



Well, it's a kind of non-written contractual agreement: you want your
mailserver to be able to sent to t-online.de, they want to know who you 
are.

You're free not to agree to the terms, so where's law involved anyway?


In the end, the acceptance or non-acceptance of mail operators is 
something many of the small providers suffer from, as outlined just 
recently here on the list. However...



And, to point this out again: the subject of this thread already has been
disproven — t-online.de/Deutsche Telekom/t...@rx.t-online.de is still 
white-

listing personal mailservers, as long as the criteria on their postmaster
page are met.


...that is my understanding. And from all interactions I had with mail 
operators, Telekom was amongst the fastest and most uncomplicated ones, 
so at least the practical handling was quite relaxed.


Florian
___
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 10/20/22 7:51 AM, Kai 'wusel' Siering via mailop wrote:
Well, just use your ISP's submission service, problem solved.  Or pay 
someone to MX you domain, problem solved.


I don't agree that the problem is /solved/.  Rather I think using such 
an external problem /changes/ or /moves/ the problem in such a way as to 
make DT/T-Online happy.


Similar to how lines of credit don't /solve/ money problems, they simply 
time shift them.


As a German, you have to have an imprint on anything that is considered 
a "service", yes, even on your personal, non-monetized blog. It the 
law ;) And also off-topic here.


Please forgive ~> humor my ignorance, but what does the imprint / 
impressum (?) /need/ to have in it?


Do imprints / impressums for brick and mortar stores include the CEO's 
personal information?  Or, instead, do they include contact information 
for a company employee that can handle inquiries and connect them with 
the proper other internal employees on an as needed basis?  Sort of like 
many businesses have an operator that answers phone calls and connects 
people with internal departments.


This sort of seems like the quintessential $BUSINESS is licensed in 
$STATE and $LAWYER is the official point of contact that is common for a 
number of (above board) small businesses in the U.S.A.


Would said $LAWYER's contact information in an imprint / impreessum 
suffice?  Or is there supposed to be something more direct?


I ask as I'm genuinely curious, not wanting to object.  I'm trying to 
understand the laws / regulations / rules of business for another 
country on the common spinning body of water and rock riding through the 
solar system.


Aside:  I wonder if there is any use for the old Responsible Person DNS 
record or a TXT record for something like this.  Obviously people would 
have to support it.  I could see value in something like 
. being a TXT record that either provides the details 
or points to the impressum (e.g. URL).




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

2022-10-20 Thread Slavko via mailop

Dňa 20. októbra 2022 12:51:42 UTC používateľ Jaroslaw Rafa via mailop 
 napísal:

>So basically they require anybody who runs a mail server to put their street
>address and telephone number online to be publicly available???

Perhaps not really. How they can verify, that published  phone number is
really your? Yes, they can call, but do they speak in all world's languages?
I do no speak German... And even, how they want to verify name and/or
address? At least in our country, the citizen's register is not public.

In other words, if one want to publish that imprint, he/she can try to fill
random things in it in most of the world.

Anyone little experienced with Internet know, how problematic (even
impossible) is to remove information from it, when it was published,
see [1]

>Of course, as I would have to publish that information myself, it does not
>*literally* and *formally* violate the GDPR, but it is completely
>contradictory to the "spirit" of GDPR and the whole idea why that
>regulation was introduced.

That is whole idea why GDPR was introduced, to the big cannot do
anything, but someone have to complain...

BTW, when i look their SMTP IPs, i found that they link DNSWL.org [2] site
with these IPs. I take look at numbers of emails, which DNSWL sees and
the numbers are pretty low. Thus despite how big ISP they are, it doesn't
seems as big email provider and whole this thread can be mainly "internal"
Germany problem, not worth to waste time on it for most of others.

I will leave their SMTPs in my blacklist, just for reciprocity... But i am sure,
that i will remove it after some time, as checking it is wasting of resources
only.

regards

[1] https://web.archive.org/web/20221019213340/https://katara.bbmk.org/
[2] https://www.dnswl.org/s/?s=1972


-- 
Slavko
https://www.slavino.sk/
___
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 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 in the world?), on the basis that pictures of
individuals' houses were available online for anybody to view?

Something's completely inconsistent here.


One could hold that view, yes. OTOH, it's what Deutsche Telekom
requests from you, not the state ...


As someone already said in this discussion, while the requirement to put
such data online is perfectly valid for companies, for individuals it's
nothing more than an endorsement for criminal activity.


Well, just use your ISP's submission service, problem solved.
Or pay someone to MX you domain, problem solved.


If some madman does not like what I write anywhere on the Internet (for example
on my blog,


As a German, you have to have an imprint on anything that is considered a
"service", yes, even on your personal, non-monetized blog. It the law ;) And
also off-topic here.


I would understand if I had to provide this information *to T-Online only*,
so they can contact me in case of any malicious activity from my server, but
there is no way I put this information publicly available.


I could see some GDPR questions with that, so I can understand they
don't want to start such an internal database. Hence "ony commercial
servers are allowed", make some kind of sense to me.


[…] on this absurd
requirement. It cannot be even justified by German law, which requires (as
far as I know) *German* websites to have such an impressum, because people
operating mail servers who may want to send mail to T-Online are not
necessarily German, so German law does not apply to them.


Well, it's a kind of non-written contractual agreement: you want your
mailserver to be able to sent to t-online.de, they want to know who you are.
You're free not to agree to the terms, so where's law involved anyway?

Again: I strongly oppose reject-unless-whitelisted-before for an automated
service like SMTP. But I don't see a legal lever against it (with one
exception noted yesterday), and as this basically only puts a strong burden
on private people running personal mailservers – which is what percentage
on global mail traffic? –, frankly: who cares? As you pointed out, any
business basically has to have their contact details present on the Internet
anyway.

And, to point this out again: the subject of this thread already has been
disproven — t-online.de/Deutsche Telekom/t...@rx.t-online.de is still white-
listing personal mailservers, as long as the criteria on their postmaster
page are met.

No policy change as far as I can see, just a new wording on rejection. Same
old, IMHO shitty, policy, but well.

So: move on, nothing to see here ;)
-kai

___
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

2022-10-20 Thread Kirill Miazine via mailop

• Kirill Miazine via mailop [2022-10-19 19:21]:
[...]
> 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.

And there I've received a response:


Thank you very much for your message.

We only allow evidently commercial or similar operators to connect to
our mailservers. So, please use an SMTP relay or e-mail gateway of your
hoster or ISP, that you can use as part of your contract with them.
Their support will surely help you to configure your system accordingly.

However, from our point of view, a host would be evidently commercial if
it fulfills all the requirements an recommandations from the first two
paragraphs of section 4.1 of our FAQ; see
.


I responded back stating that the technical requirements are met, but
contact details not disclosed for privacy reasons, while postmaster@
& co being fully operational for any required contact regarding the
operation of the mail server.

We'll see...

Stay tunded...

K.
___
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

2022-10-20 Thread Renaud Allard via mailop




On 10/20/22 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???



Now, one has to wonder how they can verify if the information is 
correct? And also, what are the risks of providing fake information?


What if I say in my impressum something like this:
Jorge Mario Bergoglio
Lungotevere Castello, 50
00193 Roma RM, Italia
+39066819111
tonl...@mydomain.com

OK, that one is obviously fake, but the data is coherent.



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

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?

Something's completely inconsistent here.

Of course, as I would have to publish that information myself, it does not
*literally* and *formally* violate the GDPR, but it is completely
contradictory to the "spirit" of GDPR and the whole idea why that
regulation was introduced.

As someone already said in this discussion, while the requirement to put
such data online is perfectly valid for companies, for individuals it's
nothing more than an endorsement for criminal activity. If some madman does
not like what I write anywhere on the Internet (for example on my blog,
which is on the very same website as that "impressum"), or on some forum
where I register with an email address, knowing where I live he can come to
me to beat me up. Or knowing my telephone number he can call me at random
times (for example wake me up in the night) and threaten me over the phone
or just annoy me saying stupid things.

I would understand if I had to provide this information *to T-Online only*,
so they can contact me in case of any malicious activity from my server, but
there is no way I put this information publicly available.

I have a personal website that is under my domain. There's a lot of
information about me there. One can learn how old I am, what company I'm
working for, there is even my picture, and there are also a lot of articles
I wrote for various magazines on Internet related topics (I was a journalist
some time ago). Doesn't this prove that my server is a genuine one at least
good enough as putting up my home address or personal telephone number
online?

I would be *really very* interested to hear T-Online's representatives (who,
as somebody mentioned, are on this list) statement on this absurd
requirement. It cannot be even justified by German law, which requires (as
far as I know) *German* websites to have such an impressum, because people
operating mail servers who may want to send mail to T-Online are not
necessarily German, so German law does not apply to them.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
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


Hello,

Bernardo Reino via mailop wrote on 20.10.22 at 09:01:


I wasn't aware of the timing aspect, so thank you for this!


that's at least what I understood back in the days. :-) Whether there's 
a more fine-grained approach, differentiation by ISP reputation and 
other factors, I don't know. I have my machines at Hetzner, too, and I 
think I had to unblock all new IPs in the same way. The IP I used before 
was working without explicit unblocking, but I had it in use for some 
years already.


Florian
___
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

2022-10-20 Thread Dominique Rousseau via mailop

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 ?


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
___
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