Public bug reported:
If the list has no subject_prefix, DMARC Wrap Message will not include
the Subject: in the wrapped message.
** Affects: mailman
Importance: High
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1915655
Title:
DMARC Wrap Message doesn't include Subject: in the wrapper.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1915655/+subscriptions
*** This bug is a security vulnerability ***
Private security bug reported:
A URL with a very long text listname such as
https://homewalkers.net/mailman/roster/This_is_a_long_string_with_some_phis…
will echo the text in the "No such list" error response. This can be used to make a potential victim think the phishing text comes from a trusted site.
This issue was discovered by Abderrahmane Sahnoun <x.virusdz0(a)gmail.com>.
same as CVE-2018-13796
** Affects: mailman
Importance: Undecided
Assignee: Abderrahmane Sahnoun (xvirusdz)
Status: New
** Changed in: mailman
Assignee: (unassigned) => Abderrahmane Sahnoun (xvirusdz)
** Description changed:
hi team,
im Abderrahmane Sahnoun Algerian Security Researcher when i was exploring your website i have found a bug witch done the possibility to A crafted URL can cause arbitrary text to be displayed on a web page from a trusted site in GNU Mailman 2.1.33.
it's the same like CVE-2018-13796
here a example of it:
- https://homewalkers.net/mailman/roster/wassim
+ https://homewalkers.net/mailman/roster/type_any_thing_here
I await your reply at the earliest time
Sincerely;
** Description changed:
- hi team,
- im Abderrahmane Sahnoun Algerian Security Researcher when i was exploring your website i have found a bug witch done the possibility to A crafted URL can cause arbitrary text to be displayed on a web page from a trusted site in GNU Mailman 2.1.33.
- it's the same like CVE-2018-13796
- here a example of it:
- https://homewalkers.net/mailman/roster/type_any_thing_here
- I await your reply at the earliest time
- Sincerely;
+ A URL with a very long text listname such as
+ https://homewalkers.net/mailman/roster/This_is_a_long_string_with_some_phis…
+ will echo the text in the "No such list" error response. This can be used to make a potential victim think the phishing text comes from a trusted site.
+
+ This issue was discovered by Abderrahmane Sahnoun
+ <x.virusdz0(a)gmail.com>.
** Changed in: mailman
Assignee: Abderrahmane Sahnoun (xvirusdz) => (unassigned)
** Description changed:
A URL with a very long text listname such as
https://homewalkers.net/mailman/roster/This_is_a_long_string_with_some_phis…
will echo the text in the "No such list" error response. This can be used to make a potential victim think the phishing text comes from a trusted site.
- This issue was discovered by Abderrahmane Sahnoun
- <x.virusdz0(a)gmail.com>.
+ This issue was discovered by Abderrahmane Sahnoun <x.virusdz0(a)gmail.com>.
+ same as CVE-2018-13796
** Changed in: mailman
Assignee: (unassigned) => Abderrahmane Sahnoun (xvirusdz)
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1913241
Title:
A crafted URL can cause arbitrary text to be displayed on a web page
from a trusted site.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1913241/+subscriptions
Public bug reported:
If the recipient mail address is too long, local part of VERP sender may
exceed 64 octet, the maximum total length of local-part provided by RFC
5321.
I think it should be checked in Mailman/Hander/SMTPDirect.py and fall
back to original envsender.
e.g. (not tested yet)
--- Mailman/Handlers/SMTPDirect.py.org 2018-06-27 17:19:15.000000000 +0900
+++ Mailman/Handlers/SMTPDirect.py 2020-11-27 22:06:44.047857879 +0900
@@ -338,7 +338,14 @@ def verpdeliver(mlist, msg, msgdata, env
'mailbox': rmailbox,
'host' : DOT.join(rdomain),
}
- envsender = '%s@%s' % ((mm_cfg.VERP_FORMAT % d), DOT.join(bdomain))
+ envlocal = (mm_cfg.VERP_FORMAT % d)
+ if len(envlocal) > 64:
+ syslog('smtp',
+ 'local part of VERP address exceeds 64 octet.'
+ 'fall back to original envsender: %s',
+ envlocal)
+ else:
+ envsender = '%s@%s' % (envlocal, DOT.join(bdomain))
if mlist.personalize == 2:
# When fully personalizing, we want the To address to point to the
# recipient, not to the mailing list
** Affects: mailman
Importance: Undecided
Status: New
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1905962
Title:
local-part of VERP sender may exceed 64 octet
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1905962/+subscriptions
Public bug reported:
Please note this is not a bug but just a kind enhancement request.
In GNU Mailman version 2.1.24 (I seem) You closed bug #1694384 which, among other things, asked for
not exposing the list administrator(s) personal email address(es) in the page footer.
While I appreciate this new default, in general, in small environment I would find it useful if
users could still individually identify the persons who are directly responsible for a project,
with no harm for their privacy and/or workflow related problems.
Therefore I would like the default behavior could be changed by means of a specific option (global
and/or per list) for exposing the list administrators' addresses instead of the generic list
owner's address.
Would you please consider adding it?
Thank you very much
** Affects: mailman
Importance: Undecided
Status: New
** Tags: enhancement footer list-owner privacy
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1902231
Title:
Enhancement: optionally expose list owners' addresses
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1902231/+subscriptions
Public bug reported:
Setting localhost in postfix_lmtp works against Postfix defaults and
breaks delivery.
Reason: The Postfix lmtp client only uses dns queries by default to
search for hostnames. If the DNS server does not provide an answer for
"localhost" delivery from the lmtp client to mailman fails.
Solution: Provide "127.0.0.1" instead of "localhost". This does not
require DNS and is even faster because it saves DNS lookups.
Example:
hey2(a)mailman.state-of-mind.de
lmtp:[localhost.localdomain]:8024
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 3.0 mailman
--
setting localhost in postfix_lmtp breaks delivery
https://bugs.launchpad.net/bugs/544477
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
dnspython >=2.0 requires Python >=3.6 and won't work with Mailman 2.1.
./configure should check for dnspython <2.0 and mention this requirement
of not found.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1895451
Title:
Mailman 2.1 does not support dnspython >=2.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1895451/+subscriptions
Jouni K. Seppänen has proposed merging lp:~jks/mailman/hcaptcha into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~jks/mailman/hcaptcha/+merge/389691
I noticed that a Mailman 2.1 site I run was being used for sending subscribe confirmation messages to people. I didn't want to implement reCaptcha because of privacy concerns, and hCaptcha seems to be almost a drop-in replacement that at least promises to respect user privacy. This change allows using hCaptcha instead of reCaptcha for guarding the subscription form.
When testing, the dummy keys from https://docs.hcaptcha.com/#localdev may be useful:
Dummy Site Key:10000000-ffff-ffff-ffff-000000000001
Dummy Secret Key:0x0000000000000000000000000000000000000000
--
Your team Mailman Coders is requested to review the proposed merge of lp:~jks/mailman/hcaptcha into lp:mailman/2.1.
Public bug reported:
When browsing the archive in "threaded" view, conversation are threaded.
But after 4 levels of depth, they are all stack at the same level. This
makes it hard to browse long-running discussions, as everything appears
to be on the same level. That limit appears to be hard-coded.
It would be nice to have a setting to be able to increase that limit.
** Affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1889271
Title:
Add option for web archive conversation indentation level
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1889271/+subscriptions
Public bug reported:
This was fixed in Mailman 2.1.30 by using .bin for the extension, but a
bug report was never created.
The issue prior to 2.1.30 was a scrubbed attachment with no extion in
it's name would be saved with a .obj extension and some web servers and
or browsers would not recognize the .obj extension and possibly serve
evil javascript as html.
For more info see https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2020-12137
** Affects: mailman
Importance: Medium
Status: Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-12137
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1886117
Title:
Scrubbed application/octet-stream parts should not have .obj extension
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1886117/+subscriptions