Re: [mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

I'd love to be able to drop them, but the situation is made in a way that
we can not do anything:
That user configured their bounce domain to pass through us, but we didn't
send their bouncing email in the first place. they use another service for
that.

As long as they point their bounce domain to us, we will receive this
amount of emails back.
The only things possible to stop this is either to block this user from
sending any more emails (we aren't the senders, so we don't have any
leverage here) or to change the MX of their domain to something else (and
we don't own their domain).

That's why we are desperately trying to find a solution. In the meantime,
we are in discussion - with the service that this user is using to send
emails - to see with them how we can mitigate this, hopefully make this
client stop using our MX.

Since it's impossible to just stop that flux of incoming connections, I was
hoping you had some other ideas to avoid this, hence my original email.

Thank you for your message and your help :)

Le mer. 23 nov. 2022 à 13:31, Peter N. M. Hansteen  a
écrit :

>
>
> On 11/23/22 10:39, Cyril - ImprovMX via mailop wrote:
>
> > I forgot to mention this, but indeed, the first thing we did was contact
> > them. We had no response, so we blocked them and later realized that the
> > email contact we had was a black hole on their end, so we reached out
> > using another email we found and got a response. They are looking into
> > it, but I still wonder how we can have what is now 70k connections per
> > minute solely from Outlook.
>
> I think you have just described a textbook example of a customer that
> needs to be dropped, urgently.
>
> Your initial description was vague enough that it was almost possible
> that they were just clueless, but their giving you bad contact info
> rules that out. They are *bad actors*, and should be treated accordingly.
>
> If you can extract compensation for the damage they have done, that
> would be a good thing.
>
> If you keep them on as customers, your own reputation will suffer and
> you will likely lose business over this matter.
>
> Please, do the right thing. LART them to the maximum extent possible if
> you can, but stop providing any kind of service to them.
>
> All the best,
> Peter
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Tobias Fiebig via mailop]

Heho,
> Please, give us the IP ranges these clowns are using so we can block all 
> traffic from them.
Not sure which 'clowns' you refer to; 

If this is about the sum of researchers under the mechanics of current academia 
which might release crappy measurements to the public, I sadly lack such a list;
If I manage to get the circus^Wmeasurement AS going I will certainly share the 
prefixes (and ASN) for people to block. After all, that is part of its point.

If you are referring to Tijay: Stuff is being built on EC2, and I leave it to 
Tijay if he already wants to share the IPs; 
However, as long as I can and want to give some input on that project, that SPF 
measurement setup will not originate any measurements until some issues are 
resolved. So, I am not sure how much of a point is in that at the moment, 
especially as those addresses may still change.

If and when those issues are resolved whatever IPs it will be running from will 
be first communicated, with enough time for people to take measures.

With best regards,
Tobias

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

Re: [mailop] SPF (and other email security protocols) Survey

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>My argument was that it is hardly possible to gain a sufficient understanding 
>of many protocols to be able to thoroughly design network
>measurements while accounting for all possible harms within the time available 
>for a PhD. 

I happen to have a PhD in computer science, and if that is your
experience, I feel sorry for your students. I also wonder about the
kind of department that would let students do that kind of "research"
without supervision from faculty who are sufficiently familiar with
the field to ensure that their students do real work. "Are SPF lookups
making too many queries" could be a plausible master's project but
it's way too trivial for a PhD thesis.

Please, give us the IP ranges these clowns are using so we can block all 
traffic from them.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Tobias Fiebig via mailop]

Hello John,
> So if they were competemnt and ethical, tney would stop and find people to 
> work with who understand the issues so they can do research that is not 
> abusive and could have useful results.  Unfortunately, as we have seen, they 
> are neither.

I personally believe (and sincerely hope that my believes are not disappointed 
here) that this stopping, reflecting, and improving is currently taking place, 
and has been for some time, as signified by no new mail measurements I know of 
having hit the world from the group so far.

> Having spent my entire life in and around academia, I have no sympathy for 
> people who say that since we are so nice and our goals are virtuous it 
> excuses the stuff we are doing. No, it does not.

You are attacking a strawman here, one where I obviously (and usually quiet 
aggressively) agree with your point.

My argument was that it is hardly possible to gain a sufficient understanding 
of many protocols to be able to thoroughly design network measurements while 
accounting for all possible harms within the time available for a PhD. That is 
just as much a recipe for disaster as it is a practical reality for many people 
out there; Start your PhD, do four papers in four years, and have your first 
one submitted by the end of year 1. Learning by doing, breaking too much in the 
meantime, which is not a desirable state of affairs, especially given that with 
the standard-academia-workload no PI will be able to thoroughly vet what their 
students built.

To still be able to make a positive difference, I started my current efforts to 
build something to curb this issue; Because no matter if one extends sympathies 
to people doing harm out of ignorance (no matter whether you see the cause for 
that in an underlying system or not), the truth is also that those measurements 
will keep hitting the Internet.

I might have a bit too much of an idealistic world view here, but I believe 
established infrastructure which provides proper feedback from more experienced 
people before packets hit the fan (to which one can also point people to if 
they make mistakes) can really make a positive difference here, especially if 
people who really know what they are doing are willing to look at things before 
they are let out on the Internet.

Talking of which: John, would you be willing to be part of something like that? 
I mean, it will probably take quiet some time until I have this going, so this 
would be a commitment for an undetermined future point in time (mostly due to 
me not having a /23 v4 spare for the project; But I am working on it. And of 
course then there is the adoption thing.)... But I believe your eyes in such a 
project might actually allow quiet a lot of students to learn a lot.

With best regards,
Tobias

 

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

Re: [mailop] [EXTERNAL] Re: Contact at Outlook?

[Michael Wise via mailop]

... From time to time.



If it can't be handled with the IP delisting form, it's going to be very 
difficult for an external party to get a hold of someone in an org that handles 
billions of emails a day. And I'm not someone who can do anything about such 
issues as a general rule.

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



-Original Message-
From: mailop  On Behalf Of Atro Tossavainen via 
mailop
Sent: Wednesday, November 23, 2022 2:26 PM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] Contact at Outlook?



On Wed, Nov 23, 2022 at 04:01:30PM -0600, Jarland Donnell via mailop wrote:

> Assuming that doesn't pan out, can you file an abuse complaint with

> their DNS provider? Sure can't hurt anything.



Oddly enough Microsoft's DNS provider is... Microsoft.



Microsoft has an employee participating on this list.



--

Atro Tossavainen, Founder, Partner

Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)

Tallinn, Estonia

tel. +372-5883-4269, 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.koliloks.eu%2F=05%7C01%7Cmichael.wise%40microsoft.com%7Ce442a6128d304d9ca76608dacda21d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048393561432126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=NavAOkbpSq%2Bqcep76wupKJ7Gtuyqd6yy%2FSaXvZ83KLU%3D=0

___

mailop mailing list

mailop@mailop.org

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=05%7C01%7Cmichael.wise%40microsoft.com%7Ce442a6128d304d9ca76608dacda21d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048393561432126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XfwF75usbYTbV76pWopiM6jXxuPaGiw2KNxp3zm5NNA%3D=0
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>Yes, I do, see Footnote ** of my previous mail; But to recap: It is a complex 
>problem between how academia is setup, what it incentivizes, what
>it requires, what it rewards, and who does network measurement research 
>(usually people without operational experience working on things technically 
>too big for a single PhD). 

So if they were competemnt and ethical, tney would stop and find people to work
with who understand the issues so they can do research that is not abusive and
could have useful results.  Unfortunately, as we have seen, they are neither.

Having spent my entire life in and around academia, I have no sympathy
for people who say that since we are so nice and our goals are
virtuous it excuses the stuff we are doing. No, it does not.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at Outlook?

[Atro Tossavainen via mailop]

On Wed, Nov 23, 2022 at 04:01:30PM -0600, Jarland Donnell via mailop wrote:
> Assuming that doesn't pan out, can you file an abuse complaint with
> their DNS provider? Sure can't hurt anything.

Oddly enough Microsoft's DNS provider is... Microsoft.

Microsoft has an employee participating on this list.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at Outlook?

[Cyril - ImprovMX via mailop]

That's a good idea ! I will do that !

Thank you !

Le mer. 23 nov. 2022, 23:10, Jarland Donnell via mailop 
a écrit :

> Assuming that doesn't pan out, can you file an abuse complaint with
> their DNS provider? Sure can't hurt anything.
>
> On 2022-11-23 13:12, Cyril - ImprovMX via mailop wrote:
> > Hi everyone ,
> >
> > I'm hoping that someone will be able to put me in contact with someone
> > working at Outlook.
> >
> > We are still having a really bad issues regarding our previous
> > discussion on having a lot of bounces and I'm hoping to have some help
> > from someone ar Outlook.
> >
> > Thank you !
> >
> > Best,
> > Cyril
> > ___
> > 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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at Outlook?

[Jarland Donnell via mailop]

Assuming that doesn't pan out, can you file an abuse complaint with 
their DNS provider? Sure can't hurt anything.


On 2022-11-23 13:12, Cyril - ImprovMX via mailop wrote:

Hi everyone ,

I'm hoping that someone will be able to put me in contact with someone
working at Outlook.

We are still having a really bad issues regarding our previous
discussion on having a lot of bounces and I'm hoping to have some help
from someone ar Outlook.

Thank you !

Best,
Cyril
___
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] Contact at Outlook?

[Cyril - ImprovMX via mailop]

Hi everyone ,

I'm hoping that someone will be able to put me in contact with someone
working at Outlook.

We are still having a really bad issues regarding our previous discussion
on having a lot of bounces and I'm hoping to have some help from someone ar
Outlook.

Thank you !

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Tobias Fiebig via mailop]

Hey Bill,

> Do you know why his students have at least twice in the past engaged in 
> deceptive spamming to gather data?

Yes, I do, see Footnote ** of my previous mail; But to recap: It is a complex 
problem between how academia is setup, what it incentivizes, what it requires, 
what it rewards, and who does network measurement research (usually people 
without operational experience working on things technically too big for a 
single PhD). 
You can, of course, now simply tie that to Tijay, who at least starts to engage 
with the issue now, and tries to be part of a solution instead of the problem;
Then again, as I said, it is a wider problem, and there surely is a ton more 
science-y-groups that are doing similar things, but simply did not pop up on 
your radar yet.

I for one personally prefer working on fixing the underlying problem instead of 
keeping beating on a person that is actually developing awareness of the issue. 
Because academia will not go away. PhDs doing research won't. So,... well. 
Let's fix things instead.

> Frankly, there's no chance that I'll ever cooperate with that person's 
> research.

This is fine. Your choice, and also the reason I am trying to build one stable 
AS for that kind of research, so people can easily enforce never being involved 
on multiple network layers, without running the risk of, e.g., blocking IPs 
that are later used by a different entity (when using stuff like EC2, for 
example). Similarly, that's the reason why such an entity should have a board 
checking planned research that actually involves non-academics. In the end, 
well done research can be really beneficial (e.g., by figuring out changes to 
RFCs); It just MUST not cause harm, and that harm is often not apparent, 
certainly not to people usually found in IRBs, and often not even for people 
that are not actively involved in that _specific_ type of system (Say, DNSOP 
assessing Mail measurements, or MAILOP commenting on some BGP experiments, even 
though, of course, there are community overlaps).

> His tenure should be pulled. He has a pattern demonstrating ignorance of his 
> field of study.
This is not fine; At least in my personal opinion. It is essentially what I 
talked about in my previous mail when referring to rather frustrated comments 
that do not necessarily take into account that the person on the other end of 
the communication is also a, well, person.
Furthermore, it--again--does not really help in mitigating the underlying 
problem, which is a bit bigger than just one person doing research, but instead 
may even make it worse.
I would usually have this discussion off-list, but given that you posted this 
to the list as well, it might be worthwhile to talk about it somewhat openly, 
as it relates to how we want to interact with each other here.

The reason I believe that comment is not fine is that it rather directly 
attacks Tijay as a person, without considering the context of events. Your 
earlier statements in that context were even a bit stronger. In any case, this 
is certainly not in line with how I would expect a rather senior engineer to 
communicate, especially given that this message may also be read by more junior 
people directly. In the end, we are all shaping the tone in the community.

Specifically, your call for revoking tenure is relatively close to "make that 
person lose their job and prevent them from ever working in that field again". 
This is usually done when people demonstrate significant neglect of ethical 
standards and practices in their _academic field_.* The problem here, though, 
as I mentioned above are those standards and practices (or rather: Especially 
the incentive structures and requirements) in the field, which are just 
incompatible with how the Internet works (and this issue is certainly not 
restricted to mail). So, you are basically putting a lot of (kind of justified) 
frustration at academic research at large into comments towards a single person.

Furthermore, when I think about the impact of one of the measurement studies 
(crashing MXes of smaller ops running off-the-shelf frameworks), I cannot shake 
off the feeling that a reply to one of those operators posting to mailop asking 
for help with the issue (without the measurements having been tied to Tijay) 
could very well have been: "Ah, yeah. Unethical scans. But you should have 
figured that out by yourself. Maybe, if you can't debug something that simple, 
and figure out how to block it, you shouldn't be running mail-servers on the 
Internet. *shrug*" 

Which, I think, illustrates the point about tone I hinted at earlier a bit more.

Instead, I would expect clear, yet respectful, communication that takes the 
underlying problem into account and works towards a solution, making sure that 
the problem does not occur again in the future, independent from the people 
involved, while the people involved are allowed to grow. 

But that may just be me.

With best regards,
Tobias

* 

Re: [mailop] SPF (and other email security protocols) Survey

[Slavko via mailop]

Dňa 23. novembra 2022 14:32:51 UTC používateľ "Taejoong (tijay) Chung via 
mailop"  napísal:


>Yes. As Tobias explained, we can observe certain phenomena (e.g., some mail
>servers look up SPF records more than 100 times) from data, but we don't
>know *why* it happens; we have interviewed around 5~10 mail operators
>individually, which were great but hard to scale, thus we thought that
>survey would be useful. 

Nobody maintaining own mail service will have troubles with limit 10.
My SPF record, for example requires only 1 DNS lookup (record itself),
as it contains only IP addresses.

If someone have problem with that limit (10), he must take into account,
that rising this limit will increase used resources on receiving side and
i have feel, thet they do not care, as count of DNS lookups is not
something, what bother sending side... Consider, that 10 DNS lookups
on 1 000 messages can be 10 000 DNS lookups. And what those
who are receiving millions messages or more?

