Comment 22 for bug 2023971
Revision history for this message
| Miriam España Acebal (mirespace) wrote | #22 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Hi Miha,
First of all, thanks for your work on this Miha.
You've summarized it very well and you're right that moving in a different direction than upstream always involves more delicate work in the future. Upstream's discussion is ongoing [1], and we don't know the decision they could make even if we (I) provide as fast as possible what they need to take it:
- specific tests
- data (that we have from this MIR study already)
- Extending the patch: completely switching even from libemail-
- and as extra and beyond: making/checking it is compliant with latest RFC DMARC/DMARCbisfor, making our proposal more robust (although it is out-of-scope of the original PR) [1.1]
since for the moment they don't find a compelling reason to change the dependency [1.2] because:
- the security issue is solved [2] (as you rightly point out too)
- they are perfectly within their rights that our main/universe distinctions are not a priority for them.
Coming back to the Requires TODO for ACK in the MIR review of libemail-mime-perl [3], the #0 is that libemail-mime-perl passes the security review: Would that package be reviewed by security to see if we can go back to it? The security review (SEC-2671) was blocked and later rejected due to the switching to libmime-tools-perl.
I have no objection to reverting back to libemail-mime-perl if:
- The libemail-mime-perl security review (SEC-2671) passes with an ACK/OK.
- TODO #2 (duplicity) can be overcome.
Thank you in advance!
[1] https:/
[1.1] https:/
[1.2] https:/
[2] https:/
[3] https:/