-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extra space in urldefense v3 #10
Comments
Thanks for the issue! I have noticed the extra space in demangled URLs and from a couple emails I've checked, I've verified that in some cases there is an extra space inserted in emails that use The extra space does not seem to be an issue with emails that are Base64-encoded or of Content-Type Two cases I've seen so far:
(There are probably additional variants to these.) Given that context, because the decoder does not process URLs (or emails) in their I think handling case (1) (which is much more noticeable) in a general way will require some careful thought, because it's not clear to me how to delimit a URL surrounded by angle brackets ( Thus, for now, I don't have a good fix for this issue, but I'll happily consider your (or anyone else's) suggestions if you have one. |
Thank you very much for looking into this small issue! I understand that a cure could easily be worse than the disease, and anyway this is a bug of urldefense, not of your decoder. I could add an ugly hack to my pipeline (for example something like |
When decoding emails with URLs mangled with urldefense v3, there is a little glitch: urldefense seems to add always a space after the URL, but this space is kept by
decode_email.py
. For example, if someone sends an email with<https://example.com>
, the decoded email will have<https://example.com >
. This is not absolutely a big deal, but perhaps the solution is easy enough.Thank you very much for this very useful piece of software!
The text was updated successfully, but these errors were encountered: