reject mixed-separator path traversal in imap attachment names

[Samin061]

_is_escaping_current_directory in the imap hook rejects a traversing attachment name with f"..{os.sep}" in name, which is tied to the host separator. On Windows os.sep is a backslash but a forward slash is also a valid path separator, so an attachment named ../../evil slips past the check and, once joined onto the output directory in _correct_path, resolves outside it, letting whoever sent the mail write an arbitrary file. This normalises both separators and rejects any .. path component instead.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information.

[potiuk]

Good fix. Tying the check to os.sep meant that on Windows, where / is equally valid as a separator, ../../evil walked straight past the guard — and attachment names come from email, so that input is attacker-controlled whenever the mailbox receives external mail.

The revision addresses the earlier review point properly: using os.sep plus os.altsep keeps backslashes as ordinary characters on POSIX while catching both separators on Windows, and the two parametrized tests lock that platform difference in. ("..\\..\\test1.csv", False) on POSIX is exactly the case worth pinning.

I checked the obvious follow-on question — absolute names like /etc/passwd — and they are covered, though somewhat by accident: _correct_path concatenates strings rather than using os.path.join, so an absolute name becomes /out//etc/passwd and stays inside the directory. Worth knowing that this is load-bearing, since switching that concatenation to os.path.join later would reintroduce an escape that this check does not cover.

Splitting on components also catches a bare .. that the old substring test missed, which is a nice bonus even though it isn't exploitable on its own.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting