Re: [mailop] Musings on Mail Service Operators

[Dave Crocker via mailop]

On 2/2/2022 7:31 PM, Scott Mutter via mailop wrote:
Why is it impossible to take a look at what Instant Messaging protocols, 
SMTP, SMS do that make them successful and then blend those together 
into a new "email-like" system?


Because replacing widespread systems is vastly harder than one would intuit.

Staying with email as the focus, there was early desire to expand from 
simple text to support multimedia.  And there were multiple efforts, 
from the latter 1970s onward.


What succeeded was not replacing existing email but rather adding to it, 
with an optional layer -- MIME.



I'm not going to pretend to know what the ultimate solution might be.  
One of the major issues with email is the address spoofing that goes 
on. 


It is popular to think that this can be solved, but the reality has so 
far demonstrated that what cannot be solved in the real (wet) world 
cannot be solved on the Internet.  And spoofing, or the like, is part of 
that wet world, as well as the digital one.


The schemes people propose to 'fix' spoofing wind up working less well 
than hoped, such as by not scaling adequately, or by having collateral 
downsides.



     Would more 
need to be done to lock this down?  Absolutely.  But it's at least A 


Locking down tightly has downsides, as well as benefits.



Email was first invented in 1971 - that's over 50 years ago.  We've 


This being a list for technicians, forgive me for noting that Ray 
Tomlinson did NOT invent email in 1971.


Email dates back at least to the mid-1960s.  Tom van Vleck is the most 
likely candidate for bragging rights.


What Ray did was to creat /networked/ email.  And, of course, choose the 
at-sign as the mailbox@host syntax.




   Why not invent a new, more modern email alternative?  


One of the wonders of the Internet is that you are free to go do that. 
Create it.  Deploy it.  Develop support for it.  If you can.



Something that takes a lot of what we've learned from email usage over 
the years, what we've seen in instant messaging, SMS, and other computer 
communication protocols and builds on that from the ground up?  Wouldn't 
that be better than constantly adding band-aids to email/SMTP to fix 
problems that pop up?


Possibly, but also apparently not.  It is spectacularly difficult, risky 
and expensive to create a new, distributed infrastructure.  By contrast, 
it is only modestly difficult to add to an existing infrastructure (if 
one is very careful.)


MIME managed to turn text email into multimedia without modifying the 
global email infrastructure at all.  Only the author and the recipients 
had to adopt it.  This is astonishingly cheaper than if they/we had had 
to create an entire, global infrastructure for multimedia mail.


There will come a point at which there is a strong desire to add a 
feature that we can't figure out how to add to the existing email 
service.  But over those 50 years, we haven't hit that limit yet, in 
spite of so many changes needed.



And don't be afraid to say no when it comes to adding every little 
feature into this protocol.  I'm not a huge fan of mailing lists or 
distributed mailings (forums accomplish the same thing with less of the 
hassle of email deliverability concerns). 


Centralized platforms are much easier to develop and run than 
distributed ones, of course.  But they also are a pain, moving 
operational hassles to users, when one has to flit from one to the next, 
checking for new postings.  So, again:  tradeoffs.




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

Re: [mailop] Anyone heard of this network? Looks like a spear phishing operation?

[Andrew C Aitchison via mailop]

On Wed, 2 Feb 2022, Michael Peddemors via mailop wrote:


But of course I could be wrong, and it has some form of valid use..

But none of the names match up to host records.. Just some significant names 
there, and thought better get the work out.



# -- IPXO_141_11_29 [141.11.29.0/24]


rwhois gives the /24 an address in the UK
but a +370 phone number in Lithuania.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Musings on Mail Service Operators

[Scott Mutter via mailop]

A lot of the issues stem from the way IT managers, and maybe technology
managers in general bathe in arrogance.  "There's no such thing as a good
idea, unless it is *my* idea."  It's easier to get blood out of a stone
than for someone in IT to admit that someone else's approach to something
has merit.

Email - as we know it - should have been dead years ago.  But instead we
keep adding band-aid after band-aid after band-aid to the system.

Why is it impossible to take a look at what Instant Messaging protocols,
SMTP, SMS do that make them successful and then blend those together into a
new "email-like" system?

I'm not going to pretend to know what the ultimate solution might be.  One
of the major issues with email is the address spoofing that goes on.  Maybe
a spoofed address doesn't authenticate with SPF or DKIM... but that only
works if EVERYONE else uses SPF and DKIM... that's the bandaid.  Instant
messaging and SMS can't as easily be spoofed, they may be fake but senders
have to register on the platform in some way (be it a Facebook account,
Twitter account, phone number, etc).  Would more need to be done to lock
this down?  Absolutely.  But it's at least A obstacle that potential
abusers have to overcome.  Email doesn't have that.

But as others have said there are definitely constraints to these instant
messaging and SMS protocols: size, content, searchability, etc.  These are
things that regular email does well.

Email was first invented in 1971 - that's over 50 years ago.  We've learned
a lot about how people tend to use email and how people tend to abuse email
within the past 50 years.  Instead of adding new constructs to email.  Why
not invent a new, more modern email alternative?  Something that takes a
lot of what we've learned from email usage over the years, what we've seen
in instant messaging, SMS, and other computer communication protocols and
builds on that from the ground up?  Wouldn't that be better than constantly
adding band-aids to email/SMTP to fix problems that pop up?

And don't be afraid to say no when it comes to adding every little feature
into this protocol.  I'm not a huge fan of mailing lists or distributed
mailings (forums accomplish the same thing with less of the hassle of email
deliverability concerns).  Not a huge fan of automatic email
forwarders/redirects, which tend to break SPF and DKIM.  Maybe things like
these don't need to be allowed?

I just think it's time we stop worrying about how we're going to carry
email over into the 2030s, 2040s, 2050s and on.  And instead start looking
at how we can create an email replacement from the ground up.  Too many
people invested in email, you say?  Email was around before SMS, before
Facebook, before whatever other communication medium kids are using these
days.  Yet those platforms don't seem to have an issue in getting people to
use them.  Why couldn't a properly reimagined email replacement do the same
thing?

On Wed, Feb 2, 2022 at 5:52 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia  2.02.2022 o godz. 18:26:38 yuv via mailop pisze:
> >
> > Either it will go the other way, or folks will move away from email all
> > together.  I am moving away.  I miss the ability to store away in
> > Maildir format my correspondence and to look back in the archives to
> > Eudora times and earlier, but since I made the decision to prefer other
> > methods of electronic communication over email, I feel much better.
>
> Just out of curiosity: what better methods of communication did you find? I
> can't find any. Text messages via phone won't do, any IM-type programs (be
> it Facebook Messenger, Signal, Telegram or anything else) won't do either.
> They are unsearchable, unmanageable, limited in size and in the type of
> content you can send, plus there is the mentioned "walled gardens" issue,
> that is, (except of text messages) you have to use the same service than
> the
> person you try to communicate with.
>
> For me, still nothing beats e-mail - even with all the deliverability
> problems...
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Musings on Mail Service Operators

[Jaroslaw Rafa via mailop]

Dnia  2.02.2022 o godz. 18:26:38 yuv via mailop pisze:
> 
> Either it will go the other way, or folks will move away from email all
> together.  I am moving away.  I miss the ability to store away in
> Maildir format my correspondence and to look back in the archives to
> Eudora times and earlier, but since I made the decision to prefer other
> methods of electronic communication over email, I feel much better.

Just out of curiosity: what better methods of communication did you find? I
can't find any. Text messages via phone won't do, any IM-type programs (be
it Facebook Messenger, Signal, Telegram or anything else) won't do either.
They are unsearchable, unmanageable, limited in size and in the type of
content you can send, plus there is the mentioned "walled gardens" issue,
that is, (except of text messages) you have to use the same service than the
person you try to communicate with.

For me, still nothing beats e-mail - even with all the deliverability
problems...
-- 
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] Walled gardens

