[mailop] IngramMicro spam

[Eric Tykwinski via mailop]

Just a heads up…  Seems I’m getting IngramMicro spam phishing attempts passing 
DKIM/SPF so probably a hacked account there sending email:
[2022.10.21] 18:40:35.911 [37157707] [148.163.152.203] Valid reverse DNS entry 
found: mx0b-0021cb01.pphosted.com
[2022.10.21] 18:40:36.536 [37157707] Running SPF check
[2022.10.21] 18:40:36.536 [37157707] Finished SPF check; result = Pass
[2022.10.21] 18:40:36.536 [37157707] [DKIM] Performing DKIM check...
[2022.10.21] 18:40:36.552 [37157707] [DKIM] Result: Good. 
[2022.10.21] 18:40:38.083 [37157707] Spam Checks took 2161 ms
[2022.10.21] 18:40:38.083 [37157707] Spam Checks completed.

Headers:
Return-Path: 
Received: from mx0b-0021cb01.pphosted.com (mx0b-0021cb01.pphosted.com 
[148.163.152.203]) by smartermail.truenet.com with SMTP
(version=TLS\Tls12
cipher=Aes256 bits=256);
Fri, 21 Oct 2022 18:40:30 -0400
Received: from pps.filterd (m0096139.ppops.net [127.0.0.1])
by mx0b-0021cb01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29LLW5Dl031862;
Fri, 21 Oct 2022 15:38:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingrammicro.com; 
h=message-id :
reply-to : from : to : subject : date : mime-version : content-type;
s=PPS-Aug2020; bh=KMWrk6rOSKKUSW/SA9MDwca6MwSSasYRpvGaeP5JQZE=;
b=OmsimosZ9NIqdbr59AnmGipXTQVyuwCmSS7glFFIUFrCAqzATh0djj5ZJE1aSywsblsR
LUBj/rRC2x6hNivvxONfpnFnIUGanVmFEmFr7EwTG7YNlT+xaU9qqYynlW4ZnI4CbrGm
5J83FuQecT26/LxWAbmDcI6lnYpLxvz/wfENDueoEaMyrWy6ApH6gv7jEZlnx/i6/dGl
bG99ccz0fxe73QlVO5Ng3Gvfx//dUUujLZ5sTxF+dLz+h50yd/1A7gOK8f8dPu5/Xuz1
9vm7uyZpwzWoB7JVhWd1dCvvPk7lDhVBTW8gbOApA6JEpD6tZNkjrhbvjVAnRephy+UM jg== 
Received: from mailrelay.ingrammicro.com (smtp1202.ingrammicro.com 
[64.40.229.202])
by mx0b-0021cb01.pphosted.com (PPS) with ESMTPS id 3kbyv9sdyp-20
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 21 Oct 2022 15:38:15 -0700
Received: from USCHIZWXCH1203.corporate.ingrammicro.com (10.22.120.203) by
USCHIZWXCH1202.corporate.ingrammicro.com (10.22.120.202) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2507.9; Fri, 21 Oct 2022 15:38:13 -0700
Received: from lsmtp33.ingrammicro.com (10.133.22.108) by
uschizrelay.corporate.ingrammicro.com (10.22.120.203) with Microsoft SMTP
Server id 15.1.2507.9 via Frontend Transport; Fri, 21 Oct 2022 15:38:08 -0700
Message-ID: 
Reply-To: AEX 
From: AEX 
To: 
Subject: American Express Alert: Card Dispute Notice
Date: Fri, 21 Oct 2022 18:38:40 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="0a0c45ee1adef4fb08a2eb445095ba0223e9"
X-Proofpoint-ORIG-GUID: theT2AhoXJXb9CDUOt1sYWwZM47wrZCp
X-Proofpoint-GUID: theT2AhoXJXb9CDUOt1sYWwZM47wrZCp
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 
score=25 mlxlogscore=47
priorityscore=1501 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=25
adultscore=0 phishscore=34 clxscore=1011 lowpriorityscore=0
impostorscore=0 mlxscore=25 classifier=spam adjust=0 reason=mlx
scancount=1 engine=8.12.0-220913 definitions=main-2210210131

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

___
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

[Slavko via mailop]

Dňa 21. októbra 2022 19:14:06 UTC používateľ Laura Atkins via mailop 
 napísal:
>No, they belong to all senders.
>
>For instance, my mail server can connect and send mail to t-online.  I’m not 
>the only person who has said that in this thread. 

Do you mean the wordtothewise.com?

regards


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

[Julian Bradfield via mailop]

On 2022-10-21, Kai 'wusel' Siering via mailop  wrote:

[ in reply to a poster who had pain setting up new mxes ]

> To stay ontopic here, the question is: _why_ were you getting "blocks left 
> and right"? And what were they?
>
> Was it a "fresh & clean" IPv4 address or one that had been abused in the 
> past? What did the RBL checking tools tell you about that IP?
>
> Did the IP belong to an ISP that people that have to deal with remote abuse 
> do wrinkle their nose at?
>
> And, most importantly: did you have to contact any postmaster to get that 
> IPv4 address, with matching PTR and A records, proper SPF and DKIM entries, 
> whitelisted to access their MXes at all?

Yes. In the last 18 months, I've had cause to move both my primary and
secondary MXes to different VPS providers. For both of them, Microsoft
had the addresses on their internal blocklist. In both cases, the
addresses themselves had no history, but were on the same /24 as hosts
that did have a history. In both cases, I successfully jumped through
the Microsoft hoops, and got them unblocked. This required not just
being compliant, but providing proof of purchase and date of purchase
of the addresses. It took a few days and three or four emails each
time.

Gmail is also a bit sensitive, but in my experience can be
assuaged purely mechanically by carefully following all compliance
requirements, including the ones I wouldn't otherwise bother with.
Which is just as well, because there's no known way of contacting a
human at Gmail, whereas Microsoft give you a real human after the
first escalation.

Currently neither I nor any of my users have any t-online.de
correspondents, so I haven't tried dealing with them.
___
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

[Jarland Donnell via mailop]

Because this topic appears to be generating so much interest, I'll toss 
my data into the ring. Data helps everything. I'm typing this 
progressively as I do the work, so that's why it doesn't read like 
something in which I've already reached a conclusion before typing it.


I know I work my butt off to keep my outbound systems from sending out 
spam, but I largely go unrecognized as while we're a very highly 
utilized ESP, we're definitely not big enough that people routinely 
think of us or even recognize us as a whole. Our utilization is, 
however, above average and I feel like this is a good data set:


root@zmta1:/var/log# zgrep t-online.de syslog* | grep REJECT | wc -l
299
root@zmta1:/var/log# zgrep t-online.de syslog* | grep ACCEPT | wc -l
1718

That goes from September 21st to today. So I'm looking at, rounded up, 
about 15% rejection rate by t-online.de. For comparison, let's pull the 
same data points for Gmail which I expect to have a much larger data set 
for:


root@zmta1:/var/log# zgrep gmail.com syslog* | grep REJECT | wc -l
40292
root@zmta1:/var/log# zgrep gmail.com syslog* | grep ACCEPT | wc -l
1971913

So around 2% rejection rate by Gmail, and around 15% by t-onilne.de. The 
thing I don't like about comparing these two, though, is that my 
t-online.de numbers are so small that I'm uncertain if I can draw a 
conclusion that the 15% rejection rate is comparatively high. So what if 
I include some stats on sending domains and their relation to the same? 
I mean, for all I know in that data set from that test alone, 290 out of 
299 rejections only account for one user. Let's see what I get:


root@zmta1:/var/log# zgrep t-online.de syslog* | grep REJECT | awk 
-F'from=' '{print $2}' | awk '{print $1}' | awk -F'@' '{print $2}' | 
sort | uniq | wc -l

22
root@zmta1:/var/log# zgrep t-online.de syslog* | grep ACCEPT | awk 
-F'from=' '{print $2}' | awk '{print $1}' | awk -F'@' '{print $2}' | 
sort | uniq | wc -l

168

Then again for Gmail:

root@zmta1:/var/log# zgrep gmail.com syslog* | grep REJECT | awk 
-F'from=' '{print $2}' | awk '{print $1}' | awk -F'@' '{print $2}' | 
sort | uniq | wc -l

2884
root@zmta1:/var/log# zgrep gmail.com syslog* | grep ACCEPT | awk 
-F'from=' '{print $2}' | awk '{print $1}' | awk -F'@' '{print $2}' | 
sort | uniq | wc -l

14506

Now I confess that my data set would be receiving new data as I 
progressively went through these, which is more likely to favor Gmail 
than t-online.de as should be obvious by this point. The conclusions in 
the end were:


T-Online.de Sept21-Oct21:
299 rejections for 22 domains
1718 accepted for 168 domains

Gmail Sept21-Oct21:
40292 rejections for 2884 domains
1971913 accepted for 14506 domains

Useless data? Perhaps, but it's data, feel free to make use of it.

On 2022-10-21 14:14, Laura Atkins via mailop wrote:

No, they belong to all senders.

For instance, my mail server can connect and send mail to t-online.
I’m not the only person who has said that in this thread.

Laura

Sent from my iPhone


On Oct 21, 2022, at 6:49 PM, Gellner, Oliver via mailop
 wrote:






Am 21.10.2022 um 18:43 schrieb Laura Atkins via mailop
:



The above statement is untrue. I know a number of mailservers that
are able to successfully send mail to t-online.de [1] and have
never contacted the tosa@ address.


Since when do those mailservers exist? Do they belong to a large
ESP?

—
BR Oliver
-

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de [2]
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

-

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum
in Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung
stehen oder sich bei uns bewerben, verarbeiten wir personenbezogene
Daten. Informationen unter anderem zu den konkreten
Datenverarbeitungen, Löschfristen, Ihren Rechten sowie die
Kontaktdaten unserer Datenschutzbeauftragten finden Sie hier [3].



Links:
--
[1] http://t-online.de
[2] http://www.dmtech.de
[3] 
https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832

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

___
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

[Grant Taylor via mailop]

On 10/21/22 1:02 PM, Jaroslaw Rafa via mailop wrote:
As many have pointed out, putting this information online may be 
harmful to privacy and even facilitate criminal acts against you.


I still feel like there is room for an abstraction layer wherein you 
provide a postal address and telephone number which does (eventually) 
make it to you, but does not expose personal / private information. 
E.g. "You can contact us via our legal representative at $POSTAL_ADDRESS 
and $PHONE_NUMBER."


You are talking about a "company", while the whole thread started 
with the problem that *private* (non-commercial) mail servers run 
by *indiiduals* (not companies) have trouble delivering mail to 
t-online.de...


Ignoring the privacy implications for a few minutes, my understanding is 
that private (non-commercial) mail servers can also put the same 
information / imprint / impressum on their web site and thereby qualify 
to be white listed by T-Online.  Is that not correct?




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

[Laura Atkins via mailop]

No, they belong to all senders.

For instance, my mail server can connect and send mail to t-online.  I’m not 
the only person who has said that in this thread. 

Laura 


Sent from my iPhone

> On Oct 21, 2022, at 6:49 PM, Gellner, Oliver via mailop  
> wrote:
> 
>  
>>> Am 21.10.2022 um 18:43 schrieb Laura Atkins via mailop :
>>> 
>> The above statement is untrue. I know a number of mailservers that are able 
>> to successfully send mail to t-online.de and have never contacted the tosa@ 
>> address. 
> 
> Since when do those mailservers exist? Do they belong to a large ESP?
> 
> — 
> BR Oliver
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
> hier.
___
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

[Jaroslaw Rafa via mailop]

Dnia 21.10.2022 o godz. 10:26:58 Michael Peddemors via mailop pisze:
> T-Online isn't the only one that wants to see a website associated with the
> domain in the PTR record, frankly others do that as well, and best practices
> say that website should have contact information available.

Contact information, yes, but what information exactly?
My opinion is that if I have my email address on my website,that's
sufficient contact information.

T-Online requires a telephone number (confirmed in this thread by a quote
from their message) and probably street address (unconfirmed).

As many have pointed out, putting this information online may be harmful to
privacy and even facilitate criminal acts against you.

> If you can't put up an associated webpage or redirect the URL to your
> company website, well.. frankly the confidence level in your ability to
> prevent abuse to our customers from your server drops considerably.

You are talking about a "company", while the whole thread started with the
problem that *private* (non-commercial) mail servers run by *indiiduals*
(not companies) have trouble delivering mail to t-online.de...
-- 
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

[Gellner, Oliver via mailop]

Am 21.10.2022 um 18:43 schrieb Laura Atkins via mailop :

The above statement is untrue. I know a number of mailservers that are able to 
successfully send mail to t-online.de and have never 
contacted the tosa@ address.

Since when do those mailservers exist? Do they belong to a large ESP?

—
BR Oliver

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
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

[Michael Peddemors via mailop]

T-Online isn't the only one that wants to see a website associated with 
the domain in the PTR record, frankly others do that as well, and best 
practices say that website should have contact information available.


I don't think that is unreasonable ask, especially if traffic from that 
location triggers or trips a 'suspicious' flag.


In Gmails' case, they as for a SPF record.. everyone can ask for 
whatever evidence they need to suggest that a responsible party is 
behind the operation of that mail server..


And given our experience in email threat analysis, (you want a couple 
thousand examples of throwaway domains being stood up to send spam 
without an associated URL every day?) we also strongly recommend that as 
a Best Practice if you want to run an email server, that you do this as 
well.  Was trying to find that M3AAWG document that also suggested that.


Not to say that there aren't some professional spammers who already 
throw up a fake accompanying website with fake contact information, so 
it isnt' a perfect solution, but I can understand if they want to vet 
traffic from a mail server, using that technique makes a lot of sense.
(And of course the spammers that forge someone else's domain in their 
PTR records)


Worst case of course, there are some ESP's that don't do this simple 
Best Practice, so hopefully T-Online applies the same principles to them 
as well.


If you can't put up an associated webpage or redirect the URL to your 
company website, well.. frankly the confidence level in your ability to 
prevent abuse to our customers from your server drops considerably.


IMHO..

Now I really do have to do, there is this guy with a Gmail account who 
says he has $2.3M waiting for me..


On 2022-10-21 10:03, Zack Aab via mailop wrote:
Just to throw my experience in the ring in case it's helpful to anyone: 
I had a sender deliver just fine to T-Online until a couple of weeks ago 
when they were blocked for (what I determined after conversation with 
tosa@) not having a website with contact info available at the outbound 
mta's parent domain name (ehlo outbound._mtaparentname_.com).  Once a 
website redirect was put up they unblocked.  I'm guessing it's some 
combination of automated crawling for contact info and manually 
unblocking the false negatives as they come up (as people who monitor 
their bounces reach out).

Just my $0.02.
*Zack Aab* (He/him)
Consultant, Packaged Technology Operations, Shift Paradigm
*O* +1 (512) 717-4097  | *C* +1 (404) 317-6729 
 | *W* shiftparadigm.com 



On Fri, Oct 21, 2022 at 12:52 PM Grant Taylor via mailop 
mailto:mailop@mailop.org>> wrote:


On 10/21/22 10:30 AM, Laura Atkins via mailop wrote:
 > I know a number of mailservers that are able to successfully send
mail
 > to t-online.de  and have never contacted the
tosa@ address.

I wonder if that hints at a thus-far un-discussed aspect of T-Online's
policy.

There is every chance that T-Online did some sort of analysis of email
traffic to identify likely legitimate senders and primed their white
list with those domains / IPs.  E.g. ratio of outgoing messages to
domains / IPs verses spam complaints therefrom.

Similarly, I suspect that T-Online also primed their white list with
the
email oligarchies.  --  If I can borrow / re-use what I consider to be
an apt description.

After all, every single list has to start from something.  Good lists
organically grow (and shrink) over time as needed.



-- 
Grant. . . .

unix || die

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



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




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Zack Aab via mailop]

Just to throw my experience in the ring in case it's helpful to anyone: I
had a sender deliver just fine to T-Online until a couple of weeks ago when
they were blocked for (what I determined after conversation with tosa@) not
having a website with contact info available at the outbound mta's parent
domain name (ehlo outbound.*mtaparentname*.com).  Once a website redirect
was put up they unblocked.  I'm guessing it's some combination of automated
crawling for contact info and manually unblocking the false negatives as
they come up (as people who monitor their bounces reach out).
Just my $0.02.
*Zack Aab* (He/him)
Consultant, Packaged Technology Operations, Shift Paradigm
*O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729>
| *W* shiftparadigm.com 


On Fri, Oct 21, 2022 at 12:52 PM Grant Taylor via mailop 
wrote:

> On 10/21/22 10:30 AM, Laura Atkins via mailop wrote:
> > I know a number of mailservers that are able to successfully send mail
> > to t-online.de and have never contacted the tosa@ address.
>
> I wonder if that hints at a thus-far un-discussed aspect of T-Online's
> policy.
>
> There is every chance that T-Online did some sort of analysis of email
> traffic to identify likely legitimate senders and primed their white
> list with those domains / IPs.  E.g. ratio of outgoing messages to
> domains / IPs verses spam complaints therefrom.
>
> Similarly, I suspect that T-Online also primed their white list with the
> email oligarchies.  --  If I can borrow / re-use what I consider to be
> an apt description.
>
> After all, every single list has to start from something.  Good lists
> organically grow (and shrink) over time as needed.
>
>
>
> --
> Grant. . . .
> unix || die
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
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

[Kai 'wusel' Siering via mailop]

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 schrieb Renaud Allard via mailop:

Being a packager for exim, I can tell you that this has probably not the 
slightest chance of occurring.
A packagers "job" is not to modify the default config to express his political 
views, but to make the least amount of modifications to make it work on the OS/platform 
they are packaging it to.

I don't like what t-online does as it hurts interoperability, but banning a specific company/individual in a _default_ configuration is not the way to go. 


As it doesn't "hurt" interoperability, but technically inhibits it, reflecting 
this in the default configuration is the way to go.

As it is now, default configuration of postfix delays mail to @t-online.de for 
5 days and than bounces it. Dunno if Exim has an ignore-554-greeting flag as 
well and if, if it is on by default also. Either case, no default configuration 
is able to successfully send to @t-online.de when used on a new server.

Since that's a known fact now, thanks to this thread, the default 
configurations of MTAs should reflect this interoperability issue with 
t-online.de. It's a purely technical setting, reflecting the unconventional, 
non-industry-standard configuration of t-online.de, ensuring the MTA is not 
generating useless traffic and friction for the users and operators. On what 
grounds should that lead to a litigation?

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

[Grant Taylor via mailop]

On 10/21/22 10:30 AM, Laura Atkins via mailop wrote:
I know a number of mailservers that are able to successfully send mail 
to t-online.de and have never contacted the tosa@ address.


I wonder if that hints at a thus-far un-discussed aspect of T-Online's 
policy.


There is every chance that T-Online did some sort of analysis of email 
traffic to identify likely legitimate senders and primed their white 
list with those domains / IPs.  E.g. ratio of outgoing messages to 
domains / IPs verses spam complaints therefrom.


Similarly, I suspect that T-Online also primed their white list with the 
email oligarchies.  --  If I can borrow / re-use what I consider to be 
an apt description.


After all, every single list has to start from something.  Good lists 
organically grow (and shrink) over time as needed.




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

[Laura Atkins via mailop]

> On 21 Oct 2022, at 17:16, Kai 'wusel' Siering via mailop  
> wrote:
> 
> Moin,
> 
>> Consider T-Onlines move more like the overall accepted policy of not 
>> accepting mail from IPs that somehow have traces of residential in their PTR 
>> (cable, dialup etc.)?
> 
> No. As it's not relevant what your PTR says, you are always 554'd until you 
> contact t...@rx.t-online.de. Add a second IP to your mail-out.fqdn? 50% 
> 554's. As you put it: "That is the trouble with examples." ;-)

Just so we don’t end up in a position where people spread this disinformation. 

The above statement is untrue. I know a number of mailservers that are able to 
successfully send mail to t-online.de  and have never 
contacted the tosa@ address. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
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

[Kai 'wusel' Siering via mailop]

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 
blocks left and right -


To stay ontopic here, the question is: _why_ were you getting "blocks left and 
right"? And what were they?

Was it a "fresh & clean" IPv4 address or one that had been abused in the past? 
What did the RBL checking tools tell you about that IP?

Did the IP belong to an ISP that people that have to deal with remote abuse do 
wrinkle their nose at?

And, most importantly: did you have to contact any postmaster to get that IPv4 
address, with matching PTR and A records, proper SPF and DKIM entries, 
whitelisted to access their MXes at all?


Let me agree that blocking a provider by default does not seem wise.

Your end-users don't care, for them it just "does not work". They are not interested in 
"politics", and if their e-mail doesn't work, they just go with a different service. 
People are lazy and people want practical solutions.


Exactly, people are lazy, they don't want to spend 15 minutes to write a longer email 
which then sits 5 days in the mailer's outgoing queue and finally comes back with a 
cryptic message like "A problem occurred. (Ask your postmaster for help or to 
contact t...@rx.t-online.de to clarify.)".

Postmasters are people, too. They as well don't want such a shit show. _They_ 
didn't do anything wrong to deserve that treatment.


Second, where to start and where to end? There seem to be quite a few mail 
operators who block, let's say, a bit arbitrary.


There is one known public mail service that blocks universally, not just arbitrarily. 
Given that, default MTA configuration should be "don't talk to them as the won't let 
you talk back". Saves peoples time and nerves, therefore a very pragmatic, and very 
practical solution.

If your customers *request* to talk to t-online.de users, you still can 
negotiate with tosa@rx and then reflect that in your MTA configuration.


Blocking all of them makes things worse, and then the fear of e-mail getting 
into the hand of a few single big players becomes a self-fulfilling prophecy. 
Nobody wants to be on a mail server that can only connect to very few selected 
sites, whatever the reason, and how good the motivations might be.


Well, mostly no-one using a @t-online.de mailbox knows about their provider's 
block-by-default policy. And no customer ever notices, as *their* mail is 
deviously delivered to any domain there is. But they don't get a reply, giving 
the _receipient_ a bad reputation in their eyes. Whereas it's their very own 
mail provider that is inhibiting the replies to them.

As such, disabling reception of @t-online.de mail per default – until the way 
back is mutually agreed on – is the best way to solve this. It makes the harm 
t-online.de creates visible to their users and prevents communication delays 
and blackholes.


Third, I guess the deployment cycles are rather long - so what you add to a 
package right now will very likely not end up on a majority of machines for 
months, years, whatever. And who knows if distributions will incorporate 
anything of that, so it seems a lot of work with very little predictable result.


Every Change has to start somewhere. This is a plague for 10+ years now; if 
from, say 2023, or 2024, new MTA deployments start to save the users from the 
pitfalls of the t-online.de setup, it is a start. Usually existing 
configurations aren't overwritten, so this will help only on new installations 
or manual upgrades, where configuration parameters are copied over manually.


I am just a small operator for a rather specific use case here, so I can only 
assume the amount of pain and frustration bigger operators must go through.


Speaking as the operator of two really tiny mail servers myself, I rather 
assume that the most pain and frustration is created there.

I doubt that it would take GMX more that one single mail to tosa@rx if they change IPs in 
their sending pool. Question is if they even would notify t-online.de upfront anyway. 
Would Google, Microsoft? "T what?"
I actually expect that t-online.de proactively monitors known webpages or DNS records of 
the big players — what they do not want, are major tabloids doing headlines like 
"T-Online messes up it's mail service".


Am 21.10.22 um 16:40 schrieb Florian Effenberger via mailop:

Well Germans are not what they used to be , so maybe that one considered your 
insistence enough to whitelist you.. or perhaps the decision of when a server 
is commercial or not is not /that/ well-defined for them.


