Re: [mailop] heads-up: Exchange Online: validation issues with Let's Encrypt DANE

[Kirill Miazine via mailop]

• Tobias Fiebig via mailop [2024-06-10 14:09]:
> Moin,
> are you sure the RRset is not inadvertently bogus? Can slip by rather
> easily for a set of reasons; Old RRSIGs vor example after one of the
> entries got updated?

no. LE TLSA RRs are generated automatically based on URL lists, so there
are neither dupes nor errors. zones are signed by ldns-signzone prior to
getting distributed to name servers for publishing.

> If not; Out of personal curiosity; can you test where 'the boundary' is
> to trigger the error? should be doable with like 4 test domains max
> (bin-search starting at 7 RR in the set).

_that_ was an interesting challenge indeed! the answer I got is 12: 12
TLSA RRs are OK, but when there are 13 or 14, emails are stuck somewhere
and would later trigger error message later on. (for sake of
completeness, I went all way with domains from 6 to 14 TLSA RRs)

> With best regards,
> Tobias
> 
> On Mon, 2024-06-10 at 12:36 +0200, Kirill Miazine via mailop wrote:
> > Apparently exchange online would provide an error to the user like
> > this:
> > 
> > dnssec-invalid: Destination domain returned invalid DNSSEC records
> > 
> > https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/ndr/non-delivery-reports-in-exchange-online
> >  
> > explains what this really means:
> > 
> > The destination domain indicated it was DNSSEC-authentic, but
> > Exchange 
> > Online wasn't able to verify it as DNSSEC-authentic.
> > 
> > So the guess is that Exchange Online is getting in trouble when there
> > are more than a few TLSA records...
> > 
> > • Kirill Miazine via mailop [2024-06-10 12:06]:
> > > Although there are better alternatives to 2 1 1 with Let's Encrypt,
> > > some 
> > > still use 2 1 1, and it seems Exchange Online is not happy when
> > > there 
> > > are 14 TLSA records (why 14? because 
> > > https://letsencrypt.org/certificates/)... A good reason to not use
> > > 2 1 
> > > 1
> > > 
> > >   ; TLSA - LE certs published at
> > > https://letsencrypt.org/certificates/
> > > -_le-tlsa   TLSA    2 1 1 
> > > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ;
> > > LE E1
> > > -   TLSA    2 1 1 
> > > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ;
> > > LE E2
> > > -   TLSA    2 1 1 
> > > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ;
> > > LE R3
> > > -   TLSA    2 1 1 
> > > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ;
> > > LE R4
> > > +_le-tlsa   TLSA    2 1 1 
> > > 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ;
> > > LE
> > > +   TLSA    2 1 1 
> > > d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7
> > > +   TLSA    2 1 1 
> > > 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba
> > > +   TLSA    2 1 1 
> > > 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7
> > > +   TLSA    2 1 1 
> > > cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75
> > > +   TLSA    2 1 1 
> > > 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5
> > > +   TLSA    2 1 1 
> > > f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
> > > +   TLSA    2 1 1 
> > > 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
> > > +   TLSA    2 1 1 
> > > 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d
> > > +   TLSA    2 1 1 
> > > f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
> > > +   TLSA    2 1 1 
> > > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
> > > +   TLSA    2 1 1 
> > > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
> > > +   TLSA    2 1 1 
> > > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
> > > +   TLSA    2 1 1 
> > > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
> > > ___
> > > mailop mailing list
> > > mailop@mailop.org
> > > https://list.mailop.org/listinfo/mailop
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> 
> -- 
> Dr.-Ing. Tobias Fiebig
> T +31 616 80 98 99
> M tob...@fiebig.nl
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

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

Re: [mailop] heads-up: Exchange Online: validation issues with Let's Encrypt DANE

[Kirill Miazine via mailop]

• Viktor Dukhovni via mailop [2024-06-10 22:06]:
> On Mon, Jun 10, 2024 at 12:06:26PM +0200, Kirill Miazine via mailop wrote:
> 
> > Although there are better alternatives to 2 1 1 with Let's Encrypt, some
> > still use 2 1 1, and it seems Exchange Online is not happy when there are 14
> > TLSA records (why 14? because https://letsencrypt.org/certificates/)... A
> > good reason to not use 2 1 1
> 
> The below includes four of the TLSA records twice, which is indeed
> invalid:
> 
> e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
> bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
> 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
> 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10

the paste in my email showed a diff from zone file... records mentioned
above had comments removed, so they showed up twice (once with - and
once with +)...

> Each RR should appear exactly once in an RRset.  Perhaps that's the
> problem and not the record count?  Do you still have the below published
> in live DNS?
> >  ; TLSA - LE certs published at https://letsencrypt.org/certificates/
> > -_le-tlsa   TLSA2 1 1
> > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; LE E1
> > -   TLSA2 1 1
> > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; LE E2
> > -   TLSA2 1 1
> > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; LE R3
> > -   TLSA2 1 1
> > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; LE R4
> > +_le-tlsa   TLSA2 1 1
> > 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; LE
> > +   TLSA2 1 1
> > d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7
> > +   TLSA2 1 1
> > 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba
> > +   TLSA2 1 1
> > 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7
> > +   TLSA2 1 1
> > cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75
> > +   TLSA2 1 1
> > 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5
> > +   TLSA2 1 1
> > f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
> > +   TLSA2 1 1
> > 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
> > +   TLSA2 1 1
> > 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d
> > +   TLSA2 1 1
> > f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
> > +   TLSA2 1 1
> > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
> > +   TLSA2 1 1
> > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
> > +   TLSA2 1 1
> > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
> > +   TLSA2 1 1
> > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
> 
> -- 
> Viktor.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

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

Re: [mailop] heads-up: Exchange Online: validation issues with Let's Encrypt DANE

[Kirill Miazine via mailop]

Apparently exchange online would provide an error to the user like this:

dnssec-invalid: Destination domain returned invalid DNSSEC records

https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/ndr/non-delivery-reports-in-exchange-online 
explains what this really means:


The destination domain indicated it was DNSSEC-authentic, but Exchange 
Online wasn't able to verify it as DNSSEC-authentic.


So the guess is that Exchange Online is getting in trouble when there 
are more than a few TLSA records...


• Kirill Miazine via mailop [2024-06-10 12:06]:
Although there are better alternatives to 2 1 1 with Let's Encrypt, some 
still use 2 1 1, and it seems Exchange Online is not happy when there 
are 14 TLSA records (why 14? because 
https://letsencrypt.org/certificates/)... A good reason to not use 2 1 
1


  ; TLSA - LE certs published at https://letsencrypt.org/certificates/
-_le-tlsa   TLSA    2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; LE E1
-   TLSA    2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; LE E2
-   TLSA    2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; LE R3
-   TLSA    2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; LE R4
+_le-tlsa   TLSA    2 1 1 
3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; LE
+   TLSA    2 1 1 
d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7
+   TLSA    2 1 1 
2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba
+   TLSA    2 1 1 
6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7
+   TLSA    2 1 1 
cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75
+   TLSA    2 1 1 
885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5
+   TLSA    2 1 1 
f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
+   TLSA    2 1 1 
919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
+   TLSA    2 1 1 
025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d
+   TLSA    2 1 1 
f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
+   TLSA    2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
+   TLSA    2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
+   TLSA    2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
+   TLSA    2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270

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

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

[mailop] heads-up: Exchange Online: validation issues with Let's Encrypt DANE

[Kirill Miazine via mailop]

Although there are better alternatives to 2 1 1 with Let's Encrypt, some 
still use 2 1 1, and it seems Exchange Online is not happy when there 
are 14 TLSA records (why 14? because 
https://letsencrypt.org/certificates/)... A good reason to not use 2 1 1


 ; TLSA - LE certs published at https://letsencrypt.org/certificates/
-_le-tlsa   TLSA2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; LE E1
-   TLSA2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; LE E2
-   TLSA2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; LE R3
-   TLSA2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; LE R4
+_le-tlsa   TLSA2 1 1 
3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; LE
+   TLSA2 1 1 
d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7
+   TLSA2 1 1 
2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba
+   TLSA2 1 1 
6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7
+   TLSA2 1 1 
cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75
+   TLSA2 1 1 
885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5
+   TLSA2 1 1 
f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
+   TLSA2 1 1 
919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
+   TLSA2 1 1 
025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d
+   TLSA2 1 1 
f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
+   TLSA2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
+   TLSA2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
+   TLSA2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
+   TLSA2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270

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

Re: [mailop] dnsbl.spam.fail

[Kirill Miazine via mailop]

• John Levine via mailop [2023-12-11 22:00]:

It appears that Gellner, Oliver via mailop  said:

And to add a rant to that: I don’t have much sympathy for operators that are 
trying to use their control over a MTA or DNSBL as some
kind of extortion tool or to put forward their own vendettas.


I also block most mail from Hetzner's network. It's not a vendetta,
it's not extortion, it's purely practical. My time is not unlimited,
the vast majority of the mail from that network is spam and if a tiny
bit of real mail gets lost, so be it. It is not worth my time to make
exceptions in my filtering rules.


If you're the only user on the system, then sure, fine -- your mail, 
your choice, but in my case I have "normal" users, and I don't want to 
throw my users' email away, so even OVH can't be blocked, as e.g. Migadu 
is/was using OVH. Of course, an option is making individual exception, 
as Domeneshop does here, but the trigger for the exception is that a 
non-spammer is affected by the block.



If you want people to accept your mail, act like someone who wants
people to do so, and that starts by not sending it from a network
that gushes spam.  Believe me, Hetzner's not the only one.


As a matter of fact I move my mail server to Hetzner only recently, 
until then I was using TransIP for a decade. But also a "test lab" at 
Hetzner, so I decided to just merge everything at Hetzner, as they're 
closer to me geographically, and after considering Hetzner's reputation 
for email: what has been decisive to give it a try is that a number of 
email providers seem to be using them. Initially it was a backup 
dedicated server, there were no issues at all (except one with Fastmail 
responding with 4xx instead of 5xx for a user which no longer existed, 
and reporting re-delivery attempts to senderscore, but that doesn't have 
anything to do with Hetzner).


I am still evaluating Hetzner as email source, though, and have a couple 
of hosts at Mythic Beasts, and have setup ready to let the mail flow 
through them, in case of any issues, but mostly it has been fine-ish.


I'm open for good alternatives in/close to Scandinavia. I had considered 
UpCloud, but comments on the list made me reconsider that option. Also, 
this is a personal setup, so price does indeed matter. :)


But we're getting off-topic, my initial post triggered by discovery of 
the "new" dnsbl.spam.fail list, which I never had experienced earlier, 
and that question has been answered.



R's,
John

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

Re: [mailop] dnsbl.spam.fail

[Kirill Miazine via mailop]

• Gellner, Oliver via mailop [2023-12-11 21:29]:

Even if there are a lot of addresses in that netblock that are sending
spam, Domeneshop now officially knows that at least one IP address does
not (Kirills). It would be trivial to exclude it from their blocking,


Domeneshop shall be given due credit here, as they added an exception 
for my IP very quickly.

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

Re: [mailop] Changes to Validity Reputation Data Through DNS

[Kirill Miazine via mailop]

Hi, Tom

• Tom Bartel via mailop [2023-12-11 17:52]:

Hello Mailops Community,

I wanted to pass along an update regarding coming changes in 2024 to 
public query access for Validity reputation data in DNS.  We're 
finalizing implementation of necessary response codes (including in Spam 
Assassin) to enable this.  It's similar to the Spamhaus DQS changes a 
while ago.  Any questions and/or feedback, LMK.

Is this correct understanding?

- DNS requests will be counted based on IP address of the client doing 
the lookup (which will mean resolver)
- If more then 10K reqs/month is required, user may create account and 
add IP addresses of their resolvers -- this will remove limits (probably 
some limits still apply?)


The question not answered is what happens with the queries when 10K are 
met and if no account is created. Will NXDOMAIN be returned in such cases?




Thanks,

Tom

Dear Mailops Community,

Validity provides free access through DNS to our reputation data, 
including Validity Certified Allowlist and Return Path Blocklist to 
allow for use with email filtering. This is commonly accessed through 
rules available in Apache SpamAssassin.


Starting March 1, 2024we will allow up to 10,000 requests per user over 
a 30-day time period.After 10,000 requests, users must create a 
MyValidityaccount to continue using this free service. At this level of 
usage, we’dsimply like to know who you are – there are no fees or 
purchases required. Upon the creation of a MyValidityaccount, you will 
receive continued access to queries (directly or through SpamAssassin).


Sign up for an account 

If you have any questions, please visit our FAQ here 
.


Best regards,

Validity Data Services


___
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] dnsbl.spam.fail

[Kirill Miazine via mailop]

• Atro Tossavainen via mailop [2023-12-11 09:54]:
> > Inability to do external DNS lookups makes it impossible to monitor
> > for presence on their list.
> 
> https://spam.fail/search?ip=127.0.0.2

Well, yeah, not really _impossible_, but I was referring to doing
monitoring based on DNS lookups, as is normal for DNS BL.

As they aren't providing an API either, I ended up doing doing HTTP GET
check and string matching, along the lines of

curl -s https://spam.fail/search?ip=foo|grep -q 'is not blacklisted'||echo foo 
blacklisted

Also, Domeneshop confirmed they operate spam.fail as internal list and
that they indeed have blacklisted Hetzner ranges because "lack of abuse
handling":


The IP belongs to Hetzner which have a full lack of abuse handling.
A broad range of IP addresses within the block the IP address you are
requesting about s constantly being abused to spam and scam campaigns,
and Hetzner does nothing about it. 


Their MX, their rules...

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

Re: [mailop] dnsbl.spam.fail

[Kirill Miazine via mailop]

• Marco Moock via mailop [2023-12-10 11:24]:

Am 10.12.2023 um 10:55:21 Uhr schrieb Kirill Miazine via mailop:


The block is quite new, I guess spam.fail operators just took
Hetzner's IP ranges and put in their lists


https://spam.fail/search?ip=65.108.153.125

It really seems that the entire /15 IPv4 net is on the blacklist.
You IPv6 is not on the list.


Anyone has any experience with this list or who the operator is?

I suspect it could even be Domeneshop's own list, as it uses their name 
servers. And looking up e.g. 125.153.108.65.dnsbl.spam.fail is not 
possible from anywhere except their own network (I tested from their 
webhosting shell login server).


Inability to do external DNS lookups makes it impossible to monitor for 
presence on their list.



Maybe just ask them to remove your address from that if too many
spammers used that network in the past.


I already did request a manual delisting, which is "a manual process, 
and may therefore take a few days", and also shared my concern with the 
owners, who are competent guys, and hopefully will push forward a 
resolution.


This is ironic, as I've always had a whitelist entry for Domeneshop's 
servers, in case _they_ end up on some blacklist, and then they added me 
to their blacklist.


Checked IP of a friend, who also hosts his personal mail server on 
Hetzner, and he's blacklisted as well.


For now I will configure delivery to use a Mythic Beasts host I have 
around (let's see how this message derlivery flows)... MB seem to have a 
better network reputation.



According to uceprotect, parts of that net were used by spammers
recently:

http://www.uceprotect.net/de/rblcheck.php?asn=24940
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[mailop] dnsbl.spam.fail

[Kirill Miazine via mailop]

Hi, list

Started getting reports of failed deliveries due to listing on some -- 
until now unknown to me -- DNSBL called dnsbl.spam.fail. I have never 
seen it before -- anyone has a clue what this list is about?


It's used by Norwegian provider Domeneshop, and they have quite a big 
share of non-microsoft/google email hosting in Norway, so this listing 
is quite annoying for my users.


The block is quite new, I guess spam.fail operators just took Hetzner's 
IP ranges and put in their lists


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

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

I guess discussing my setup (retry rules, queue lifetime or encryption 
setup) is not strictly on the topic, but I'm commenting it further:


• Slavko via mailop [2023-10-09 09:34]:

Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a):

The reason for a long retry is that I have to manually decrypt 
mailstore partition in case of server reboot. Exim would accept the 
message, but defer delivery until the mount appears. I wanted to have 
some time in case of a reboot and me not being easily available to 
mount the partition.


Consider to spend some time to setup auto decrypt on boot, doing that 
manually has little security enhancement on servers, as once decrypted, 
the content is available to OS and thus to potentional attacker too (the 
only restrictions are access rights).


I've come to current setup as good enough approach to protect data in 
"cloud" and remote dedicated server setups, where I didn't want raw data 
on the provider's block storage or physical disk, and where I equally 
didn't want to have another device at the same provider act as a 
decryption key.


And I don't really type in the passphrase normally, a script does that 
over ssh. But when e.g. offline, I have to type it in manually.


When you store decrypt key on separate disk (eg. USB stick), you are 
safe even after disk replace...


For local setups that's an option, for remote setups where provider is 
offering virtual disks it's certainly an option too, but I didn't want 
them to have the key.

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

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

• Simon Arlott via mailop [2023-10-09 09:12]:

On 09/10/2023 07:44, Kirill Miazine via mailop wrote:

The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I wanted to have some time in
case of a reboot and me not being easily available to mount the partition.


You need to configure different retry times for local domains and then
set delay_warning_condition so that it doesn't send warning emails
unless the origin is local.


I know I could, but current default retry rule has served me so well for 
so many years that I don't add additional logic to deal with theoretical 
edge cases.


However, I am now considering retry rules speecifically for 
in1-smtp.messagingengine.com and in2-smtp.messagingengine.com, and also 
looking at what would be appropriate to as have hosts_max_try and 
hosts_max_try_hardlimit.

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

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Hi, Rob

Thanks for your email and for confirming my theory.

• Robert Mueller via mailop [2023-10-09 08:23]:



I see that current setup might be useful in case some user changes MX
before the domain is activated at Fastmail, in which case giving 4xx
could make sense. But it is not right to report such re-tries to sender
score as attempts to deliver to non-existing users.


Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. 
Many inexperienced email users aren't sure exactly what order to change or set 
things up in and we've seen users lose email before because they changed the MX 
records before adding their domain at Fastmail. The 4xx response reduces the 
chance of lost email.


Exactly what I was thinking, yes.


In general it doesn't really matter that it's 4xx not 5xx. There's no sensible 
reason to point MX records for a domain to us if you're not planning on 
actually using us for your email. If that does happen, the email will 
eventually bounce when the other side gives up trying to resend, which in most 
cases is at most 24 hours.

Now clearly there's an interesting and unexpected edge case that's happened here. The 
logging of repeated delivery to a "non-existent" address has been rolled up 
into a sender score feed that's affected your servers IP reputation, which is really 
annoying.


It is. And if mailing volume would be huge, those retries wouldn't 
matter for the score, but I don't, so, yeah.



Unfortunately fixing the code on this is non-trivial right now since in the 
policy daemon where this logging occurs we don't actually have the information 
we need to suppress this case there and then. I have some longer term ideas for 
this, and will keep this scenario in mind when I get to them.

Sorry Kirill, I don't have a really good answer right now, though I would say that 
"emails would be kept in the queue for a month" is probably actively working 
against you here. There's no reason an email should be queued for that long. 24 hours 
seems a high upper bound these days and is the postfix default. It's better that it 
actually bounce sooner to let the sender know that something went wrong rather than 
trying for a month and the user not knowing that their email is in limbo somewhere.
The reason for a long retry is that I have to manually decrypt mailstore 
partition in case of server reboot. Exim would accept the message, but 
defer delivery until the mount appears. I wanted to have some time in 
case of a reboot and me not being easily available to mount the partition.


I guess I'll have to work with sender score to have them re-set the bad 
score.

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

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Hi, Tom

Thank you so much for reaching out and for providing an email address to 
get in touch with the sender score operators. I'll email them right away!


-- Kirill

• Tom Bartel via mailop [2023-10-08 18:33]:

Kirill,

I'm with Validity.  I can tell you we are intent on producing quality 
scores and if there is erroneous data feeding the model we are happy to 
take a look at it.  In the case of "bad" input, we'd look at issuing 
corrective measures. You can open a ticket at datahelp at validity dot 
com if you'd like to pursue any further.


Thanks,

Tom

On Sun, Oct 8, 2023 at 10:02 AM Kirill Miazine via mailop 
mailto:mailop@mailop.org>> wrote:



• Marco M. via mailop [2023-10-08 14:26]:
 > Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:
 >
 >> Actually the error message "Relay access denied" indicates that
 >> domain is not configured at Fastmail anymore. I just tried and
 >> non-existent users give a different error message:
 >
 > Everybody can set an MX to them, so they must reject that as a
 > permanent error. The current way make it look like somebody is trying
 > unauthorized relaying many times.

I see that current setup might be useful in case some user changes MX
before the domain is activated at Fastmail, in which case giving 4xx
could make sense. But it is not right to report such re-tries to sender
score as attempts to deliver to non-existing users.

I hope Rob & Bron & Co are able to make it right... Now I wonder what
happens with the "sender score" of my mail server, which I've been
operating since early 2000s with tender, love and care.

I find it very unfair that some third party is given an authority to
assign my server some "sender score" based on such false reports. Am I
even able to appeal the score assignment somehow?

 >> 550 5.1.1 : Recipient address rejected: User
 >> unknown in virtual mailbox table
 >
 > That is the right way to deal with that.
 > ___
 > mailop mailing list
 > mailop@mailop.org <mailto:mailop@mailop.org>
 > https://list.mailop.org/listinfo/mailop
<https://list.mailop.org/listinfo/mailop>
___
mailop mailing list
mailop@mailop.org <mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
<https://list.mailop.org/listinfo/mailop>



--
Phone: 303.517.9655
Website: https://bartelphoto.com <https://bartelphoto.com>
Instagram: https://instagram.com/bartel_photo 
<https://instagram.com/bartel_photo>


"Life's most persistent and urgent question is, 'What are you doing for 
others?'" - Martin Luther King Jr.


___
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] fastmail and sender score snafu

[Kirill Miazine via mailop]

• Marco M. via mailop [2023-10-08 14:26]:

Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:


Actually the error message "Relay access denied" indicates that
domain is not configured at Fastmail anymore. I just tried and
non-existent users give a different error message:


Everybody can set an MX to them, so they must reject that as a
permanent error. The current way make it look like somebody is trying
unauthorized relaying many times.


I see that current setup might be useful in case some user changes MX 
before the domain is activated at Fastmail, in which case giving 4xx 
could make sense. But it is not right to report such re-tries to sender 
score as attempts to deliver to non-existing users.


I hope Rob & Bron & Co are able to make it right... Now I wonder what 
happens with the "sender score" of my mail server, which I've been 
operating since early 2000s with tender, love and care.


I find it very unfair that some third party is given an authority to 
assign my server some "sender score" based on such false reports. Am I 
even able to appeal the score assignment somehow?



550 5.1.1 : Recipient address rejected: User
unknown in virtual mailbox table


That is the right way to deal with that.
___
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] fastmail and sender score snafu

