Re: [mailop] Sometimes I hate Microsoft :)

[Renaud Allard via mailop]

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.




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

[Evan Burke via mailop]

If you want to be pragmatic about this, you should be looking closely at
your customer's sending practices and metrics.

On Thu, Mar 9, 2023 at 7:50 AM Eduardo Diaz Comellas via mailop <
mailop@mailop.org> 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... :(
>
> Best regards
>
> --
> Eduardo Díaz Comellasñ
> Ultreia Comunicaciones, S.L.
>
> ___
> 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] IP RBLs and large cidr blocks

[Tobias Fiebig via mailop]

> 
Heho,

> > I mentioned to Michael -- in a direct email -- that I wonder if
> > there is an opportunity to put something in parent DNS zones in the
> > .arpa sub-domains, much like DS records for DNSSEC go in parent
> > zones, so that an IP provider (or at least naming authority) can
> > specify that a range is delegated to another entity.
> 
> Usually this is ONLY done for a /24 or greater by upstream
> providers.. (While it can get done for smaller blocks, you end up
> with that ugly double PTR record, one from the provider and one from
> your DNS server)
_This_ is what the IRR system/'rwhois' is for, no? I usually put
objects for v4 i delegate into IRR, same for v6; I recall that hetzner
also does (used to do?) this for delegated networks in their dedicated
server product. At least the RIPEDB comes with an API.

ARIN even says explicitly that ISPs only have 7(!) days to submit
reassignments of v4/29 v6/56 or shorter to the database.

> > I also mentioned that miscreants would be likely to abuse this and 
> > artificially divide their IP space so that bans on some parts would
> > not effect other parts.  Hence the need to have a larger addressing
> > /naming authority provide this.
Yeah, like, the LIRs? (Granted, the bar to become a LIR in RIPE is not
that high (and an LLC not that much more difficult to get for the other
RIRs; But you can technically nuke bad-faith LIRs from orb... er
ASPATH).


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

Re: [mailop] IP RBLs and large cidr blocks

[Grant Taylor via mailop]

On 3/9/23 12:45 PM, Michael Peddemors via mailop wrote:
Okay, better expand on what I am saying.. say you have a bunch of IPs 
from Linode, .. you 'might' want to indicate better what they are for..


eg..

sharedhosting.hisdomain.com
mailout.hisdomain.com

etc..

If the PTR's still reflect the generic

li1072-208.members.linode.com

He probably won't get them removed from an RBL..


I guess there are people that don't configure reverse DNS on their 
Linode (et al.) IP addresses.  But I can't fathom doing that for 
anything even remotely production unless "linode.com" was in my 
employer's name.



Usually this is ONLY done for a /24 or greater by upstream providers.


Ah.  So maybe it's more they "won't" support it than "can't" support it.

(While it can get done for smaller blocks, you end up with that ugly 
double PTR record, one from the provider and one from your DNS server)


Please elaborate on what you mean by "ugly double PTR record".  RFC 2317 
Classless IN-ADDR.ARPA delegation comes to mind and I bet that's not 
what you're referring to.


Yes, we see that.. it does occur.. but pretty obvious usually.  Take a 
look at the OVH guys with fake ownership.. but it can be used to help 
positively identify good operators, and that value is important as well.


ACK


Strange, wish Linode would pipe up on this on list..


Ya.  I wish that more providers would be active on industry mailing lists.

Thankfully I find that I can get some engagement on Twitter.  But sadly, 
often the people that respond aren't able to do much.  Though 
occasionally they do manage to unwedge things.


Some segments are REALLY bad, and other segments never generate a 
complaint.. They must be differentiating internally some of their 
customer signups..


I wonder how much of it has to do with age of the segments and / or VPSs 
therein.



If the hosting provider doesn't provide 'rwhois', speak with your feet.


Given their recent announcement of 20% rate increase on a lot of 
products / services, I'm probably going to be re-evaluating things.


Even GoDaddy offers it, and as much talk about bad GoDaddy, a person 
with a correct 'rwhois' can usually get off an RBL a LOT quicker.


ACK



--
Grant. . . .
unix || die



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

Re: [mailop] IP RBLs and large cidr blocks

[Grant Taylor via mailop]

On 3/9/23 2:03 PM, Gellner, Oliver via mailop wrote:
Also some MTA may use different or stricter checks for IPv6 than for 
IPv4, so it‘s possible that a message gets rejected while it would have 
been accepted if delivered via IPv4.


I believe Google has more stringent requirements for IPv6 than they do 
for IPv4.


Admittedly they are for things that are SHOULD be the case in IPv4. 
Google just chose to make them MUST in IPv6.




--
Grant. . . .
unix || die



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

Re: [mailop] IP RBLs and large cidr blocks

[Gellner, Oliver via mailop]

On 09.03.2023 at 18:51 Michael Grant via mailop wrote:

If I can get this spamhaus issue solved, why should I not just leave
it in place so my mailer will talk ipv4 or ipv6?  Why just stick with
ipv4?  I realize it's not necessary today to be able to send on ipv6
but why should I not get this working?

Well, after enabling IPv6 you have to watch RBLs not only for your IPv4 
addresses but also for IPv6, make sure that both have FCRDNS which match and 
deal with other MTAs that have IPv6 addresses, yet don‘t fully support IPv6. 
Also some MTA may use different or stricter checks for IPv6 than for IPv4, so 
it‘s possible that a message gets rejected while it would have been accepted if 
delivered via IPv4.

In the end all of that can be solved, but it‘s additional work and if you‘re 
not doing this for fun or because your personally interested in it, then it‘s a 
question of what return you get for your efforts.

—
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] IP RBLs and large cidr blocks

[Matthew Stith via mailop]

Michael,

Feel free to hit me up off list.

Also one statement for the group, Spamhaus only lists IPv6 space in /64s 
with the XBL and CSS lists. There may be larger ones in the SBL DROP or 
EDROP lists but those are indicative of hijacked space and wouldn't 
belong to a legit hosting company.


On 3/9/2023 7:50 AM, Michael Grant via mailop wrote:

Is there some way an ISP can tell an RBL how it's split up it's
internal IP address space?  For example, our Linode's ipv6 address is
on the Spamhaus XBL, but it's the entire /28.  (Thanks Tobias for
prompting me to check this!)

Anyway, it got me wondering, is there some way an ISP such as Linode
can communicate to Spamhaus how it carves up it's large swatches of
addresses?  Or does this somehow happen automatically over time as I
as a customer delist my single /128 address in their database?

In the case of Spamhaus, I tried to delist my address and the delist
page says I need to make sure the problem in 2600:3c02::/32 has been
resolved.

When I do a whois lookup on my ipv6 addr, Linode is responsible for
the entire /28 yet Spamhaus seems already to have split that up down
to the /32 level, yet really it probably should be split down to the
/64 and in some cases /56 level.

I was curious, does this happen and how?  Is there some internet
database that keeps track of how smaller swatches of the address space
are actually carved up?  Smaller than what whois reports.

To be clear, I'm talking about how the address space is split up, NOT
the actual customer like whois reports.

Barring that, is there some way to tell Spamhaus how the address space
is carved up so I can communicate that to Linode?  I looked but didn't
see anything obvious.

Michael Grant

___
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] Mailing Lists and domains with DMARC reject

[John R Levine via mailop]

Would a MUA send a POST to a known domain if it was found on a message 
coming from an unknown, or anyway different domain?


Maybe.  It's quite common for a message to come from some company and the 
links to point back to the ESP.


Isn't it difficult to agree on opaque tokens in that case?


No.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Thu 09/Mar/2023 19:21:36 +0100 John R Levine via mailop wrote:
Yes, the idea was to prevent malicious unsubs by sending fake spam with 
someone else's one-click unsub.


Would a MUA send a POST to a known domain if it was found on a message coming 
from an unknown, or anyway different domain?


Maybe.  It's quite common for a message to come from some company and the links 
to point back to the ESP.



Isn't it difficult to agree on opaque tokens in that case?


Best
Ale
--





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

Re: [mailop] IP RBLs and large cidr blocks

[Michael Peddemors via mailop]

On 2023-03-09 10:33, Grant Taylor via mailop wrote:

On 3/9/23 9:45 AM, Michael Peddemors via mailop wrote:





AS well, you 'could' change default PTR's for segments used differently.


I find the idea of requiring PTRs to contain a magic string to be 
unappetizing at best and appalling at worst.


IMHO *NOBODY*, and I mean absolutely /nobody/ gets to tell me what I 
name my own system.  That extends to things that tie into the host name, 
e.g. rDNS PTR records.


This would also be predicated on there being a single string that the 
entire industry would accept.  I find this to be extremely unlikely.


Okay, better expand on what I am saying.. say you have a bunch of IPs 
from Linode, .. you 'might' want to indicate better what they are for..


eg..

sharedhosting.hisdomain.com
mailout.hisdomain.com

etc..

If the PTR's still reflect the generic

li1072-208.members.linode.com

He probably won't get them removed from an RBL..



At least you are asking how you can do things differently.


I mentioned to Michael -- in a direct email -- that I wonder if there is 
an opportunity to put something in parent DNS zones in the .arpa 
sub-domains, much like DS records for DNSSEC go in parent zones, so that 
an IP provider (or at least naming authority) can specify that a range 
is delegated to another entity.


Usually this is ONLY done for a /24 or greater by upstream providers..
(While it can get done for smaller blocks, you end up with that ugly 
double PTR record, one from the provider and one from your DNS server)




I also mentioned that miscreants would be likely to abuse this and 
artificially divide their IP space so that bans on some parts would not 
effect other parts.  Hence the need to have a larger addressing / naming 
authority provide this.


Yes, we see that.. it does occur.. but pretty obvious usually.  Take a 
look at the OVH guys with fake ownership.. but it can be used to help 
positively identify good operators, and that value is important as well.




I think the distributed nature of rDNS could work well for this /if/ 
there was an agreed upon way to signal this /and/ we could get 
addressing / naming authorities to support it.


I know there has been a lot of Linode 'slagging' on the list, but it 
isn't as bad as some other networks.


I'm using Linode and still having reasonable luck.  Though I do see 
evidence that the neighborhood is running down in some places.


Strange, wish Linode would pipe up on this on list..

Some segments are REALLY bad, and other segments never generate a 
complaint.. They must be differentiating internally some of their 
customer signups..



As a customer, ask Linode to provide 'rwhois' for you.


I have done exactly that multiple times.  Each and every time they say 
that they don't support it.




If the hosting provider doesn't provide 'rwhois', speak with your feet.
Even GoDaddy offers it, and as much talk about bad GoDaddy, a person 
with a correct 'rwhois' can usually get off an RBL a LOT quicker.



--
"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] IP RBLs and large cidr blocks

[Grant Taylor via mailop]

On 3/9/23 10:45 AM, Michael Grant via mailop wrote:
If I can get this spamhaus issue solved, why should I not just leave 
it in place so my mailer will talk ipv4 or ipv6?  Why just stick 
with ipv4?  I realize it's not necessary today to be able to send on 
ipv6 but why should I not get this working?


You are opening yourself up to /some/ issues related to the preference 
of IPv6 over IPv4.


I've had a few receiving domains that I needed to break IPv6 for email.

I've seen a LOT of ... data ... noise ... information ... something 
about people strongly preferring IPv4 over IPv6 for email if not 
outright actively discouraging IPv6 for email.


