The mailing list for listmasters using Sympa

[Matt Taggart <address@concealed>]

"Roger B.A. Klorese" writes:
> It feels like you assume that Sympa will be used in a circumstance in 
> which the organization that implements Sympa also implements the email 
> infrastructure, or at least, where the users of Sympa have some control 
> over the email environment. And that is certainly what educational 
> environments often look like, and, for that matter, what many corporate 
> settings do as well.
> 
> But it doesn't work at all for organizations that are hosting lists and 
> that have no relationship at all to the user-side email infrastructure, 
> like a dedicated list-hosting provider. When our client organizations 
> look at us, they expect us to be compatible with their email 
> environments, not the other way around.

While riseup also hosts email, the vast majority of our list subscribers 
(99.33% currently) use addresses with other providers.

We have seen a few complaints from users in the past about sympa password 
reset URLs already being used and we just assumed that probably the user 
had clicked on it twice. But an anti-malware tool preloading the link would 
definitely explain it as well.

I'm opposed to anti-malware tools doing this sort of thing in the interest 
of "protecting" users. In addition to messing up one time tickets and the 
problems David mentioned it also causes an http request to happen possibly 
when the user doesn't want it to, which could leak the user's real IP. This 
is a concern for many of our users who go to great pains using tor/VPNs in 
order to stay anonymous on the internet.

Tangent.. I once ran into another case of an anti-malware tool overstepping 
it's bounds in in the interest of "protecting" the user. A well known 
anti-virus tool was transparently intercepting SMTP sessions from a desktop 
mail client and during the transaction setup was silently dropping the 
STARTTLS advertisement from the server, in an attempt to force the session 
to unencrypted. I'm guessing the tool was trying to detect if the computer 
had become infected and was sending out spam, and encryption would 
interfere with that.... It took running a by hand SMTP session on the 
client machine to figure out what was going on.

While making the one time tickets have some additional verification step 
would solve this minor corner case, I'm opposed to software working around 
broken anti-malware tools and I think David's position is the correct one.

-- 
Matt Taggart
address@concealed