maybe the term "commercial" here stems from the German imprint requirements.


It's »geschäftsmäßig« in TMG §5 (1), not commercial. Telekom states mailservers would 
need to be run by "commercial" (»kommerziellen«) operators. 

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

[Kai 'wusel' Siering via mailop]

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


It would most probably not be a problem with verein.de, which most probably 
runs a website, and thus already has an imprint stating their board, their 
register number and court in addition to address and mail or telephone — as 
they are required by law. That is the trouble with examples.


Sorry, but you deviate from the facts: i...@verein.de is being harassed by 
t-online.de a) by delivering a message from one of it's users *although* 
t-online.de *knows* that the receipient cannot answer and b) by responding with 
554 to the reply, which is now lost.

Whether or not verein.de has a website is irrelevant. What *is* relevant though 
is that for every but one public mail service there would be no 554, and that 
one exemption is t-online.de. This should be reflected in MTA default 
configurations: mail exchange from and to @t-online.de has to be enabled 
manually as per t-online.de's policy.

Someone mentioned that B2B mailservers might be configured "like t-online.de", 
that is only talking to whitelisted peers. Might be, but that's just another misleading 
example.


Consider T-Onlines move more like the overall accepted policy of not accepting 
mail from IPs that somehow have traces of residential in their PTR (cable, 
dialup etc.)?


No. As it's not relevant what your PTR says, you are always 554'd until you contact 
t...@rx.t-online.de. Add a second IP to your mail-out.fqdn? 50% 554's. As you put it: 
"That is the trouble with examples." ;-)



Am 21.10.22 um 13:28 schrieb Gellner, Oliver via mailop:


Verein would still be impacted because having an imprint alone doesn't help. A 
mail operator of verein.de would still have to manually contact t-online.de to 
have their MTA IP addresses added to their whitelist. A distributed system like 
email does not work if everyone has to contact the operators of other MTAs over 
an out of band channel first before being able to send a message.


This. Of course one *can* do that, but than this should be properly reflected 
in MTA default configurations and even BCP documents. Even if it's just an odd 
mail provider from Germany, hence mostly irrelevant for the world at large.
-kai

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

[mailop] Gesty and OVH behavior questions.. Shutting down early for the weekend.

[Michael Peddemors via mailop]

Well, first rain in the Pacific Northwest in three months, the trees and 
the grass are happy .. and as a good excuse as any to make it a short week.


But wanted to get this out for questions over the weekend.

Gesty.. I think we all know this actor, and see their footprint all over 
the place, including other ESP's and large providers.


Today, we see it coming from a notorious leaky source, "register.it"
Headers show it's authenticating from ADSEUROPE IP space, using ,,

Received: from NubeGestyFor ([188.93.78.25]) by cmsmtp with ESMTPSA
X-Rid: s...@actualizatusconocimientos.es@

Brazilian spam.. Curious, has register.it started offering a relay 
service, or changed their rate limiters to allow this activity?


For OVH..

Seeing a large increase in email authentication attacks from OVH space, 
mostly with PTR matching this pattern..


PTR = vps-23594a8e.vps.ovh.net

Attempting password guessing, across all SMTP ports, 25,465,587.
They are easy to catch, and usually end up getting their IPs on an RBL, 
but one wider spread piece of activity we aren't getting enough insight 
into.


Has anyone else been observing activity from the following ranges?

Is it also AUTH attacks, or is it a spamming outbreak?

54.38.156.22(M,RS)4   vps-4aaf0480.vps.ovh.net
   54.38.156.117(M,RS)4   vps-9abd49af.vps.ovh.net
   54.38.156.124(M,RS)3   vps-d885dba6.vps.ovh.net
   54.38.156.236(M,RS)6   vps-d24f39b1.vps.ovh.net
54.38.157.137   (M,RS)2   vps-030cd424.vps.ovh.net
54.38.159.56(M,RS)6   vps-1f309a0e.vps.ovh.net
   54.38.159.160(M,RS)3   vps-8c808b2c.vps.ovh.net
   54.38.159.173(M,RS)2   vps-7486dda2.vps.ovh.net
   54.38.159.182(M,RS)3   vps-89b9e286.vps.ovh.net
   54.38.159.248(M,RS)3   vps-c4488cdd.vps.ovh.net
54.39.20.82 (M,RS)3   vps-a3424546.vps.ovh.ca
   54.39.20.114 (M,RS)4   vps-269f67c1.vps.ovh.ca
   54.39.20.127 (M,RS)6   vps-b035d0f7.vps.ovh.ca
   54.39.20.133 (M,RS)4   vps-4cb06eab.vps.ovh.ca
   54.39.20.163 (M,RS)5   vps-dd1983e4.vps.ovh.ca
   54.39.20.194 (M,RS)3   vps-f6c5066d.vps.ovh.ca
   54.39.20.201 (M,RS)2   vps-7f0b7cba.vps.ovh.ca
   54.39.20.226 (M,RS)3   vps-c3300741.vps.ovh.ca
54.39.21.2  (M,RS)4   vps-66246fa7.vps.ovh.ca
   54.39.21.7   (M,RS)6   vps-f621d01c.vps.ovh.ca
   54.39.21.44  (M,RS)6   vps-4dc0d5c3.vps.ovh.ca
   54.39.21.55  (M,RS)5   vps-1add25f7.vps.ovh.ca
54.39.22.110(M,RS)4   vps-29e7283d.vps.ovh.ca
54.39.23.155(M,RS)4   vps-ce4f0144.vps.ovh.ca
54.39.98.137(M,RS)5   vps-75f248d0.vps.ovh.ca
   54.39.98.145 (M,RS)5   vps-3f7f92b4.vps.ovh.ca
   54.39.98.150 (M,RS)1   vps-213ca2d3.vps.ovh.ca
   54.39.98.151 (M,RS)4   vps-857fc621.vps.ovh.ca
   54.39.98.155 (M,RS)4   vps-bdebdfa4.vps.ovh.ca
   54.39.98.171 (M,RS)3   vps-2679ef00.vps.ovh.ca
   54.39.98.174 (M,RS)3   vps-4d72b5c0.vps.ovh.ca
   54.39.98.181 (M,RS)4   vps-a341f4f0.vps.ovh.ca
   54.39.98.183 (M,RS)5   vps-e51a692b.vps.ovh.ca
   54.39.98.184 (M,RS)6   vps-d0b9760d.vps.ovh.ca
   54.39.98.186 (M,RS)5   vps-5cc70f61.vps.ovh.ca
   54.39.98.196 (M,RS)4   vps-337608d7.vps.ovh.ca
   54.39.98.199 (M,RS)4   vps-5c859463.vps.ovh.ca
   54.39.98.200 (M,RS)4   vps-d51ff7eb.vps.ovh.ca
   54.39.98.202 (M,RS)5   vps-a74457d6.vps.ovh.ca
   54.39.98.210 (M,RS)5   vps-fa388962.vps.ovh.ca
   54.39.98.222 (M,RS)5   vps-59084780.vps.ovh.ca
   54.39.98.227 (M,RS)3   vps-c35476ff.vps.ovh.ca
   54.39.98.241 (M,RS)3   vps-5d577433.vps.ovh.ca
54.39.99.35 (M,RS)4   vps-4503cbf9.vps.ovh.ca
   54.39.99.37  (M,RS)4   vps-7d627fcd.vps.ovh.ca
   54.39.99.40  (M,RS)3   vps-72369c5e.vps.ovh.ca
   54.39.99.43  (M,RS)4   vps-e131c50d.vps.ovh.ca
   54.39.99.44  (M,RS)5   vps-fa21cd75.vps.ovh.ca
   54.39.99.49  (M,RS)2   vps-af4febbd.vps.ovh.ca
   54.39.99.51  (M,RS)4   vps-42db1b0e.vps.ovh.ca
   54.39.99.52  (M,RS)6   vps-0cf43083.vps.ovh.ca
   54.39.99.53  (M,RS)3   vps-502ba72e.vps.ovh.ca
   54.39.99.54  (M,RS)4   vps-167bf86a.vps.ovh.ca
   54.39.99.56  (M,RS)1   vps-ab7b5ee5.vps.ovh.ca
   54.39.99.59  (M,RS)6   vps-1c17526f.vps.ovh.ca
   54.39.99.60  (M,RS)3   vps-23478e44.vps.ovh.ca
   54.39.99.61  (M,RS)4   vps-2f7e5534.vps.ovh.ca
   54.39.99.62  (M,RS)5   vps-9000a7c3.vps.ovh.ca
   54.39.99.63  (M,RS)6   vps-a3e9.vps.ovh.ca
   54.39.99.69  (M,RS)4   vps-43511e30.vps.ovh.ca
   54.39.99.76  (M,RS)5   

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

[Florian Effenberger via mailop]

Hello,

Bernardo Reino via mailop wrote on 21.10.22 at 16:32:

Well Germans are not what they used to be , so maybe that one 
considered your insistence enough to whitelist you.. or perhaps the 
decision of when a server is commercial or not is not /that/ 
well-defined for them.


maybe the term "commercial" here stems from the German imprint 
requirements. Websites that are not purely private (and that definition 
is very narrow, more narrow than the term might suggest) need an 
imprint. If they consider "commercial" the opposite of "private", that 
could explain it.


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

[Bernardo Reino via mailop]

On Fri, 21 Oct 2022, michael.zork--- via mailop wrote:


[...]

Here is my story:

[...]

I still didn't know what to do, so I asked again for details.

Two emails later they still didn't tell me what the exact problem was, so I 
put my postal address on the website, maybe that helps. It didn't, but I got 
this answer:



Die Forderung einer Anbieterkennzeichnung impliziert eine kommerzielle
oder vergleichbare Nutzung. Sie müssten hierfür unter "XXdomainXX"
noch Kontaktdaten zur "schnellen" elektronischen Kontaktaufnahme(*)
hinzufügen.

(*) Das kann entweder eine telefonische Rufnummer oder alternativ
ein Kontaktformular sein, sofern die Reaktionszeit kurz sein sollte.

[...]


That's interesting, because at least it seems to narrow down what they consider 
essential in the legal notice ("Impressum"). After having whitelisted my two 
servers in the last couple of days, I have removed the postal address in one, 
leaving only name, e-mail and telephone number, and also the phone number in the 
other, leaving only name and e-mail.


I don't expect any reaction to that, as I don't expect that they will actually 
monitor websites/impressum for changes (but who knows :)



Without any more discussion another support guy whitelisted my IP.


Well Germans are not what they used to be :), so maybe that one considered your 
insistence enough to whitelist you.. or perhaps the decision of when a server is 
commercial or not is not /that/ well-defined for them.


Cheers,
Bernardo___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[michael.zork--- via mailop]

Am 21.10.2022 um 13:28 schrieb Gellner, Oliver via mailop:

On 21.10.22 08:03, Johannes Posel via mailop wrote:

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 
mailto:some...@t-online.de mails to mailto: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 mailto:i...@verein.de receives the 
mail and reponds to it. *BÄM* 554.

It would most probably not be a problem with verein.de, which most probably 
runs a website, and thus already has an imprint stating their board, their 
register number and court in addition to address and mail or telephone — as 
they are required by law. That is the trouble with examples.

Verein would still be impacted because having an imprint alone doesn't help. A 
mail operator of verein.de would still have to manually contact t-online.de to 
have their MTA IP addresses added to their whitelist. A distributed system like 
email does not work if everyone has to contact the operators of other MTAs over 
an out of band channel first before being able to send a message.
Exactly... If there would be hundreds of big mailserver operators which 
do it like Deutsche Telekom, email would be a big mess and nearly unusable.


They seem to have a big IP whitelist. They write on their postmaster 
page that they don't do greylisting, SPF or DKIM That's why they 
(currently) totally rely on IP whitelisting.


I had exactly this problem a few weeks ago.

Here is my story:

I moved my server to Hetzner, let the Hetzner Support open port 25 after 
paying the invoice, and then I couldn't sent to t-online.de. I saw this 
5 days later when an email bounced to the sender. Luckily this was not 
an important email with a deadline or similar...


Because I knew they have a big IP whitelist, I contacted them with my 
usual "begging-email", which contained my domains, old IP, new IP, my 
name and so on.


Of cause I have proper reverse-DNS, abuse@ and postmaster@ are 
monitored, SPF, DKIM and DMARC is working, outbound spam protection, 
rate-limiting (in case an account gets hacked), everything perfect from 
my side. I'm running my own private mailserver since >15 years.


They responded:

Nachdem wir nur nachvollziehbar kommerziellen und vergleichbaren
Betreibern erlauben, sich mit unseren Mailservern zu verbinden,
verwenden Sie als/für Privatnutzer bitte ein SMTP-Relay bzw. Mailgateway
des Hosters oder ISPs, um E-Mails im Rahmen der vertraglichen Leistungen
vom Mailserver über dessen offizielles Mailgateway zu senden. Der
dortige Support ist Ihnen bei der Konfiguration sicherlich gerne
behilflich.

Translated:

Since we only allow comprehensible commercial and comparable
operators to connect to our mail servers,
as/for private users, please use an SMTP relay or mail gateway
of the hoster or ISP to receive e-mails within the scope of the 
contractual services

from the mail server via its official mail gateway. The
support will certainly be happy to help you with the configuration.
help you with the configuration.


I asked them a few questions, for example what "comprehensible 
commercial and comparable operators" means. And that I will not use my 
hosters relay, because a) Hetzner has no relay as far as I know, b) I 
don't want to give my email content (and emails of my friends and 
family) to Hetzner if I don't have to. GDPR+privacy and so on.


Answer from Telekom:

eine kommerzielle oder vergleichbare Nutzung ist nicht erkennbar und
liegt laut Ihrer Beschreibung auch nicht vor. Vergleichbar wäre es erst
dann, wenn eine Konfiguration vorliegt, die sich nach den in unserer
"Postmaster-FAQ"(*) beschrieben Punkten richtet. Für
"(http(s)://)(mx1.)XXdomainXX.de" ist dies bisher noch nicht gegeben.

Translated:

A commercial or comparable use is not recognisable and does not
exist according to your description. It would only be comparable
if there was a configuration that followed the points described
in our "Postmaster-FAQ"(*). This is not yet the case for
"(http(s)://)(mx1.)XXdomainXX.de".