It's a proverbial Your Mileage May Vary.

Just be mindful that you may run into some unexpected things, like your 
IPv6 address being on an RBL that your IPv4 address is not.  And the 
complications related thereto, like your MTA preferring IPv6 over IPv4 
to the destination checking said RBLs.




--
Grant. . . .
unix || die



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

Re: [mailop] IP RBLs and large cidr blocks

[Grant Taylor via mailop]

On 3/9/23 9:45 AM, Michael Peddemors via mailop wrote:
Yes, it's called 'rwhois'.  Of course, linode can SWIP the larger 
portions, with a clear indication of what parts of the IP space are used 
for what.


I've opened multiple support tickets with Linode over the years asking 
for SWIP and / or RWHOIS and they have always responded that they do not 
support that.


Do you have evidence to the contrary showing that they do support SWIP 
and / or RWHOIS?



AS well, you 'could' change default PTR's for segments used differently.


I find the idea of requiring PTRs to contain a magic string to be 
unappetizing at best and appalling at worst.


IMHO *NOBODY*, and I mean absolutely /nobody/ gets to tell me what I 
name my own system.  That extends to things that tie into the host name, 
e.g. rDNS PTR records.


This would also be predicated on there being a single string that the 
entire industry would accept.  I find this to be extremely unlikely.



At least you are asking how you can do things differently.


I mentioned to Michael -- in a direct email -- that I wonder if there is 
an opportunity to put something in parent DNS zones in the .arpa 
sub-domains, much like DS records for DNSSEC go in parent zones, so that 
an IP provider (or at least naming authority) can specify that a range 
is delegated to another entity.


I also mentioned that miscreants would be likely to abuse this and 
artificially divide their IP space so that bans on some parts would not 
effect other parts.  Hence the need to have a larger addressing / naming 
authority provide this.


I think the distributed nature of rDNS could work well for this /if/ 
there was an agreed upon way to signal this /and/ we could get 
addressing / naming authorities to support it.


I know there has been a lot of Linode 'slagging' on the list, but it 
isn't as bad as some other networks.


I'm using Linode and still having reasonable luck.  Though I do see 
evidence that the neighborhood is running down in some places.


Now, having said that that, you are looking  at the IPv6 space.  Are you 
planning to run email on IPv6? Many challenges ahead.


I am and have been running a dual stack email server for many years. 
I've only got a few recipient domains that I've artificially broken IPv6 on.



As a customer, ask Linode to provide 'rwhois' for you.


I have done exactly that multiple times.  Each and every time they say 
that they don't support it.



But for email, you should stick to IPv4.  Just my two bits.


I apparenlty have different two bits.



--
Grant. . . .
unix || die



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

Re: [mailop] Mailing Lists and domains with DMARC reject

[John R Levine via mailop]

Yes, the idea was to prevent malicious unsubs by sending fake spam with 
someone else's one-click unsub.


Would a MUA send a POST to a known domain if it was found on a message coming 
from an unknown, or anyway different domain?


Maybe.  It's quite common for a message to come from some company and the 
links to point back to the ESP.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IP RBLs and large cidr blocks

[Michael Grant via mailop]

On Thu, Mar 09, 2023 at 08:45:58AM -0800, Michael Peddemors via mailop wrote:
> Yes, it's called 'rwhois'.  Of course, linode can SWIP the larger portions,
> with a clear indication of what parts of the IP space are used for what.
> 
> AS well, you 'could' change default PTR's for segments used differently.
> 
> At least you are asking how you can do things differently.
> 
> I know there has been a lot of Linode 'slagging' on the list, but it isn't
> as bad as some other networks.
> 
> Now, having said that that, you are looking  at the IPv6 space.  Are you
> planning to run email on IPv6? Many challenges ahead.
> 
> As a customer, ask Linode to provide 'rwhois' for you.  But for email, you
> should stick to IPv4.  Just my two bits.

