Re: [mailop] IP RBLs and large cidr blocks

[Michael Grant via mailop]

I've resolved this now.

Thanks to Matthew Stith for pointing out that Spamhaus's largest ipv6
blocks are indeed /64 and not /32.

Oddly, today I plainly see the spamhaus listing the /64 and not the
/32 I saw yesterday.  Did something change???  I am pretty sure I
wasn't imagining things and pretty sure I copypasted that
2600:3c02::/32 from the 'Why was this IP listed?' section.  Ahh well.

What I did:

My linodes have a /128 address (within a shared /64) and a separate
/64 block.  The /128 clearly has bad network neighbors and there's
nothing I can do about that.  I spent the day changing the ipv6 on
these linodes to first addr in the separate /64 block.  That block on
all my servers is clean, not in any blacklists.

I did ask Linode if they'd do rwhois on my /64 blocks but said they
don't do that at this time but said I was not the only one who had
asked for that and they said they added my request to their internal
feature request.  So maybe one day...

Thanks also to Grant Taylor who provided some insite and some
encouragement to persiste in getting this working.

I absolutely understand there's some unpredictability here delivering
mail over ipv6 but the future is now, ipv6 isn't going away.  I fully
realize there are probably no ipv6 only domains out there at this
time.

I have seen different levels of filtering and strictness even between
different MXs within the same domain on ipv4, so honestly to say I
shouldn't do this because there's there might be differences between
ipv4 and ipv6 MXs is frankly no worse than what we already are seeing.
If I see something so broken, I am known for letting someone know.

Michael Grant




signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Continuous DMARC temperrors with Microsoft

[Tim Starr via mailop]

I see those, too. I assumed it was due to temporary DNS lookup failures.

-Tim

On Fri, Mar 10, 2023 at 10:19 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

> Hello,
>
> we repeatedly receive DMARC reports from dmarcrep...@microsoft.com with
> allegedly failed DKIM checks. The result is always "temperror". This
> happens daily for all kind of domains, also under different top level
> domains.
> Noone else is reporting temperrors on such a regular level and also at
> Microsoft most messages (from the very same domains on the same day) pass
> the DKIM check, so it's not like the DNS entries were broken. The numbers
> of failed messages are not huge, but they happen frequently. Does anyone
> see such behaviour in their DMARC reports from Microsoft as well?
>
>
> Examples:
>   
> 
>   195.2.200.153
>   17
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   shop.dm-drogeriemarkt.ba
>   shop.dm-drogeriemarkt.ba
> 
> 
>   
> shop.dm-drogeriemarkt.ba
> acl20211215
> temperror
>   
>   
> shop.dm-drogeriemarkt.ba
> mfrom
> pass
>   
> 
>   
> --
>   
> 
>   136.243.101.209
>   9
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   rp.news.dm.de
>   news.dm.de
> 
> 
>   
> news.dm.de
> elaine
> temperror
>   
>   
> rp.news.dm.de
> mfrom
> pass
>   
> 
>   
> --
>   
> 
>   213.128.132.138
>   6
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   unserdm.at
>   unserdm.at
> 
> 
>   
> unserdm.at
> keyingress
> temperror
>   
>   
> unserdm.at
> mfrom
> pass
>   
> 
>   
>
>
> --
> 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<
> 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

[mailop] Continuous DMARC temperrors with Microsoft

[Gellner, Oliver via mailop]

Hello,

we repeatedly receive DMARC reports from dmarcrep...@microsoft.com with 
allegedly failed DKIM checks. The result is always "temperror". This happens 
daily for all kind of domains, also under different top level domains.
Noone else is reporting temperrors on such a regular level and also at 
Microsoft most messages (from the very same domains on the same day) pass the 
DKIM check, so it's not like the DNS entries were broken. The numbers of failed 
messages are not huge, but they happen frequently. Does anyone see such 
behaviour in their DMARC reports from Microsoft as well?


Examples:
  

  195.2.200.153
  17
  
none
fail
pass
  


  hotmail.com
  shop.dm-drogeriemarkt.ba
  shop.dm-drogeriemarkt.ba


  