[yuv via mailop]

Sorry for the late reply, Bill.  Life.  In absence of external
governance factors, I can only self-govern.  I decided to self-govern
toward co-operation rather than confrontation, let's work through the
little misunderstandings.


On Thu, 2021-12-30 at 11:29 -0500, Bill Cole via mailop wrote:
> On 2021-12-29 at 07:40:01 UTC-0500 (Wed, 29 Dec 2021 07:40:01 -0500)
> yuv via mailop 
> is rumored to have said:
> 
> > On Tue, 2021-12-28 at 21:59 -0500, John Levine via mailop wrote:
> > > It appears that yuv via mailop  said:
> > > > The first thing to make internet email viable for the future is
> > > > to
> > > > establish a defensible perimeter and keep bad actors
> > > > out.  Easier
> > > > said
> > > > than done. ...
> > > 
> > > Unfortunately, e-mail walled gardens are a Well Known Bad Idea.
> > 
> > RFCs-based e-mail is a walled garden.
> 
> You may have missed the fact that "walled garden" is actually an 
> established bit of jargon in an Internet context

Forgive me for using established jargon, I will accept the focus on the
world that started on 00:00:00 UTC on 1 January 1970 and rephrase my
argument in more precise terms than my previous use of terms
established by a slightly older Western cult [1].


> So, in short: no, it is not.

You are right.  It's not walled, it is surrounded by a Ring of Fire. 
And it is Hell, not a garden.

A wall is a barrier.  It creates two separate spaces: a protected space
on the inside and the remainder outside.  Sometimes, the protected
space is the desirable space and it is called a garden in opposition to
the wilderness outside.  Desirability is a matter of opinion and so is
the use of the term "garden".

You do, elegantly, put up a different kind of walls to protect inside
space [2].

RFCs (or the implementations described within, to use your definition
of what RFCs are) are a barrier to enter the inside and participate in
the system.  Unlike your barriers cited above, the barrieres
implemented and described in RFCs are unintentional barriers, but the
end effect is that the complexity makes the system worse, not better;
and spammers benefits more of that complexity than non-spammers.  But
that is again a matter of opinion: spam is in the eyes of the
recipient.  Always.


> > We lawyers call this the Rule of Law.
> 
> LOL. RFCs are "law." Not in *any* way. RFCs are documentation.

Sir Isaac Newton merely documented gravity [3].


> RFCs are not law. Not ever. Can't improve a "Rule of Law" that has
> no laws and only pragmatic, heuristic rules in the form of
> documentation.

With all due respect, "Rule of Law" is actually an established bit of
political and philosphical thinking [4].  You are mistaking "Rule of
Law" for the collection of statutes imposed on the land by legislators
and enforced by the power of government.  These are artificial rules. 
Some rules are natural, some are artificial.  Artificial rules can be
improved, and RFC (or the underlying, described implementations) are
definitely artificial and definitely can be improved.


> There is no "rule of law" on the Internet because it is defined, 
> designed, and developed as a giant pile of autonomous entities who 
> interact in documented ways developed by experimentation and 
> collaboration. There is no penalty for not working together, beyond
> not working together.

There is no penalty for ignoring the law of universal gravitation,
beyond... oh, wait a minute, why is it so difficult to move to a
different planet, leaving the "90% crap" behind? (you referenced
Sturgeon's Law [5]).  Sometimes, natural penalties are more powerful
than the most powerful penalties that governing entities can mete. 
Governing entities are subject to the Rule of Law like anyone else.  In
fact, the Rule of Law applies to any political setting, including loose
and experimental collaboration.


> Not law, documentation. RFC5321 describes the state of SMTP, as of
> 2008, sorta. How it was working best then, to the degree that the
> editor and authors could reach consensus. The changes from 2821 to
> 5321 are clarifications, consolidations, and updates reflecting the
> evolution of implementations of SMTP in the interim.

Documentation with consequences = law.

To bring it back to Sturgeon's Law: the percentage depends on the
choice of denominator.  Miopically setting the denominator to all
internet emails ignores my reality (and possibly the reality of many
users) that if the denominator includes all electronic transmissions,
internet email is over-represented in the numerator.

The result is the rise of alternative messaging platforms.  The
displacement of mission-critical inter-entities transmissions to other
tools.  It takes just a little bit of courage to jump outside the Ring
of Fire and move away from email-first to prioritize other forms of
electronic communication with less headache.


[1] 

[2] 

Re: [mailop] Musings on Mail Service Operators

[yuv via mailop]

On Wed, 2022-02-02 at 11:20 +0100, Jaroslaw Rafa via mailop wrote:
> Dnia  2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze:
> > I start to earnestly wonder when folks [...]
> > will attempt to regain knowledge to run their own and small-scale
> > mail systems again
> 
> I think it will rather go the other way

Probably.

Either it will go the other way, or folks will move away from email all
together.  I am moving away.  I miss the ability to store away in
Maildir format my correspondence and to look back in the archives to
Eudora times and earlier, but since I made the decision to prefer other
methods of electronic communication over email, I feel much better.

I still owe an answer to Bill about Walled Gardens.  It will come,
eventually, maybe, if it was not caught in the spam filter.

--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer


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

Re: [mailop] Office 365 Assistance

[Michael Wise via mailop]

If, as you say, they are Office365 customers, they could always open a ticket 
with Customer Support ….
What are the sending IPs?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?

From: mailop  On Behalf Of Michael E. Weisel via 
mailop
Sent: Tuesday, February 1, 2022 8:06 PM
To: mailop@mailop.org
Subject: [EXTERNAL] [mailop] Office 365 Assistance

Hi everyone, I hope you are all well and staying healthy and safe.  We’ve been 
working with The Home Depot on their Retool Your School Program 
(https://retoolyourschool.com/) for more than ten years now.  Over the past 
year and especially the last few months, we are having a hard time getting 
their emails to the intended recipients with a lot of their messages going to 
junk.  All the messages are going to HBCU’s (Historically Black College and 
Universities) and a lot of them are using Microsoft Office 365.  We’ve begun to 
ask the colleges to mark their IP, domain, and email address as safe senders 
but it’s hard to reach everyone personally.  The messages are not bouncing 
back, just ending up in Junk for a large majority of subscribers.  This is a 
100% opt-in program, and the list size is under 700 subscribers.  They send out 
once to twice a week from December through May.  All the colleges are competing 
for more than $500,000 in campus improvement prizes and many schools can’t 
participate because they aren’t receiving the emails. They have a dedicated IP 
address and custom DNS.  It’s setup with SPF, DK, DKIM, DMARC, SNDS, JMRP, and 
a “List Unsubscribe” in the header.  I’ve filled out the forms for Office 365 
support and the IP isn’t blocked.  I also filled out the Microsoft support form 
and the IP is also not blocked there or any indication through SNDS that there 
are any issues.  If anyone on list may be able to help, the program would be 
greatly appreciative.



Thanks,

Michael

Michael E. Weisel
CTO / Deliverability Lead
Gold Lasso
(301) 990-9857 Corporate
(240) 813-0174 Direct Dial

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

[mailop] Mid-Week state of the Union, spam, threats and observations from the trenches.

[Michael Peddemors via mailop]

Just a friendly mid week report on the state of spam and threats our 
auditors are seeing..


Still seeing a couple of actors using Digital Ocean..

Actor 1)

143.110.147.238   2   vps1.geniusys.org
143.198.135.159 (M)   2   vps1.ok4ya.com
147.182.200.110 (M)   2   vps1.4tickets.org
147.182.224.47  (M)   2   vps1.gwsunday.com
147.182.226.59  (M)   2   vps1.designchina.org
147.182.234.194 (M)   2   vps1.luck3d.org

Actor 2)