I literally only tried enabling mail on my server the other day after
running Tobias Fiebig's security scan test.  I failed the ipv6 test so
thought, well, let's enable that in sendmail and see if I can make
that box green...what could possibly go wrong?

Quite quickly we realized the ipv6 address of the box was on
spamhaus's XBL.

By 'rwhois', I think you mean running whois with an ip address versus
a hostname.  This is exactly how I use it to know who owns which
netblock.  That's how I can see Linode owns the /28.

When you say "ask Linode to provide 'rwhois'", what specifically do
you mean for them to do?  Once that's done (if they're willing to do
this for me), would spamhaus and other RBLs then know to list smaller
blocks in that space?

If I can get this spamhaus issue solved, why should I not just leave
it in place so my mailer will talk ipv4 or ipv6?  Why just stick with
ipv4?  I realize it's not necessary today to be able to send on ipv6
but why should I not get this working?


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

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Wed 08/Mar/2023 18:39:37 +0100 John R Levine via mailop wrote:


And why does RFC8058 require that fields such as List-Unsubscribe-Post: 
MUST be signed?


Is it special "One click" case? I was not interested in it yet...


Yes, the idea was to prevent malicious unsubs by sending fake spam with someone 
else's one-click unsub.



Would a MUA send a POST to a known domain if it was found on a message coming 
from an unknown, or anyway different domain?


It may be that in the tradeoff between resilience and security the latter wins. 
 In that case shouldn't RFC8058 have modified Section 5.4.1 of RFC6376, 
Recommended Signature Content?


Should software that defines the default fields to sign after that section add 
List-Unsubscribe-Post to that list?



Best
Ale
--






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

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Wed 08/Mar/2023 22:27:57 +0100 Ángel via mailop wrote:

On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:

On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:


Why do you sign Content-Type: since you know it is going to be 
changed?


Do you mean exactly me, or it was generic question? If you mean me:

Do you want change the text/plain message, eg. to multipart/alternative 
with text/html appended? Of course, in my case that change will invalidate 
body signature too (as i sign whole body), but anyway, it constructs core 
of message, thus (IMO) fulfill RFC.


Yes, I meant you, since you (are among the ones who) do it.

The change to multipart can only happen using the deprecated l=.  It allows to 
completely replace the body appearance.  As you don't use l=, the only added 
protection is against an improbable collision between the original bh= and the 
hash of the modified body.


There are more ways to change a Content-type for abuse.

Suppose there is a web form that is expected to send a plain text message 
saying:

"Hello Alessandro

Thanks for registering on example.com, please click the following link to validate 
your account: https://example.com/register...";


These kind of forms are already abused by using "names" such as "buy our viagra 
at great price on http://spamurl.com";



URLs don't depend on Content-Type:, do they?


The "I received a scam letter from Paypal" thread a few months ago is also based 
on the same concept.



That turned out to be authentic, IIRC.


Now, let's suppose that email is DKIM-signed but the Content-type: text/plain header 
is not. And the form is filled out by «Bobby * { color: white; background-color: 
white; } .phish * { color: black}Important notification from your bank 
Your password has expired. Please https://phishing.com";>Renew it here»


and attacker changes the Content-type from text/plain to text/html...



Is that content going to replace «Alessandro» in the plain/text message from 
the generated message?  The culprit seems to be rather the input sanitizing 
than the signing.




Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)



That requires the original text to already contain the exploit.  Perhaps the 
plain text message was exemplifying it?




Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.



I agree that some kind of transactional messages can bear paranoid signatures. 
They also deserve p=reject.


Ordinary messages, which can expect to be forwarded or slightly modified could 
keep a lower profile, couldn't they?


I understand that the only advantage of signing lightly is for the very few 
people who can recover that kind of signatures after MLM transformation, so it 
seems to be a lost argument...




1-
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings



I hope Javascript in email messages does not run...


Best
Ale
--





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