[Kirill Miazine via mailop]

Rob (BCC), Bron (BCC), will you please make someone have a look at it? 
The problem is that Fastmail MX respond with 4xx to addresses at domains 
which are not configured at Fastmail AND reports each of those temporary 
rejections as an attempt of delivery to non-existing user. This has made 
my own tiny server get bad "sender score"... Now I don't know how much 
sender score is really used and whether it will be reset at some point.


• Marco M. via mailop [2023-10-08 08:55]:

Am 07.10.2023 um 22:41:01 Uhr schrieb Kirill Miazine via mailop:


Recently I experienced a very "interesting" case which gave my
personal email server "poor" "sender score" due to high rate of
emails sent from my server to non-existent users.


Normal, because spammers often have mass of non-existing (mostly not
anymore) addresses and because these lists are often sold, many
spammers will try it.


I think I figured out what it was. A user sent an email to another
family member, but using contact's old email domain which used to be
hosted by Fastmail, but where no such user would exist anymore (I
don't know if domain still exists as a domain at Fastmail, but
clearly MX point to them).


Actually the error message "Relay access denied" indicates that domain 
is not configured at Fastmail anymore. I just tried and non-existent 
users give a different error message:


550 5.1.1 : Recipient address rejected: User unknown 
in virtual mailbox table