Sure, plain DNS lookups are cheap, especially with local cache -- until
someone "smart" will not set 60s TTL for these records. And i afraid, that
exactly these, who have problem with current limit, will be "smart". And
with DNSSEC the DNS lookups are not cheap anymore, or more precise
the validation is not cheap.

Anyway, using SPF on shared environment is something, what negates
SPF purpose at all, as anyone from that shared provider can succesfuly
pass SPF for any other domain in it (sharing the same TXT records).
Thus in these shared services is SPF mostly cosmetic or part of
PR/marketing only. Whole result then depends only on that, if particular
provider checks spoofing from own customers, which is a) not published
and b) moves trust to smewhere else.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Taejoong (tijay) Chung via mailop]

My apologies for the late response due to Thanksgiving break (happy
holidays!)

We tried hard not to cause any potential GDPR issues and not to fall into
the human subject research category as Tobias and Laura already explained
(thanks!); for example, we intentionally did not use Google Surveys because
we were not sure if Google Forms are GDPR compliant. (but, SurveyMonkey has
a Data Processing Agreement,
https://www.surveymonkey.com/curiosity/surveymonkey-committed-to-gdpr-compliance/)
and we revised the questionaries with our IRB not to fall into the human
subject research category and not to collect any private information. But
again, we (and IRB) are not perfect. That is why we made all questionnaires
optional (after the first page).

> The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and
should be baked into any code library used by an operator that is doing SPF
validation on inbound mail, so I don't see them facing challenges here.
> On the other hand, staying under the limit of ten for domains publishing
SPF records can be quite a challenge for complex organizations using
multiple services to send their email, and while there are known ways to
skin that cat, there isn't a universally adopted method for doing so.

Thanks for pointing it out – that is why we find that many domains have
many referrals causing many DNS lookups. Our focus is more on the SPF
validation side --- We've been testing many open-source milters, plugins,
libraries, and so on; most of them have 10 or 20 limits. But as SMTP
servers install multiple plugins, libraries, or spam filters, we find that
the actual number of lookups can be amplified. This may cause some security
concerns, which we are investigating now; once our analyses are complete,
we will share the results here.

> Is the survey investigating problems faced by operators doing SPF
validation or operators publishing SPF records or both?

The survey itself is more focused on the operators doing SPF validation.
But I think it would have been better if it also covered the other
perspective as you said :-)

> While we wait for Tijay's reply, let me anticipate that he works on a
> "DNSSECFixer" project, which leverages machine learning techniques to
> automatically fix incorrectly configured and insecure domains.[*]
> As one of the few who took part in the survey, my guess is that it aims
at a
> bird's eye view of email operators' involvement in the configuration of
> security features available in SMTP servers.  Correct?

Yes. As Tobias explained, we can observe certain phenomena (e.g., some mail
servers look up SPF records more than 100 times) from data, but we don't
know *why* it happens; we have interviewed around 5~10 mail operators
individually, which were great but hard to scale, thus we thought that
survey would be useful. So far, thanks to mailop and dnssec communities, I
gained many benefits by doing so --- our team got many help last year from
the mailop community to understand why sometimes deploying/managing DANE is
hard (https://list.mailop.org/private/mailop/2021-June/019414.html and
shared our findings after the survey:
https://list.mailop.org/private/mailop/2021-November/020617.html) or help
from DNS registrars to understand the challenges of deploying DNSSEC.

Thanks again for your help.

Taejoong "Tijay" Chung, Assistant Professor
Virginia Tech  |  Computer Science
Knowledge Works II, RM 2228
2202 Kraft Drive, Blacksburg, VA 24060
(540) 231-0667| ti...@vt.edu




On Wed, Nov 23, 2022 at 7:54 AM Tobias Fiebig  wrote:

> Heho,
> (Excuse the footnotes; But there is a lot of tangential stuff worth
> mentioning, but not necessarily core to the thread.)
>
> Let me weigh in here and provide some context as Tijay listed me as a
> collaborator, and he seems to be a bit delayed in replies. Tijay is a
> Professor at VT, and works on a variety of topics at the intersection of
> security and measurement. This means that he usually supervises students in
> pursuit of their PhD*.
>
> One of the areas a PhD student currently works on is SPF. This started
> with them prodding around and finding that a) The _defined_ limits for SPF
> lookups seem to be impractical (using Bulk ESPs, Salesforce here, marketing
> there,... lots of includes), and b) Some SPF implementations are really not
> good at dealing with _very_ deep SPF trees.
>
> This is, for better or worse, how ideas for research papers usually come
> together in this specific field of research**.
>
> So, what is this research about now: The group found that odd behavior,
> and what you usually do then first is do some measurements. That didn't go
> to well, and shut off a couple of mailserver***, and they are currently
> working really hard at getting that measurement setup robust and in line; I
> am helping there a bit, as we built a similar setup for our mail-delivery
> scans (even though that does no potentially intrusive things, which makes
> stuff a lot easier in terms of consent etc.).
>