143.198.134.22  (M)   1   email-14.getprospect.cc
143.198.16.156  (M)   1   email-12.getprospect.ch
143.198.57.2161   email-33.getprospect.app
159.223.49.68   (M)   1   email-27.getprospect.co
162.243.17.244  (M)   1   email-32.getprospect.nl
192.241.176.221 (M)   1   email-21.getprospect.co.uk
192.241.246.154 (M)   1   email-18.getprospect.nl
198.199.116.201 (M)   1   email-10.getprospect.ch
198.199.126.185 (M)   1   email-25.getprospect.app
198.199.127.109 (M)   1   email-30.truemail.io
198.199.96.44   (M)   1   email-3.getprospect.com.de
209.97.152.20 1 email-18.getprospect.com.de

Actor 3)

159.223.14.7(M)   1   cm30srv.libdlget.ir
174.138.1.77(M)   1   cm23.iman.info
174.138.4.60(M)   1   cm22.iman.info
174.138.5.148   (M)   1   cm21.iman.info
198.199.124.207 (M)   1   cm26.shift-bot.com
37.139.2.134(M)   1   cm27.shift-bot.com
   80.240.128.144   (M)   1   cm16.bitchanger.org
   80.240.128.187   (M)   1   cm17.bitchanger.org
80.240.128.49   (M)   1   cm29.bitchanger.org
   80.240.128.52(M)   1   cm15.bitchanger.org
(They also use other networks like Hetzner/OVH et al)
195.201.226.170 (M)   1   cm14.sparkpost.ir
23.88.109.173   (M)   1   cm12.sparkpost.ir
137.74.191.163  (M)   1   cm3.beefland.ir
   137.74.191.164   (M)   1   cm4.beefland.ir
   137.74.191.165   (M)   1   cm5.beefland.ir

Plus of course the usual brand of snowshoe spammers using their networks.

Still seeing abusive patterns/exploits/fake account phishing and 
spammers from SendGrid/Mailgun at excessive levels this last week or two.


Brazil/Argentina still leading in GPON and compromised router attacks

Amazon AWS still a very large attack surface for email compromise 
attacks, as well as spamming.


A very unique attacker from compromised servers is on our radar, a very 
special fingerprint makes it easy to detect, but we are interested in 
who is behind that one, because given that they have no geo preference 
in who they attack from, they are a different breed.


Anyone in blue teams, that wants detail reach out off list.

Wish 'NewTrends' IP(s) had PTR records, increase in attacks from their 
IP space again.


The Azure spammer keeps getting new IP(s), I think they pick a new 
naming pattern every month, and either warm them up somehow, but a 
continuing problem for almost a year now..


20.36.39.35 x1  nbdigital10.acceder-dispositivonovob.com
20.36.40.177x4  nbdigital8.acceder-dispositivonovob.com
20.74.164.87x1  nbdigital87.acceder-dispositivonovob.com
20.92.105.206   x3  nbdigital17.acceder-dispositivonovob.com

Do I even have to mention how bad Gmail is getting? Such obvious 
attacks, spam, nigerian prince, etc..


Outlook is trying hard to catch up though it seems recently ;)

Still seeing one or new snowshoe spammer ranges every day from the usual 
suspects, such as Psych, Multicom, and known bullet proof hosters.


And miscreants from south east asia getting bolder.. plus of course, 
ISP's over there that are doing little to stop it..


China has become relatively quiet of late.

And the ongoing OVH problems of course, at least they are easy to catch 
most of the time.


15.235.3.29 x152ip29.ip-15-235-3.net
15.235.3.43 x18 ip43.ip-15-235-3.net
15.235.3.45 x10 ip45.ip-15-235-3.net
15.235.30.105   x79 ip105.ip-15-235-30.net
15.235.30.106   x112ip106.ip-15-235-30.net
15.235.30.108   x6  ip108.ip-15-235-30.net
15.235.30.109   x18 ip109.ip-15-235-30.net
15.235.30.110   x62 ip110.ip-15-235-30.net
15.235.30.111   x89 ip111.ip-15-235-30.net
15.235.30.113   x48 ip113.ip-15-235-30.net
15.235.30.114   x152ip114.ip-15-235-30.net
15.235.5.100x19 ip100.ip-15-235-5.net
15.235.5.104x131ip104.ip-15-235-5.net
15.235.5.105x289ip105.ip-15-235-5.net
15.235.5.106x13 ip106.ip-15-235-5.net
15.235.5.108x60 ip108.ip-15-235-5.net
15.235.5.109x180ip109.ip-15-235-5.net
15.235.5.110x171ip110.ip-15-235-5.net
15.235.5.111x55 ip111.ip-15-235-5.net
15.235.5.112x155ip112.ip-15-235-5.net
15.235.5.113x87 ip113.ip-15-235-5.net
15.235.5.114x179ip114.ip-15-235-5.net

