Hello Paul,
On Wed, 2024-08-07 at 23:37 +0000, Paul Gregg via mailop wrote:
> On Wed, Aug 07, 2024 at 11:35:10PM +0200, Tobias Fiebig via mailop
> wrote:
> > [...]
>
> That was not my intent. It was to suggest a way for some mails to
> make it through.
>
> [snip]
Please note the list of my suggestions to a similar goal falling into
'[snip]' here.
> Perhaps not that - but certainly encouraging them to open a Support
> case to ensure their settings are correct.
>
> [...]
> Proofpoint provides guidance, documentation, setup guides,
> professional services, etc to help customers correctly configure
> their systems. But not all do. We can't force them.
The above '[snip]'-ed content specifically outlined where Proofpoint
could actually do a lot more (by actually not having to do _that_
much).
> Most of this mailing list is "I'm having issues delivering to ...",
> while seeking a contact that might be able to help (this thread being
> the same). Usually someone has misconfigured something somewhere.
Yes. Well. With a bit of a nuance: _I_ actually _do_ get my mail
delivered; To Proofpoint, and to Google directly, if someone hosts
there. It is _Proofpoint_ who has delivery issues to Google.
> At PP we absolutely want customers to have correct configurations and
> to receive mail - it doesn't do us any good to block legit senders.
Again, Proofpoint is not blocking anything here. Proofpoint is
_breaking_ things; If this was an intentional _block_ decision, that
would be a (somewhat) different case.
> [...] The best/only way for anyone to get PP to do anything is to
> have the Customer open a Support case.
This carries the same perspective again, which I personally find 'a bit
difficult':
Proofpoint is handing out sharp knifes to their customers. When these
keep running around, generally, it is Proofpoint's job to make them
stop; Not the one of the people who are concerned about the amount
of Band-Aids they have to hand out. Similarly, 'hand out more Band-
Aids'
is not really something that might trigger a lot of enthusiasm.
More specifically, Proofpoint is selling a product that can have
_serious_ consequences for a company using it; This includes the
delivery issues, as well as that the urldefense (and similar products
of competitors) mechanism is fundamentally GDPR incompliant/a
sure-shot way to create "mandated reporting incidents" under the GDPR.*
Proofpoint has the deliverability issue. Proofpoint needs to fix
its stuff. And I am _pretty_ sure that (regardless of our conversation)
Proofpoint (That is: The responsible POs / engineers) _already_
know. There is just a business decision to not address this; And, to
be fair, I can fully and with no irony see how that decision can be
reached, and acknowledge that--given general industry constraints--
it is reasonable given the context.
I just don't believe that it is reasonable in the context of 'building
a well working global email infrastructure'.
With best regards,
Tobias
* I do recon that a claim like 'this product is fundamentally GDPR
incompliant' may 'raise some eyebrows'; Hence, allow me to elaborate
(Disclaimer: Not a lawyer, just speaking as a security & privacy
researcher):
The urldefense mechanism adds additional tracking information to links.
These usually include, iirc, an identifier for the Org and specific
mailbox the link was sent to;
This, generally, makes sense: It is essential to track, e.g., phishing
links being sent--ideally across several clients. It is the core of
the value proposition.
Naturally, it also implies that there is a certain amount of data
collection associated with these links--it is hard to believe that
there are no logs on the webcluster handling these URIs, and even
harder to believe that a threat intel system would pass up on that
information voluntarily.
Usually, this is also not a problem processing wise: The users
clicking on these links are employees of the customer after all;
Privacy issues covered by contractual relation.
The issue occurs if an employee/user of a PP client forwards such
a mail, or, even worse, copies content--often not even being aware
of the urldefense URL being included, e.g., when dealing with an
HTML email.
In that case, all of a sudden, the client sends a tracking link to
its contacts with all the related implications. Furthermore, as--
likely--proofpoint also uses the collected data for its own purposes,
e.g., when processing URI accesses to identify larger attacks,
regardless of whether a _specific_ URI or accesses to those is
finally determined to be malicious and is, e.g., processed further,
PP becomes a data processor under the GDPR as well.
There are additional bonus points to get if multiple orgs using
different URI protection services are involved, leading to, e.g.,
a Proofpoint Urldefense URL being rewritten by Outlook Protection,
leading to a multi layer forward. I took the liberty of attaching
a public (yet older) example of such, sent to +- 1000 people.
(Note: The Slack workspace link in the attached mail is the
double-rewrite. The inclusion of the rewrite links happened as
the user received an HTML template for the mail from someone else,
and copied it into the mail. The Slack link was received by someone
at another org using PP and then forwarded to the sender, who then
copied it into the mail template, leading to the double-rewrite
for that specific link.)
The absence of the urldefense targets in the other links also
demonstrates that this is not a forwarding issue, but occurs
when users recompose mails; Copy-pasting things together, not
actually seeing the links being send; Which is what users simply
_do_; They are just doing their jobs.
Related, btw: How long does proofpoint keep those urldefense
links around after the business relationship to a client ended?
The link still works, but I know that the Org responsible for
the proofpoint target in the Slack link no longer uses PP;
Note, though, that this former PP client is _not_ uva.nl, i.e.,
not the org of the email sender.
Funnily enough I once had the opportunity to discuss all of
this with a PP privacy person at a previous affiliation. The
conclusion there was that, indeed, this issue makes PP fundamentally
incompatible with the GDPR, if contents of mails are either
copy-pasted or forwarded to external parties without making them
aware of the data collection/processing by proofpoint (or others).
--- Begin Message ---
Dear attendee
Many thanks for having registered for ACM SIGCOMM'22! As we're gearing up for
the conference, we wanted to share some logistical information with you.
General info & Slack:
Information regarding the conference and its program is available and will be
kept up-to-date via our website
https://conferences.sigcomm.org/sigcomm/2022/<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconferences.sigcomm.org%2Fsigcomm%2F2022%2F&data=05%7C01%7Cp.grosso%40uva.nl%7Cc8d375f8c0ee42d48a3c08da835875b9%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C637966713214013713%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DbxHyL5LLUeX2MEqkxzteAWSfTeQeevAzcjuV5LNzJc%3D&reserved=0>
and the various Slack channels, see
https://conferences.sigcomm.org/sigcomm/2022/online-participation.html<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconferences.sigcomm.org%2Fsigcomm%2F2022%2Fonline-participation.html&data=05%7C01%7Cp.grosso%40uva.nl%7Cc8d375f8c0ee42d48a3c08da835875b9%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C637966713214013713%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1eNNBA8qRO91lvyzZXW7dIFN5WQBM2jKxngvMmRC5GE%3D&reserved=0>.
We encourage participants to review these and selectively join the Slack
channels of interest. If you're not already a member of the SIGCOMM Slack
Workspace, you can join
here<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fjoin.slack.com%2Ft%2Fsigcomm%2Fshared_invite%2Fzt-1eerhl2x2-ubF4Bnc0uRXT8eNOUetGpQ__%3B!!PAKc-5URQlI!4v-7Er7iw_VoCliZnmJtR7AjOV7BZw5vSNvAebOUvVuExNfojMvMu0Rz21H-aDNnUZwe9BhREYvt9oEbwn9ugwag%24&data=05%7C01%7Cp.grosso%40uva.nl%7Cc8d375f8c0ee42d48a3c08da835875b9%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C637966713214169932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I9zFmaQ%2FIYULakEWxaP5SIiSGcNozVF8610jsee6okM%3D&reserved=0>.
These channels can be used by both remote and physical participants and will
hopefully serve as a useful medium to link people up!
Historic venue:
The conference venue, called Beurs van Berlage, is a national monument built in
1903 by the famous Dutch architect Hendrik Berlage. If you keep an eye out for
it, you will spot many artistic details throughout the building.
Rooms:
Our program details the locations for the sessions and events. There will be
signage at the venue to direct you to the various rooms. You may also consult
https://beursvanberlage.com/amsterdam-conference-centre/rooms-overview/<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbeursvanberlage.com%2Famsterdam-conference-centre%2Frooms-overview%2F&data=05%7C01%7Cp.grosso%40uva.nl%7Cc8d375f8c0ee42d48a3c08da835875b9%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C637966713214169932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4BK9UWBlwuJ6yYXWS4fiPgG%2BGjd3pmfLvpavlh2FAWM%3D&reserved=0>
for an overview of those rooms. Please note that food and beverages are not
allowed within the room called "Berlage zaal". This is because it contains an
ancient carpet (as old as the building itself). We have prepared a room that
can be used for praying. If you'd like to make use of that, please contact the
staff/volunteers.
Volunteers:
We have 10 student volunteers helping us and you to make SIGCOMM'22 a memorable
event. They are wearing orange (our national color) lanyards, so you can more
easily spot them. If you have any questions, feel free to approach them and/or
us.
Covid measures:
At present, there are no Covid restrictions enforced within the Netherlands.
Nonetheless, we offer a number of measures. The venue itself is
well-ventilated. Wearing of masks is not mandatory, yet you are welcome to
choose to do so (one conference mask will be provided). There are also numerous
disinfection stations throughout the building. Furthermore, we have COVID
self-tests at your disposal. Please do not enter the event if you feel unwell.
If you happen to develop symptoms during the day, you can make use of a
dedicated room to administer a self-test. Finally, although seating is not 1.5m
apart, we have placed ~100 more chairs than attendees in the main conference
room (Effectenbeurszaal).
Streaming and recording:
As a reminder, and as stated in the registration form, the sessions of the main
conference (in the (Effectenbeurszaal) will be live streamed and recorded.
Wifi codes:
- At the conference venue the SSID is ACMSIGCOMM and the password is
@Amsterdam2022!
- At the banquet venue the SSID is ACMSIGCOMM and the password is Banquet2022
Registration and badges:
The venue opens daily at 08:30 with a welcome reception after which the program
starts at 09:00. Since registration takes time, we ask that you plan your
arrival and registration accordingly. Also, please clearly wear your badges
during/throughout the conference and its social events, as they are used for
"admission control".
Food & beverage:
The venue will clearly indicate which food is appropriate for which allergies
or dietary constraints, e.g. vegetarian, gluten-free, etc. When in doubt,
please ask the venue's staff.
Reception:
Don't forget that the main conference already starts with a reception on Monday
at 6 pm!
Banquet:
The banquet on Wed. offers a reception with drinks and appetizers and some
entertainment from 6:30 till 7:30 pm, and will be followed by dinner till 10:00
pm. It is possible to walk there from the venue (in 15-20 min.). For
directions, see
https://www.muziekgebouw.nl/pQ32vSv/muziekgebouw/english#<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.muziekgebouw.nl%2FpQ32vSv%2Fmuziekgebouw%2Fenglish%23&data=05%7C01%7Cp.grosso%40uva.nl%7Cc8d375f8c0ee42d48a3c08da835875b9%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C637966713214169932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qOW0uzA2EUkH7DHMvuP5SAsgf6NPiDh3lRnwJ9bY9Zc%3D&reserved=0>.
Best regards,
Paola Grosso, local organization chair, on behalf of the entire SIGCOMM'22 team
--- End Message ---
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