shop.dm-drogeriemarkt.ba
acl20211215
temperror
  
  
shop.dm-drogeriemarkt.ba
mfrom
pass
  

  
--
  

  136.243.101.209
  9
  
none
fail
pass
  


  hotmail.com
  rp.news.dm.de
  news.dm.de


  
news.dm.de
elaine
temperror
  
  
rp.news.dm.de
mfrom
pass
  

  
--
  

  213.128.132.138
  6
  
none
fail
pass
  


  hotmail.com
  unserdm.at
  unserdm.at


  
unserdm.at
keyingress
temperror
  
  
unserdm.at
mfrom
pass
  

  


--
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] Mail Sending Self-Test Platform

[Taavi Eomäe via mailop]

On 03/03/2023 19:19, David Conrad via mailop wrote:
This kind of comment isn’t particularly useful as it appears to be a 
statement of an opinion with no explanation/justification.


DNSSEC is a different PKI. Like everything, it has pros and cons. 
Whether it is better or worse depends on what you’re looking at.


If you believe MTA-STS is superior, explaining why (ideally with data) 
would be useful.


To be totally fair the initial claim wasn't strongly backed either and 
it was late.


The general gist of it is indeed actually that DNSSEC is a different 
PKI, but it's still a PKI. There were been large problems with WebPKI 
that have now been remedied. The most recent being the rollout of 
Certificate Transparency. One can't say the same about DNSSEC's 
transparency.


Going back to the original statement that DANE is superior (or should 
supersede) MTA-STS, well, then DNSSEC should be a better PKI than WebPKI 
is. That is objectively not the case right now.


That is not to say MTA-STS is the absolute best and flawless, but it 
does currently offer more and come with fewer downsides than DANE would. 
This doesn't however mean there's no value in DNSSEC or DANE - here at 
Zone  we have adopted and implemented (for our 
customers) all three (DNSSEC, DANE and MTA-STS).


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

Re: [mailop] Sometimes I hate Microsoft :)

[Tobias Fiebig via mailop]

heho,
i actually occasionally get NDRs from them; One of them actually broke
parsing for my funny mail measurement setup recently, because it was
way in excess of 100kb... and i thought 640kb should be enough for
everyone^Wmail. -.-'

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Sometimes I hate Microsoft :)

[Support 3Hound via mailop]

About 15 years ago they was sending NDR for each non existing user, 
including very old abandoned mailbox called "soft spamtrap", and also 
for something like "unsubscribe from this list" or "block this sender".
I was managing a mailing platform and we was forcing unsubscribing for 
all permanent NDR, because...  it is the right thing to do (even if our 
customers was complaining for that).


After some month, this practice become a sort of "vademecum" to get into 
the inbox for every mailer (also bad players), so... even poor collected 
database and spammer was applying the same policy in order to "clean" 
databases.
For what I observed, during years, Microsoft heavily limited the amount 
of NDR and JMRP feedback to avoid bad usage of that.
As always, these straighten of rules bring bad news for the whole 
market, even correct players got worse reputation, starting to contain 
and not unsubscribing disabled mailbox, complainer and so on...


So, today we see NDRs not coming back and it may seem to be just a "non 
compliance" and "nonsense" behavior but there are years of abuse from 
bad players that bring them to these decision.


I personally dislike that, I think that other players acting bad 
practice shouldn't bring myself to do other bad practice to contrast it, 
but that's philosophy... they have tons of mailserver and users to preserve.




Il 10/03/2023 08:42, Renaud Allard via mailop ha scritto:



On 3/9/23 16:25, Eduardo Diaz Comellas via mailop wrote:

Hi,

Sorry for the rant, but I need to get this off my chest. Microsoft's 
MXs are accepting emails from one of my customers but then not 
delivering them to the recipient inboxes...


Why can't they decide *before* accepting the email, like any sensible 
citizen?


At least, they should send NDRs... :(



They don't seem to care about NDR. I have recently sent a mail from 
O365 to one of my personal accounts outside O365, and it was refused 
(with 5XX error) because some MS servers were on a blacklist. And I 
never got the NDR on my O365 account, so it seems they don't even send 
the NDR anymore to (at least some of) their own users either.



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