Re: [mailop] SPF (and other email security protocols) Survey

[Bill Cole via mailop]

On 2022-11-23 at 07:54:41 UTC-0500 (Wed, 23 Nov 2022 13:54:41 +0100)
Tobias Fiebig via mailop 
is rumored to have said:


Heho,
(Excuse the footnotes; But there is a lot of tangential stuff worth 
mentioning, but not necessarily core to the thread.)


Let me weigh in here and provide some context as Tijay listed me as a 
collaborator,


Do you know why his students have at least twice in the past engaged in 
deceptive spamming to gather data?


Frankly, there's no chance that I'll ever cooperate with that person's 
research. His tenure should be pulled. He has a pattern demonstrating 
ignorance of his field of study.



and he seems to be a bit delayed in replies. Tijay is a Professor at 
VT, and works on a variety of topics at the intersection of security 
and measurement. This means that he usually supervises students in 
pursuit of their PhD*.


One of the areas a PhD student currently works on is SPF. This started 
with them prodding around and finding that a) The _defined_ limits for 
SPF lookups seem to be impractical (using Bulk ESPs, Salesforce here, 
marketing there,... lots of includes), and b) Some SPF implementations 
are really not good at dealing with _very_ deep SPF trees.


This is, for better or worse, how ideas for research papers usually 
come together in this specific field of research**.


So, what is this research about now: The group found that odd 
behavior, and what you usually do then first is do some measurements. 
That didn't go to well, and shut off a couple of mailserver***, and 
they are currently working really hard at getting that measurement 
setup robust and in line; I am helping there a bit, as we built a 
similar setup for our mail-delivery scans (even though that does no 
potentially intrusive things, which makes stuff a lot easier in terms 
of consent etc.).


Anyway, apart from that, to get a scientific exploration of the 
topic, the question also is _why_ did this problem occur in the first 
place. Hence, there is now a survey which asks people (broadly) a) how 
they are implementing SPF/DMARC/TLS-RPT in their setup (software, 
limits), b) demographics about their setup [number of users, domains 
etc.], and whether they are aware of the (TBH, obviously outdated) 
limits from the standards. The survey does not contain mandatory 
fields, and tells people what to expect and that they can quit at any 
time, and can of course also have their incomplete replies (or 
complete replies if they change their mind later on!) deleted.* I 
think Laura also explained _very_ well why this is not 'human subject 
research'; I still see the issue there in terms of the IRB terminology 
(which is often even prescribed in that unhandy way; And IRBs also 
usually have 'limited experience and knowledge' when it comes to 
'Internet things', especially network measurements; But for that, see 
**.)


For the survey and measurements combined, the idea is to then have 
empirical data on how things are implemented (network measurements, 
even though there is ongoing debate on how usable those earlier 
measurements are in a scientific sense), _why_ they are implemented 
that way (technical level; part about tools and implementations in the 
survey), and _if_ and _how_ best practices/RFCs should be amended to 
capture the actual needs of the email ecosystem (second part of the 
survey). That together then can form a publication on the observed 
challenges in SPF/DMARC reporting.


As such, the survey is for everyone involved in Email; There is no 
harm to [the research], if you are not sure if the survey is for you 
and you agree to participate, go through the survey and see if you'd 
be able to provide meaningful input on the questions.


If there are further questions, or you want to further discuss 
individual points, please let me know.


With best regards,
Tobias

* This is also the reason why I'd argue that it might be somewhat good 
if the communication style with researchers tries to keep in mind 
that, in the end, there is a human on the other side. People tend to 
make rather strong and frustratedly sounding statements from time to 
time, but these might be ultimately read by a PhD student, i.e., a 
very junior person. A bit of kindness can go a long way in 
communication, and for me personally is also an important point of 
being an engineer.


** We can have an awful lot of discussions about this, and there is a 
lot going on; Besides the obvious 'is it good or not' and 'is this 
really science?', we essentially deal with 'science' with all its 
incentives (publish or perish); This means trying to do research on 
Internet protocols that have been around for longer than the combined 
age of the PI and PhD in many cases; PhDs fall out of their masters 
before getting into such a topic, and then essentially have a year to 
know all the ins and out of a protocol that grew over the past 40 
years... because after the first year they _should_ basically have 
their first paper under 

Re: [mailop] SPF (and other email security protocols) Survey

[Tobias Fiebig via mailop]

Heho,
(Excuse the footnotes; But there is a lot of tangential stuff worth mentioning, 
but not necessarily core to the thread.)

Let me weigh in here and provide some context as Tijay listed me as a 
collaborator, and he seems to be a bit delayed in replies. Tijay is a Professor 
at VT, and works on a variety of topics at the intersection of security and 
measurement. This means that he usually supervises students in pursuit of their 
PhD*.