An answer which didn't help at all, because I already had a small 
imprint-website (just for Deutsche Telekom since a few years, without 
them I wouldn't have a website on that domain) showing my name and email 
address as a method to contact me. That was enough during the last 15 years.


I still didn't know what to do, so I asked again for details.

Two emails later they still didn't tell me what the exact problem was, 
so I put my postal address on the website, maybe that helps. It didn't, 
but I got this answer:

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

[Taavi Eomäe via mailop]

On 21/10/2022 15:36, Bjoern Franke via mailop wrote:

And then tld.t-online.de sends e.g contact form spam from 
"anonym...@hostmaster.telekom.de" and produces backscatter. They don't 
even apply their own rules to their customers. Why should we accept 
mail from tld.t-online.de when we don't know who's reponsible for it? 


I think it has been mentioned multiple times in this massive thread, 
that you don't have to. Just like they don't.


However I wouldn't recommend taking the same allowlist-based approach. 
If you really-really want some attribution, just start requiring the 
existence of an SPF record.





Wishing you a good day,
Taavi



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

[Bjoern Franke via mailop]

Am 21.10.22 um 13:27 schrieb Gellner, Oliver via mailop:

On 20.10.22 20:30, Kai 'wusel' Siering via mailop wrote:

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.


t-online.de is not the only domain. You can host your domain there and all domains share 
the same spam "filtering" technique. So this is not restricted to email 
addresses ending with @t-online.de


And then tld.t-online.de sends e.g contact form spam from 
"anonym...@hostmaster.telekom.de" and produces backscatter. They don't 
even apply their own rules to their customers. Why should we accept mail 
from tld.t-online.de when we don't know who's reponsible for it?


Regards
Bjoern



___
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

[Gellner, Oliver via mailop]

On 21.10.22 08:03, Johannes Posel via mailop wrote:
>> 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 mailto:some...@t-online.de mails to mailto: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 mailto:i...@verein.de receives the mail and 
>> reponds to it. *BÄM* 554.

> It would most probably not be a problem with verein.de, which most probably 
> runs a website, and thus already has an imprint stating their board, their 
> register number and court in addition to address and mail or telephone — as 
> they are required by law. That is the trouble with examples.

Verein would still be impacted because having an imprint alone doesn't help. A 
mail operator of verein.de would still have to manually contact t-online.de to 
have their MTA IP addresses added to their whitelist. A distributed system like 
email does not work if everyone has to contact the operators of other MTAs over 
an out of band channel first before being able to send a message.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.


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

[Gellner, Oliver via mailop]

On 20.10.22 20:30, Kai 'wusel' Siering via mailop wrote:
> 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.

t-online.de is not the only domain. You can host your domain there and all 
domains share the same spam "filtering" technique. So this is not restricted to 
email addresses ending with @t-online.de

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.


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

[Henry R via mailop]

I found t-online.de and t-mobile.com have quite different mail policies. 
You can check these two domains of SPF and DMARC records.


Isn't t-mobile owned by t-online?

regards


Jaroslaw Rafa via mailop wrote:

One simple question (that I already stated in another email): did T-Online
announce clearly to their users that their email is a "gated community"?

___
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

[Jaroslaw Rafa via mailop]

Dnia 20.10.2022 o godz. 23:21:35 Grant Taylor via mailop pisze:
> 
> This type of security is often referred to as "gated communities".

One simple question (that I already stated in another email): did T-Online
announce clearly to their users that their email is a "gated community"?
-- 
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

[Jaroslaw Rafa via mailop]

Dnia 20.10.2022 o godz. 23:09:07 Grant Taylor via mailop pisze:
> 
> 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.

And that's an important (I would even say: critical) difference.

If you run a private mailserver that is, by definition, meant to receive
mail only from particular senders with whom you have pre-agreed to do so,
it's ok.

If you run a public email service to which everyone can sign up, you can't
predict with whom your users will want to communicate, so have to accept
mail from everyone (except *proven* bad actors).

Otherwise you can't call yourself a *public* email service anymore.

Does T-Online clearly message to *their customers* when signing up that "Our
e-mail service is NOT a public email service. We accept email only from a
selected group of senders. You CANNOT use our e-mail service to communicate
with anyone on the Internet"?

If there is such a clear disclaimer from T-Online to *their users*, then
they are OK. You can say this is a very shitty service, but they are OK in
sense they are honest to their users.

If there is no such disclaimer, they are dishonest. They pose as a regular,
publicly available email service while in fact they are not.

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

From what I explained above, I think that the difference is pretty obvious
and anyone who wants to suggest that there is no difference (like you in
these statements), is intentionally spreading misinformation.

Some time ago my bank provided to customers e-mail accounts on the bank's
server, which were accessible via POP. These accounts were created for
receiving information from bank, for example current account statements
after each transaction (btw. they still provide this service, but over
regular email - the dedicated accounts don't exist anymore). They made it
clear that while these accounts MAY work as regular email accounts, the bank
doesn't guarantee that I will be able to communicate with anyone outside the
bank.

These accounts were for particular purpose - communicating with the bank -
and they made it clear, so I wouldn't even think of complaining that I can't
for example send email from this account to my personal account, or receive
email sent from there. In fact I didn't even try.

But as far as I understand, it is not the case with T-Online. They don't
state that this is a "restricted" account, for example only for
communicating with T-Online staff or other T-Online users. They pose as
regular email.
-- 
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

[Renaud Allard via mailop]

On 10/21/22 04:13, Kai 'wusel' Siering via mailop wrote:

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.


Being a packager for exim, I can tell you that this has probably not the 
slightest chance of occurring.
A packagers "job" is not to modify the default config to express his 
political views, but to make the least amount of modifications to make 
it work on the OS/platform they are packaging it to.


I don't like what t-online does as it hurts interoperability, but 
banning a specific company/individual in a _default_ configuration is 
not the way to go.


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

[Florian Effenberger via mailop]

Hi,

Grant Taylor via mailop wrote on 21.10.22 at 07:09:

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


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 blocks left and right - I learned things the hard 
way, and yes, I was quite upset. I do this as a volunteer project, it 
cost me lots of time, pain and headache, and was a frustrating experience.


Let me agree that blocking a provider by default does not seem wise.

Your end-users don't care, for them it just "does not work". They are 
not interested in "politics", and if their e-mail doesn't work, they 
just go with a different service. People are lazy and people want 
practical solutions.


Second, where to start and where to end? There seem to be quite a few 
mail operators who block, let's say, a bit arbitrary. Blocking all of 
them makes things worse, and then the fear of e-mail getting into the 
hand of a few single big players becomes a self-fulfilling prophecy. 
Nobody wants to be on a mail server that can only connect to very few 
selected sites, whatever the reason, and how good the motivations might be.


Third, I guess the deployment cycles are rather long - so what you add 
to a package right now will very likely not end up on a majority of 
machines for months, years, whatever. And who knows if distributions 
will incorporate anything of that, so it seems a lot of work with very 
little predictable result.


Some perceive the behaviour as aggressive maybe, but reacting the same 
way rarely yields to good results - well, at least I try to be an 
optimist in life. ;-)


I don't have much insight into all those working groups and how the mail 
operators talk to each other, I am just a small operator for a rather 
specific use case here, so I can only assume the amount of pain and 
frustration bigger operators must go through.


However, in general, I think the first step to actually help people is 
to document things. Learning all these things can become quite tedious 
and exhausting, with multiple sources - explaining best practice can 
help many people a lot. Of course, not everyone is skilled to run a mail 
server, but then we all started small I guess, so helping those who get 
onto such role with proper and good documentation to avoid the most 
obvious pitfalls is a first step. If there is documentation available, 
at least the problems don't come as a surprise, whether one likes the 
policy or not.


Long-term, I do get quite worried about all the growing obstacles and 
enforced rules by mail operators that make it harder to deliver your 
mail and make self-hosting more and more problematic. That is 
frustrating nad makes me sad. However, and that is purely my personal 
experience, Telekom is amongst the nicest and easiest one to deal with...


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

[Johannes Posel via mailop]

Dear Kai,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 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.It would most probably not be a problem with verein.de, which most probably runs a website, and thus already has an imprint stating their board, their register number and court in addition to address and mail or telephone — as they are required by law. That is the trouble with examples. I'm totally fine with you disagreeing with my opinion. After all,
  you aren't impacted as I by the irresponsible and erratic way
  t-online.de is running their service, which indeed has a high
  locallity.It has indeed, so I’d also argue that blatant blocking is not the way to go. Consider T-Onlines move more like the overall accepted policy of not accepting mail from IPs that somehow have traces of residential in their PTR (cable, dialup etc.)?Best regards JohannesPS: considering reactivating the TOL address just for the fun of it. 

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

[Lena--- via mailop]

> From: Kai 'wusel' Siering 

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

I don't know why, but Exim's ${readsocket works without the "quit":

[root@lena ~]# time exim -be '${readsocket{inet:mx00.t-online.de:25}{}{2s}}!'
220-mailin78.mgt.mul.t-online.de T-Online ESMTP receiver fssmtpd ready.
220 T-Online ESMTP receiver ready.
!

real0m0.052s
user0m0.024s
sys 0m0.001s
[root@lena ~]# telnet mx00.t-online.de 25
Trying 194.25.134.8...
Connected to mx00.t-online.de.
Escape character is '^]'.
220-mailin82.mgt.mul.t-online.de T-Online ESMTP receiver fssmtpd ready.
220 T-Online ESMTP receiver ready.
quit
221-2.0.0 mailin82.mgt.mul.t-online.de closing.
221 2.0.0 Closing.
Connection closed by foreign host.
[root@lena ~]#

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