> name, addrs = parseaddr(msg.get('from'))
> addrs += '.invalid'
> del msg['from']
> msg['From'] = formataddr((name, addrs))
>
> If you put it in Mailman/Handlers/Cleanse.py or
> Mailman/Handlers/CookHeaders.py, parseaddr and formataddr are already
> imported from email.Utils so t
You can also apply this patch:
http://bazaar.launchpad.net/~mlm-author/mailman/2.1-author/revision/1341?remember=1338&compare_revid=1338
Rather than injecting an invalid domain in the From: and weakening more the
security of email...
___
Mailman-Deve
> Exactly how to patch this depends on what Mailman version you're
> starting with, but you basically want some code like this.
>
> name, addrs = parseaddr(msg.get('from'))
> addrs += '.invalid'
> del msg['from']
> msg['From'] = formataddr((name, addrs))
>
> If you put it in Mai
On 05/16/2014 09:27 PM, Franck Martin wrote:
> Upgrade to 2.1.18
If one is going to upgrade, one should upgrade to Mailman 2.1.18-1, but
presumably the OP knows that and wants a different mitigation.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabette
On 05/16/2014 08:36 PM, Bob Puff wrote:
> So guys... Is there a simple little hack we can do within MM 2.1 to try to
> mitigate this issue, by adding .invalid or some other extension? I've got a
> few lists that are getting to the point where MM sends the probe email, and
> then figures it is not
You are really mixing everything...
Toute connaissance est une réponse à une question.
> On May 16, 2014, at 20:09, "John Levine" wrote:
>
> In article <1856298671.144791.1400292991012.javamail.zim...@peachymango.org>
> you write:
>> The trouble with .invalid is that it is a domain that do not
Upgrade to 2.1.18
Toute connaissance est une réponse à une question.
> On May 16, 2014, at 20:43, "Bob Puff" wrote:
>
> So guys... Is there a simple little hack we can do within MM 2.1 to try to
> mitigate this issue, by adding .invalid or some other extension? I've got a
> few lists that are
So guys... Is there a simple little hack we can do within MM 2.1 to try to
mitigate this issue, by adding .invalid or some other extension? I've got a
few lists that are getting to the point where MM sends the probe email, and
then figures it is not a bouncing address, but a lot of emails are not
In article <1856298671.144791.1400292991012.javamail.zim...@peachymango.org>
you write:
>The trouble with .invalid is that it is a domain that do not accept emails.
>Therefore why should you accept emails from a domain
>that does not allow you to reply to it?
>
>It is bound in the future to creat
The trouble with .invalid is that it is a domain that do not accept emails.
Therefore why should you accept emails from a domain that does not allow you to
reply to it?
It is bound in the future to create issues when people move to more
serious/ubiquitous domain reputation schemes.
>>> that points to a server that rewrites the address and remails it, e.g.
>>> mme...@yahoo.com.remail.lists.org -> mme...@yahoo.com.
>I'm not very expert in this area, but it seems at least with the above,
>you'd need DNS entries for yahoo.com.remail.lists.org,
>aol.com.remail.lists.org, thenexto
On 05/16/2014 08:50 AM, John Levine wrote:
>> and a really evil one where you append a name
>> that points to a server that rewrites the address and remails it, e.g.
>> mme...@yahoo.com.remail.lists.org -> mme...@yahoo.com.
>
> This is apparently what LISTSERV does, give or take details of the
> s
> and a really evil one where you append a name
>that points to a server that rewrites the address and remails it, e.g.
>mme...@yahoo.com.remail.lists.org -> mme...@yahoo.com.
This is apparently what LISTSERV does, give or take details of the
syntax of the forwarding address.
Has anyone tried thi
13 matches
Mail list logo