Re: [mailop] Office 365 Assistance

[Antonie Popovic via mailop]

Hi Michael,

I'm seeing this issue quite often lately and in the majority of the cases
the problem is when M365 email hosted companies are using an extra layer of
email hygiene (Mimecast, IronPort, etc) before their Exchange Online
Gateway because some of them are still using the Exchange DMARC checks and
doing the checks against their own hygiene layer instead of the original
sender. You would be able to confirm this if you check the routing in the
email headers of those messages placed in the Junk folder.

Hope this helps,
Toni


On Wed, Feb 2, 2022 at 5:58 AM Michael E. Weisel via mailop <
mailop@mailop.org> wrote:

> Hi everyone, I hope you are all well and staying healthy and safe.  We’ve
> been working with The Home Depot on their Retool Your School Program (
> https://retoolyourschool.com/) for more than ten years now.  Over the
> past year and especially the last few months, we are having a hard time
> getting their emails to the intended recipients with a lot of their
> messages going to junk.  All the messages are going to HBCU’s (Historically
> Black College and Universities) and a lot of them are using Microsoft
> Office 365.  We’ve begun to ask the colleges to mark their IP, domain, and
> email address as safe senders but it’s hard to reach everyone personally.
> The messages are not bouncing back, just ending up in Junk for a large
> majority of subscribers.  This is a 100% opt-in program, and the list size
> is under 700 subscribers.  They send out once to twice a week from December
> through May.  All the colleges are competing for more than $500,000 in
> campus improvement prizes and many schools can’t participate because they
> aren’t receiving the emails. They have a dedicated IP address and custom
> DNS.  It’s setup with SPF, DK, DKIM, DMARC, SNDS, JMRP, and a “List
> Unsubscribe” in the header.  I’ve filled out the forms for Office 365
> support and the IP isn’t blocked.  I also filled out the Microsoft support
> form and the IP is also not blocked there or any indication through SNDS
> that there are any issues.  If anyone on list may be able to help, the
> program would be greatly appreciative.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> Michael
>
>
>
> Michael E. Weisel
>
> CTO / Deliverability Lead
>
> Gold Lasso
>
> (301) 990-9857 Corporate
>
> (240) 813-0174 Direct Dial
>
>
> ___
> 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] Musings on Mail Service Operators

[Carsten Schiefner via mailop]

On 02.02.2022 11:20, Jaroslaw Rafa via mailop wrote:

Dnia  2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze:

Having now also read Michael's call for O365 assistance, I start to
earnestly wonder when folks are tired enough of having put their
email fate into the hands of a few mega-large Mail Service Operators
with kafkaesque and fully intransparent processes and instead will
attempt to regain knowledge to run their own and small-scale mail
systems again as they realize that proper and flawless electronic
communication is part of their core business functions - whatever
that business exactly might be.


I think it will rather go the other way, because of the scale of those
mega-large mail operators. Because of their scale, the average user's
perception is that "almost everybody" is using them, so if somebody has
problems with delivering mail to them, something must be wrong with the
sender, and not with those large operators. They are "too big to be wrong".
For the users using them the solution is simple: if you have problems
delivering mail to the large operator, you should switch to that operator as
well, instead of using some "unknown mail service". Then you will have no
problems.

And that's exactly what those big operators want...