One of the areas a PhD student currently works on is SPF. This started with 
them prodding around and finding that a) The _defined_ limits for SPF lookups 
seem to be impractical (using Bulk ESPs, Salesforce here, marketing there,... 
lots of includes), and b) Some SPF implementations are really not good at 
dealing with _very_ deep SPF trees.

This is, for better or worse, how ideas for research papers usually come 
together in this specific field of research**.

So, what is this research about now: The group found that odd behavior, and 
what you usually do then first is do some measurements. That didn't go to well, 
and shut off a couple of mailserver***, and they are currently working really 
hard at getting that measurement setup robust and in line; I am helping there a 
bit, as we built a similar setup for our mail-delivery scans (even though that 
does no potentially intrusive things, which makes stuff a lot easier in terms 
of consent etc.).

Anyway, apart from that, to get a scientific exploration of the topic, the 
question also is _why_ did this problem occur in the first place. Hence, there 
is now a survey which asks people (broadly) a) how they are implementing 
SPF/DMARC/TLS-RPT in their setup (software, limits), b) demographics about 
their setup [number of users, domains etc.], and whether they are aware of the 
(TBH, obviously outdated) limits from the standards. The survey does not 
contain mandatory fields, and tells people what to expect and that they can 
quit at any time, and can of course also have their incomplete replies (or 
complete replies if they change their mind later on!) deleted.* I think 
Laura also explained _very_ well why this is not 'human subject research'; I 
still see the issue there in terms of the IRB terminology (which is often even 
prescribed in that unhandy way; And IRBs also usually have 'limited experience 
and knowledge' when it comes to 'Internet things', especially network 
measurements; But for that, see **.)

For the survey and measurements combined, the idea is to then have empirical 
data on how things are implemented (network measurements, even though there is 
ongoing debate on how usable those earlier measurements are in a scientific 
sense), _why_ they are implemented that way (technical level; part about tools 
and implementations in the survey), and _if_ and _how_ best practices/RFCs 
should be amended to capture the actual needs of the email ecosystem (second 
part of the survey). That together then can form a publication on the observed 
challenges in SPF/DMARC reporting.

As such, the survey is for everyone involved in Email; There is no harm to [the 
research], if you are not sure if the survey is for you and you agree to 
participate, go through the survey and see if you'd be able to provide 
meaningful input on the questions.

If there are further questions, or you want to further discuss individual 
points, please let me know.

With best regards,
Tobias

* This is also the reason why I'd argue that it might be somewhat good if the 
communication style with researchers tries to keep in mind that, in the end, 
there is a human on the other side. People tend to make rather strong and 
frustratedly sounding statements from time to time, but these might be 
ultimately read by a PhD student, i.e., a very junior person. A bit of kindness 
can go a long way in communication, and for me personally is also an important 
point of being an engineer.

** We can have an awful lot of discussions about this, and there is a lot going 
on; Besides the obvious 'is it good or not' and 'is this really science?', we 
essentially deal with 'science' with all its incentives (publish or perish); 
This means trying to do research on Internet protocols that have been around 
for longer than the combined age of the PI and PhD in many cases; PhDs fall out 
of their masters before getting into such a topic, and then essentially have a 
year to know all the ins and out of a protocol that grew over the past 40 
years... because after the first year they _should_ basically have their first 
paper under submission. Certainly people that haven't run their own 
mailserver/authNSes for more than a decade. Yes, recipe for disaster.

Currently, I am actually looking into building an 'AS for Measurement 
Research', especially 'higher level protocols' (mail, DNS,... ) that is open to 
researchers; That should a) have its own ASN, /47, /23, and delegated zones, so 
people can _really_ easily block/filter it, b) Maintain a global 

Re: [mailop] Massive bounce report campaign

[Peter N. M. Hansteen via mailop]

On 11/23/22 10:39, Cyril - ImprovMX via mailop wrote:

I forgot to mention this, but indeed, the first thing we did was contact 
them. We had no response, so we blocked them and later realized that the 
email contact we had was a black hole on their end, so we reached out 
using another email we found and got a response. They are looking into 
it, but I still wonder how we can have what is now 70k connections per 
minute solely from Outlook.


I think you have just described a textbook example of a customer that 
needs to be dropped, urgently.


Your initial description was vague enough that it was almost possible 
that they were just clueless, but their giving you bad contact info 
rules that out. They are *bad actors*, and should be treated accordingly.


If you can extract compensation for the damage they have done, that 
would be a good thing.


If you keep them on as customers, your own reputation will suffer and 
you will likely lose business over this matter.


Please, do the right thing. LART them to the maximum extent possible if 
you can, but stop providing any kind of service to them.


All the best,
Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Laura Atkins via mailop]

This is not normal behavior, either by microsoft or your customer. My advice is 
the same as it was yesterday: terminate the customer. 

Microsoft doesn’t normally send backscatter, so the fact that you’re getting so 
much tells me your customer (y’know, the one who didn’t give you a way to 
contact them when they signed up) is a malicious actor and is preying on you 
and your network.

Get rid of the customer. Their behavior is causing you network problems and 
they won’t fix it (by pointing the MXs at a host that can handle the volume). 
There is zero reason to keep them. 

laura 



> On 23 Nov 2022, at 09:39, Cyril - ImprovMX via mailop  
> wrote:
> 
> Thank you, everyone, for your response. My timezone differs from yours, so 
> I'm only replying now.
> 
> I forgot to mention this, but indeed, the first thing we did was contact 
> them. We had no response, so we blocked them and later realized that the 
> email contact we had was a black hole on their end, so we reached out using 
> another email we found and got a response. They are looking into it, but I 
> still wonder how we can have what is now 70k connections per minute solely 
> from Outlook.
> 
> Blocking the recipient had the effect that we don't accept emails for them 
> anymore, so anyone sending an email via ImprovMX to one of their domain will 
> have a 5xx response on the RCPT command.
> That was our initial strategy, the default when we block an account: we let 
> the sender know the email wasn't accepted.
> 
> But in this case, I realized one thing: It's possible that the sender could 
> retry, increasing the number of connections at every new bounce. So I've 
> updated the policy on this specific account to accept but silently drop any 
> emails for them.
> 
> I was also able to get a hold of a few emails we received. The bounce reports 
> don't contain the original body, but the errors I got are mostly "access 
> denied AS(201806281)" with a few "address not found".
> 
> I suspect the original sender, using the mail provider, is sending a massive 
> campaign using a very bad list of recipients that got the mail provider 
> flagged and got their email rejected.
> 
> I was hoping there was an easy fix we could implement on our end that would 
> tell Outlook to stop connecting, but I'm pretty sure someone here would have 
> shared it if that was the case.
> 
> We now need to hope that they'll be helpful in resolving the issue.
> 
> Thank you all again for your message and help, and if you have any 
> suggestions we can implement or do better, I'm all ears!
> 
> Best regards,
> Cyril
> 
> Le mar. 22 nov. 2022 à 19:08, Jarland Donnell via mailop  > a écrit :
> I would block the recipient domains at the MTA level and cut out the IP 
> rate limiting for a while. An MTA should be able to handle the rejection 
> for the domain fine. I do the same with exim when a user tries to give 
> me the job of mass forwarding bounces, I just won't do it. In my mind a 
> flood of bounces means bad behavior and I justiy the block by refusal to 
> participate in whatever it is they're doing.
> 
> I don't think you're crazy here at all, if half of your job suddenly 
> becomes forwarding bounce emails that's just not a good look.
> 
> On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote:
> > Hi!
> > 
> > I would appreciate your help on a bad issue we are having.
> > 
> > We are facing a very large amount of connections from Outlook, in the
> > order of 50k connections per minute (whereas the second "most active"
> > server is at 100).
> > 
> > Upon investigation, we discovered that one of our users is a
> > mass-sending email service (such as Mailgun; it seems legit in
> > itself), and they created one domain per client to handle bounce
> > reports, such as sp-bounce.{client's domain}.
> > 
> > Since the MX of these domains points to our server, any bounce report
> > sent is sent to our server. (Our service is a forwarding email, so
> > once we get the email, we forward it to the above user). (I'll add a
> > comment on this right after)
> > 
> > The problem is that I don't see how we can stop Outlook from sending
> > all these bounce reports to us. I thought about updating the SPF to
> > block that sender from including us, but we don't manage their DNS.
> > 
> > Right now, what we've done is to stop accepting connections from a
> > sender (in this case, Outlook) after an abnormal amount of connections
> > per a given period, but this doesn't avoid the fact that Outlook still
> > tries to connect to us massively, and also impact our regular users
> > that receive emails from Outlook sender legitimately.
> > 
> > What I'm hoping by reaching out to you is to hope someone has already
> > faced something similar and has some suggestions on how to mitigate -
> > or ideally block - this.
> > 
> > This could be a pretty well DDoS attack done by mail servers.
> > 
> > On the comment above regarding the bounce report being sent: That is
> > 

Re: [mailop] SPF (and other email security protocols) Survey

[Alessandro Vesely via mailop]

On Tue 22/Nov/2022 16:41:44 +0100 Todd Herr via mailop wrote:

On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop wrote:


The Sender Policy Framework (SPF) is an easy way to check whether the
sender is authorized to send emails – however, it may cause some security
holes if it causes too many DNS lookups.

Together with researchers from Virginia Tech and Max-Planck-Institut für
Informatik, we would like to understand which challenges operators face
when configuring the proper limit of DNS queries for SPF lookups and when
deploying other email security protocols.


I'm not quite sure I understand the premise behind the survey, and since I
don't manage email for any domain, I can't realistically take part in the
survey to learn the premise, so I'll try here.

The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and
*should* be baked into any code library used by an operator that is doing
SPF validation on inbound mail, so I don't see them facing challenges here.



On my MTA the (default) limit is 20.  That looks consistent with Postel's 
principle.




On the other hand, staying under the limit of ten for domains publishing
SPF records can be quite a challenge for complex organizations using
multiple services to send their email, and while there are known ways to
skin that cat, there isn't a universally adopted method for doing so.

Is the survey investigating problems faced by operators doing SPF
validation or operators publishing SPF records or both?



While we wait for Tijay's reply, let me anticipate that he works on a 
"DNSSECFixer" project, which leverages machine learning techniques to 
automatically fix incorrectly configured and insecure domains.[*]


As one of the few who took part in the survey, my guess is that it aims at a 
bird's eye view of email operators' involvement in the configuration of 
security features available in SMTP servers.  Correct?


As the survey asks for the domain name where such features are configured, I 
understand that that might sound as intelligence gathering for a targeted 
attack.  However, I don't reckon the survey collects any sensitive data.



Best
Ale
--

[*] https://cs.vt.edu/research/research-areas/security.html






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

Re: [mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

Thank you, everyone, for your response. My timezone differs from yours, so
I'm only replying now.

I forgot to mention this, but indeed, the first thing we did was contact
them. We had no response, so we blocked them and later realized that the
email contact we had was a black hole on their end, so we reached out using
another email we found and got a response. They are looking into it, but I
still wonder how we can have what is now 70k connections per minute solely
from Outlook.

Blocking the recipient had the effect that we don't accept emails for them
anymore, so anyone sending an email via ImprovMX to one of their domain
will have a 5xx response on the RCPT command.
That was our initial strategy, the default when we block an account: we let
the sender know the email wasn't accepted.

But in this case, I realized one thing: It's possible that the sender could
retry, increasing the number of connections at every new bounce. So I've
updated the policy on this specific account to accept but silently drop any
emails for them.

I was also able to get a hold of a few emails we received. The bounce
reports don't contain the original body, but the errors I got are mostly
"access denied AS(201806281)" with a few "address not found".

I suspect the original sender, using the mail provider, is sending a
massive campaign using a very bad list of recipients that got the mail
provider flagged and got their email rejected.

I was hoping there was an easy fix we could implement on our end that would
tell Outlook to stop connecting, but I'm pretty sure someone here would
have shared it if that was the case.

We now need to hope that they'll be helpful in resolving the issue.

Thank you all again for your message and help, and if you have any
suggestions we can implement or do better, I'm all ears!

Best regards,
Cyril

Le mar. 22 nov. 2022 à 19:08, Jarland Donnell via mailop 
a écrit :

> I would block the recipient domains at the MTA level and cut out the IP
> rate limiting for a while. An MTA should be able to handle the rejection
> for the domain fine. I do the same with exim when a user tries to give
> me the job of mass forwarding bounces, I just won't do it. In my mind a
> flood of bounces means bad behavior and I justiy the block by refusal to
> participate in whatever it is they're doing.
>
> I don't think you're crazy here at all, if half of your job suddenly
> becomes forwarding bounce emails that's just not a good look.
>
> On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote:
> > Hi!
> >
> > I would appreciate your help on a bad issue we are having.
> >
> > We are facing a very large amount of connections from Outlook, in the
> > order of 50k connections per minute (whereas the second "most active"
> > server is at 100).
> >
> > Upon investigation, we discovered that one of our users is a
> > mass-sending email service (such as Mailgun; it seems legit in
> > itself), and they created one domain per client to handle bounce
> > reports, such as sp-bounce.{client's domain}.
> >
> > Since the MX of these domains points to our server, any bounce report
> > sent is sent to our server. (Our service is a forwarding email, so
> > once we get the email, we forward it to the above user). (I'll add a
> > comment on this right after)
> >
> > The problem is that I don't see how we can stop Outlook from sending
> > all these bounce reports to us. I thought about updating the SPF to
> > block that sender from including us, but we don't manage their DNS.
> >
> > Right now, what we've done is to stop accepting connections from a
> > sender (in this case, Outlook) after an abnormal amount of connections
> > per a given period, but this doesn't avoid the fact that Outlook still
> > tries to connect to us massively, and also impact our regular users
> > that receive emails from Outlook sender legitimately.
> >
> > What I'm hoping by reaching out to you is to hope someone has already
> > faced something similar and has some suggestions on how to mitigate -
> > or ideally block - this.
> >
> > This could be a pretty well DDoS attack done by mail servers.
> >
> > On the comment above regarding the bounce report being sent: That is
> > my suspicion, by looking at the domain names (sp-bounce), the email it
> > receives, and the sender activity. But maybe there is another logical
> > explanation I'm missing!
> > I mean, to have 50k connections per minute to deliver bounce reports
> > means that the running campaign must be in the order of millions of
> > emails just for Outlook!
> >
> > All help is deeply appreciated!!!
> >
> > Thank you all in advance.
> >
> > Best regards,
> > Cyril
> > ___
> > 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 mailing list