3 ms·
I've never really understood how this 'urls via our own redirector' really works, if at all. I can imagine some reasons why it would work better than merely ch
by berkes 2y ago
I've never really understood how this 'urls via our own redirector' really works, if at all.
I can imagine some reasons why it would work better than merely checking the URLs when filtering: not rewriting but simply checking and scoring against other spam rules. But also see reasons why it secures less well.
Pro: you can block URLs post-delivery. E.g. an advisary changes the link to malware or phishing after some time/n requests/based on user agent.
Con: all encryption, including DKIM, GPG etc break.
Edit: to clarify why I don't understand why this works: and advisary can still do the same: i.e. serve an innocent page to the checker but then a bad webpage to the actual visitor. Not trivial, but not hard either.
A good middle ground might be to scan URLs on the mailserver against lists and maybe open the page and scan its content before delivering.
Then have the client intercept links and redirect them through another on-demand checker?
Because obviously, training people to "not click links in emails" or use only plain text or both, hasn't worked in the last decades.
- Maxion 2y agoThe most funny filters are those that visit the URL to check what it is. Those break all the magic login links, email verification links et. al. that people receive. Really can't understand who approved such things.
- rileymat2 2y agoIn theory, magic links that are only GET and not idempotent are the issue, not the systems/filters hitting them.
- spiffytech 2y agoThis is one of the reasons to adopt magic codes instead of magic links.
- tomschlick 2y agoOr just have your magic link include a "Confirm Login" button once it loads that sends a POST so automated clients don't cause issues.
- berkes 2y ago... potentially enriched with JS that hides that button and does a POST for you on documentLoad or such. That way, for a "normal human" it works like they expect, is technically correct, and doesn't trigger on backends fetching the resource. Unless they fetch the resource with some headless chrome or such. Which, unfortunately, is rather necessary these days.
- zinekeller 2y ago> ... potentially enriched with JS that hides that button and does a POST for you on documentLoad or such. Don't do this, most bots now actually load JavaScript.
- zinekeller 2y agoYeah, these filtering appliances/services have many, many misgivings but this one is obviously just following the spec that just happens to be violated by "magic" (not really) links (and not to metion breaking in iOS and other systems which preview them, the futility of trying to ignore robots etc.). You simply know that the designers of the service don't have any real-life testing (and often are snobbish, to boot) if "magic" links are mandatory.
- j45 2y agoMagic links/codes are a security compromise on their own. Still, corporate email belongs to the employer. For "magic links", It doesn't solve the problem that the email is intended for a specific individual, for one time use, and the filters are not aware or intelligent enough to do so. In other cases privacy and security of the communication in some cases is being compromised. It does give rise to a bootstrapped solution that delivers links well so I guess that's good.
- megous 2y agoGET request should not change any substantial state. You're up for a lot of fun if you decide to violate that as a web developer.
- pvillano 2y agoTBT that guy that used a GET to open his garage door and found it randomly opening from pre-fetches(!)