That unfortunately makes quite some sense to me, too, Jaroslaw.

And it appears to be a classic perpetrator/victim reversal wrt. to the 
perception of the public... :-/

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

Re: [mailop] Musings on Mail Service Operators

[Jaroslaw Rafa via mailop]

Dnia  2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze:
> Having now also read Michael's call for O365 assistance, I start to
> earnestly wonder when folks are tired enough of having put their
> email fate into the hands of a few mega-large Mail Service Operators
> with kafkaesque and fully intransparent processes and instead will
> attempt to regain knowledge to run their own and small-scale mail
> systems again as they realize that proper and flawless electronic
> communication is part of their core business functions - whatever
> that business exactly might be.

I think it will rather go the other way, because of the scale of those
mega-large mail operators. Because of their scale, the average user's
perception is that "almost everybody" is using them, so if somebody has
problems with delivering mail to them, something must be wrong with the
sender, and not with those large operators. They are "too big to be wrong".
For the users using them the solution is simple: if you have problems
delivering mail to the large operator, you should switch to that operator as
well, instead of using some "unknown mail service". Then you will have no
problems.

And that's exactly what those big operators want...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Musings on Mail Service Operators

[Carsten Schiefner via mailop]

Having now also read Michael's call for O365 assistance, I start to 
earnestly wonder when folks are tired enough of having put their email 
fate into the hands of a few mega-large Mail Service Operators with 
kafkaesque and fully intransparent processes and instead will attempt to 
regain knowledge to run their own and small-scale mail systems again as 
they realize that proper and flawless electronic communication is part 
of their core business functions - whatever that business exactly might be.


Best,

-C.

 Forwarded Message 
Subject: [mailop] Office 365 Assistance
Date: Wed, 2 Feb 2022 04:06:20 +
From: Michael E. Weisel via mailop 
Reply-To: Michael E. Weisel 
To: mailop@mailop.org 



Hi everyone, I hope you are all well and staying healthy and safe.  
We’ve been working with The Home Depot on their Retool Your School 
Program (https://retoolyourschool.com/) for more than ten years now.  
Over the past year and especially the last few months, we are having a 
hard time getting their emails to the intended recipients with a lot of 
their messages going to junk.  All the messages are going to HBCU’s 
(Historically Black College and Universities) and a lot of them are 
using Microsoft Office 365.  We’ve begun to ask the colleges to mark 
their IP, domain, and email address as safe senders but it’s hard to 
reach everyone personally.  The messages are not bouncing back, just 
ending up in Junk for a large majority of subscribers.  This is a 100% 
opt-in program, and the list size is under 700 subscribers.  They send 
out once to twice a week from December through May.  All the colleges 
are competing for more than $500,000 in campus improvement prizes and 
many schools can’t participate because they aren’t receiving the emails. 
They have a dedicated IP address and custom DNS.  It’s setup with SPF, 
DK, DKIM, DMARC, SNDS, JMRP, and a “List Unsubscribe” in the header.  
I’ve filled out the forms for Office 365 support and the IP isn’t 
blocked.  I also filled out the Microsoft support form and the IP is 
also not blocked there or any indication through SNDS that there are any 
issues.  If anyone on list may be able to help, the program would be 
greatly appreciative.


Thanks,

Michael

Michael E. Weisel

CTO / Deliverability Lead

Gold Lasso

(301) 990-9857 Corporate

(240) 813-0174 Direct Dial
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail does not validate DKIM for forwarded messages?

[Edgaras | SENDER via mailop]

> I mean, you did originally send the spam message from one of your IPs.
This is certainly an amplification attack from that fact, sure.
> I'm not sure that it's any different from previous replay attacks in that
sense.
A regular attack would be greatly diminished by Gmail rejecting messages
from IPs with DNS/rDNS mismatch, SPF fail, and so on - this attack went
through, and to inboxes no less.

> And presumably the reputation decline is due to us catching most of those
messages as spam.  Superficially, it looks like our system correctly
> handled this from a spam labeling perspective, and the collateral damage
was mostly contained.
Not really - we saw spam complaint rate for that domain spike to 0.9%, a
value we have never seen before. This indicates that messages were not
filtered.

> I think it's a fairly complicated question about how to handle reputation
in these instances, the reputation of your domain has been dinged due
> to its usage in spam.  This more often happens in advertised domain
reputations.  In terms of correctly determining spam/not spam for our
customers,
> the reputation is correct.
>From my experience, mere usage of a domain in a spam campaign does not have
such an impact on domain reputation. We saw spammers trying to abuse our
URL shorteners before, and these domains were not impacted as much.

ProtonMail experienced the same recently -
https://protonmail.com/blog/dkim-replay-attack-breakdown/ - they have been
able to get help with this issue. Can someone assist us?



[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Tue, Feb 1, 2022 at 11:03 PM Brandon Long  wrote:

> I mean, you did originally send the spam message from one of your IPs.
> This is certainly an amplification attack from that fact, sure.
> I'm not sure that it's any different from previous replay attacks in that
> sense.
>
> If you take the "normal" way this would work, is that a spam message would
> go through a mailing list (presumably one that didn't break the dkim
> signature), then you would want most of the blame for the spam to go to
> the original sender, and not the mailing list.
>
> And presumably the reputation decline is due to us catching most of those
> messages as spam.  Superficially, it looks like our system correctly
> handled this from a spam labeling perspective, and the collateral damage
> was mostly contained.
>
> I think it's a fairly complicated question about how to handle reputation
> in these instances, the reputation of your domain has been dinged due
> to its usage in spam.  This more often happens in advertised domain
> reputations.  In terms of correctly determining spam/not spam for our
> customers,
> the reputation is correct.
>
> The system does not rely on only a single reputation, however.  In this
> case, there is also the SPF & IP reputations, which should be unaffected by
> the relay
> campaign.  Theoretically, the system should be able to mostly compensate
> for messages coming from your system, which means the consequences would
> mostly accrue to forwarded messages.  It's hard to guarantee that in an
> emergent system, of course.
>
> I do think this is useful to understand for ARC in regards to such a
> system, that "SPF" or "IP" reputation should be different from ARC-SPF or
> ARC-IP reputation.
> In terms of applicability to DMARC, however, the message is no less
> "legitimately authenticated", but that was already true because of the DKIM
> passing.
>
> And, of course, ARC (or DMARC) doesn't indicate spamminess directly,
> merely the source.  And the source was your service, originally.
>
> Brandon
>
> On Tue, Feb 1, 2022 at 2:15 AM Edgaras | SENDER 
> wrote:
>
>> > You can also see that the bodyhash (bh=) in the AMS and DKIM headers is
>> all the same, so the body itself didn't change?
>> No, the email body did not change.
>>
>> > Note that although ARC from gmail to gmail can be used to bypass a DKIM
>> failure, that's not what's happening here.
>> Yes, here it looks like if Gmail sees ARC (Gmail to Gmail) headers, it
>> trusts them completely:
>> - it ignores SPF permerror:
>> spf=permerror (google.com: permanent error in processing during lookup of
>>  921108683ccq405...@universidadebrasil.edu.br:
>> host.universidadebrasil.email not found) smtp.mailfrom=
>> 921108683ccq405...@universidadebrasil.edu.br
>> Return-Path: <921108683ccq405...@universidadebrasil.edu.br>
>> Received: from lingojam.com ([212.83.129.110])
>> - ignores DNS/rDNS mismatch: rDNS for IP 212.83.129.110:
>> nelson-montoya.painmitigate.com, no A record.
>> - somehow thinks that the initial sending domain (sendersrv.com) should
>> be blamed, even though none of the intermediate IP addresses fall into
>> original domain's SPF, which contains -all
>> - and delivers spam to the inbox, no less.
>>
>> > A replay attack is the most likely explanation, yes.
>> It's a replay attack, but more sophisticated and dangerous due to use of
>> Gmail-Gmail ARC headers technique.
>>
>> We have