I'd guess a 5xx response would be appropriate -- at least on port 25,
but Fastmail sent 451, and made my Exim try -- and keep re-trying --
all IP addresses of all their MX. I have very conservative retry
rules, so emails would be kept in the queue for a month...


That is fastmails bad configuration. Permanent errors like "mailbox
doesn't exist" must have a permanent error code (5xx) to avoid retry.


Senders to Fastmail beware, and maybe consider treating their 4xx
errors as permanent.


Fastmail must fix that - every MTA will try it again and again if a 4xx
error occurs and that will flood them with the messages many times.


And senders given bad sender score eventually, and especially low-volume 
servers.

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

[mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Hi, mailops

Recently I experienced a very "interesting" case which gave my personal 
email server "poor" "sender score" due to high rate of emails sent from 
my server to non-existent users.


It _couldn't_ be right, as the server is used only by myself and some 
very few family members, and there is no activity which should have 
triggered that score.


I think I figured out what it was. A user sent an email to another 
family member, but using contact's old email domain which used to be 
hosted by Fastmail, but where no such user would exist anymore (I don't 
know if domain still exists as a domain at Fastmail, but clearly MX 
point to them).


I'd guess a 5xx response would be appropriate -- at least on port 25, 
but Fastmail sent 451, and made my Exim try -- and keep re-trying -- all 
IP addresses of all their MX. I have very conservative retry rules, so 
emails would be kept in the queue for a month...


I _guess_ that Fastmail is using sender score, because sender score 
graphs started at the date of that one particular email was sent. So 
every try must have been giving me "bad" score.


And I wouldn't even have discovered that if not OpenSMTPD misc@ lits 
rejected my email, and today would accept it, but add a sender-score 
header, which made me start digging...


Senders to Fastmail beware, and maybe consider treating their 4xx errors 
as permanent.


Logs below:

Oct  7 08:45:03 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.220]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied


Oct  7 08:45:06 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.218]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied


Oct  7 08:45:08 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.216]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied


Oct  7 08:45:10 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.219]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied


Oct  7 08:45:13 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.217]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied


Oct  7 08:45:16 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in2-smtp.messagingengine.com [64.147.123.52]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied

___
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

[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
<https://postmaster.t-online.de/index.en.html#t4.1>.


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

[Kirill Miazine via mailop]

• Kai 'wusel' Siering via mailop [2022-10-20 00:44]:
[...]
> > In the German Net Neutrality report 2020/2021, published by
> > Bundesnetzagentur, section 24, they say:
> > 
> >  In several cases end-users could not receive incoming emails. They
> >  believed that internet access providers were blocking emails of certain
> >  email providers. The blocking, however, was carried out by involved
> >  email service providers. For this reason the net neutrality Regulation
> >  did not apply.
> > 
> > In the t-online case the blocking is carried out by the ISP.
> 
> Nice find. But:
> 
[...]
> 
> As such: the MXes are run by »Deutsche Telekom Technik GmbH«, their IP
> space is routed by »Deutsche Telekom AG, Internet service provider«.
> Therefore it's not a net neutrality issue: There is a distinction
> between the mail service and the routing service.
> 
> Even if not: AFAICS net neutrality only applies to the transport
> level. So if the GmbH or the AG would configure their routers to drop
> 25% of packets to my ASN (or if I'd do similar stuff), that would be
> an issue of net neutrality.

I wouldn't argue very hard on this one, as I do agree that net
neutrality primarily applies on the transport level. However, I don't
think it's too far fetched to consider application of net neutrality
when an email service is provided by an ISP as a service to the ISP
subscribers, even if the email service itself technically is provided by
an entity different from the ISP, maybe being based on some kind of
contractual arrangement between AG and GmbH.

IIRC there are some situations where carrier specific rules apply to
higher level services/applications provided by an ISP, but not to
non-ISPs providing similar services.

> -kai

-- 
-- Kirill Miazine 
___
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

[Kirill Miazine via mailop]

• Bernardo Reino via mailop [2022-10-19 20:24]:
> On Wed, 19 Oct 2022, Kirill Miazine via mailop wrote:
> 
> > • Bernardo Reino via mailop [2022-10-19 14:51]:
> > > On 2022-10-19 14:25, Stefano Bagnara via mailop wrote:
> > > > On Wed, 19 Oct 2022 at 13:32, Heiko Schlittermann via mailop
> > > >  wrote:
> > > > > A given mailhost (ran privately for smaller entities) can't send
> > > > > messages to T-Online anymore.
> > > > > 
> > > > >   554 IP=168.119.159.241 - A problem occurred. …
> > > > 
> > > > Do you get this error at the connection or after you transmitted the
> > > > message?
> > > 
> > > It happens while connecting, so it's blocking on the IP address.
> > > 
> > > Even though I'm a tiny "provider" (4 users :), I've sent an e-mail to
> > > postmas...@rx.t-online.de (note the "rx", which you need if you are being
> > > blocked from contacting the usual postmas...@t-online.de address), to let
> > > them know that their users will be missing a lot of e-mails (Germany is
> > > quite "diverse" ISP-wise).
> > > 
> > > Maybe they'll reconsider (not because of my e-mail, but because of the 
> > > flood
> > > of complaints that should be — surely? — arriving :).
> > 
> > I've sent t...@rx.t-online.de an email and asked to clarify why my fullu
> > compliant mail server on TransIP network is being blocked and what kind
> > of problem has occured.
> > 
> > > We'll see..
> > 
> > We'll see... I'd say this is a net neutrality issue. Have Germany
> > adopted some rules on net neutrality?
> 
> TBH I don't think this has anything to do with net neutrality, but the term
> is (ab)used for many purposes and sometimes even with opposite meanings.

I'm not sure, as Deutsche Telekom -- as an ISP -- has apparently adopted
the policy that only commercial email servers are able to connect to
deliver email to Deutsche Telekom's email service. When t-online.de
sender is not able to receive a reply due to this policy, isn't it
exactly a net neutrality issue?

In the German Net Neutrality report 2020/2021, published by
Bundesnetzagentur, section 24, they say:

In several cases end-users could not receive incoming emails. They
believed that internet access providers were blocking emails of certain
email providers. The blocking, however, was carried out by involved
email service providers. For this reason the net neutrality Regulation
did not apply.

In the t-online case the blocking is carried out by the ISP.

If I were German, I'd file a complaint and see what Bundesnetzagentur
says. Actually I'll see what t-online answers, and if they ask me about
Impressum, I'll forward it to Bundesnetzagentur and ask them to kindly
impose measures on t-online.

> I think this is just Deutsche Telekom going Microsoft. But instead of
> rejecting (or silently dropping after accepting) after DATA they block the
> connection itself (so at least you know what hit you and when..)
> 
> To me it's a case of "their server, their rules" but also a clear case of
> "shooting yourself in the foot" or if my German doesn't fail me now "sich
> ins Knie schießen".
> 
> They'll learn..
> Bernardo

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


-- 
-- Kirill Miazine 
___
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

[Kirill Miazine via mailop]

• Bernardo Reino via mailop [2022-10-19 14:51]:
> On 2022-10-19 14:25, Stefano Bagnara via mailop wrote:
> > On Wed, 19 Oct 2022 at 13:32, Heiko Schlittermann via mailop
> >  wrote:
> > > A given mailhost (ran privately for smaller entities) can't send
> > > messages to T-Online anymore.
> > > 
> > >   554 IP=168.119.159.241 - A problem occurred. …
> > 
> > Do you get this error at the connection or after you transmitted the
> > message?
> 
> It happens while connecting, so it's blocking on the IP address.
> 
> Even though I'm a tiny "provider" (4 users :), I've sent an e-mail to
> postmas...@rx.t-online.de (note the "rx", which you need if you are being
> blocked from contacting the usual postmas...@t-online.de address), to let
> them know that their users will be missing a lot of e-mails (Germany is
> quite "diverse" ISP-wise).
> 
> Maybe they'll reconsider (not because of my e-mail, but because of the flood
> of complaints that should be — surely? — arriving :).

I've sent t...@rx.t-online.de an email and asked to clarify why my fullu
compliant mail server on TransIP network is being blocked and what kind
of problem has occured.

> We'll see..

We'll see... I'd say this is a net neutrality issue. Have Germany
adopted some rules on net neutrality?

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

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