[Mailman-Users] Re: Need help diagnosing an intermittent DMARC mung failure

[Grant Taylor via Mailman-Users]

On 4/20/24 08:21, Jim P. via Mailman-Users wrote:

Does the sender have an internationalized domain name (IDN)?


Nope.  My domain is one of them.  Yahoo is another.  The 3rd, which I 
don't remember at the moment, is a .net or .com.


Are you able to reliably dig the sender's DMARC record over and over 
in a loop to test the reliability of the sender's DNS, perhaps even 
testing each of their nameservers independently?


I've not tested this specifically.  But I've not seen this symptom for 
my domain on any of the other hundreds of mailing lists that I'm on. 
Nor have I seen it for Yahoo anywhere else.



I see folks all the time that have DNS servers out of sync.


I think that's a fair question to ask.  I'm fairly certain that's not 
the problem here.


That being said, I can't guarantee that the DNS server(s) on the host in 
question isn't / aren't having problems.


I'll do some testing therefrom.

Are there any log entries, or debugging, that could be enabled / turned 
up to help diagnose this?




--
Grant. . . .


smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org

[Mailman-Users] Need help diagnosing an intermittent DMARC mung failure

[Grant Taylor via Mailman-Users]

Hi,

I'd like some help diagnosing an intermittent DMARC mung failure on 
Mailman 2.1.29.


Some of the time DMARC munging works perfectly fine, and then seemingly 
with no configuration changes, DMARC munging stops working.  Then after 
restarting Mailman it may start working again.  --  We don't have hard 
consistent data yet.


But we do have a sender that some of the time their system their 
messages come through with "First Last via List" 
 and then other times their messages come 
through with "First Last" .


No changes on the senders side / infrastructure and no changes on the 
mailing list config / infrastructure.


Does anyone have any recommendations on how to start troubleshooting this?

N.B. I don't have root on the system but I do have the ear of people 
that do.  I might be able to check logs if I have read permission on 
them.  I'm not seeing any obvious problems in the logs that I can read. 
I may have to relay diagnostic requests to the admins if I don't have 
permission.




--
Grant. . . .


smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@mail-archive.com

[Mailman-Users] Re: Question regarding message-ids

[Grant Taylor via Mailman-Users]

On 9/13/23 7:42 AM, Ralf Hildebrandt via Mailman-Users wrote:

* A mail goes to both lists.


A singular email is sent to both lists as a recipient.

* The mail is delivered twice (to an exchange server), in two SMTP 
sessions, to the same user adress. I get two positive delivery 
confirmations.


This is what I would expect.

* since the message-id is identical, exchange is performing duplicate 
message elimination


Okay.

Since the mails are in fact NOT identical (different Subject -- each 
lists adds their own [foo] and [bar] prefix), I'd very much prefer 
a new message-id for the distributed mails.


Oh ... that's not where I thought this was going to end up.

I'd have to go back and read RFCs on what the underlying purpose of the 
Message-ID is and if using it's definition the messages are identical or 
if they should have different Message-IDs after leaving the mailing list.


I can see it both ways.  The message is the same and not the same at the 
same time.


I'm sure I can hack something up in Postfix, but is there an easy way 
(tm)?


I'm sure there are things that can be done too.  My concern becomes what 
happens to threading when messing with the Message-ID?  Conditionally 
messing with the Message-ID is an entirely different problem.


This will probably be an interesting thread to read.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org

[Mailman-Users] Re: Python 2.7.15, etc, vs Python3...

[Grant Taylor via Mailman-Users]

On 7/17/23 7:24 PM, rich...@karmannghia.org wrote:

OTOH, can Python3 (what's there now) be THAT backwards incompatible?!


How incompatible are AM & FM radio?

How incompatible are IPv4 and IPv6?

How incompatible are gasoline and Diesel motors?


SURELY I can make it happy somehow, right?


As Carl Z. alluded to, you'll have to /port/ Mailman to Python 3. 
Though I suspect you will both make some people happy and other people 
mad at doing so.



How about an ln -s of /usr/local/bin/python to the one in my path?


I don't think that's going to work out nearly as well as you hope it will.


Do I have to install the old Python from source, TOO?!


Maybe if you can't find a version of Python 2.x for your distribution.

P.S. It seems BIZARRE to me that we have the good ole cc and gcc that 
just work after however many decades, yet the modern developers seem 
just not have a clue how - or just don't care - to code for longevity - 
what, the code to get python has to enter python3 now or just die? Really?


Python 2 and Python 3 are enough different to effectively be different 
languages.


I'm sure you can easily tell I strongly disagree with modern practices 
about dependencies; "computer science" has gone backwards, at least in 
strategy! ... But I digress...


I'm inclined to agree with you.  But that's just my opinion.



Grant. . . .
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org

[Mailman-Users] Re: Line breaks in monthly reminder emails

[Grant Taylor via Mailman-Users]

On 12/2/22 5:33 PM, Mark Sapiro wrote:
There is a -l/--listname option to limit to a list or, if repeated, 
lists, but no option to limit to a single user.


Sounds like a reason to (temporarily) create a new list with yourself as 
the only subscriber and test things.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Line breaks in monthly reminder emails

[Grant Taylor via Mailman-Users]

On 12/1/22 11:45 PM, Stephen J. Turnbull wrote:
Possibly more flexible (but harder to implement and dependent on user 
MUAs) would be to use format=flowed in Content-Type.


+10 for format=flowed

IMHO format=flowed is not hard to implement and it produces responsive 
emails which wrap to whatever the window width is.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Duplicate emails being received

[Grant Taylor via Mailman-Users]

On 10/17/22 9:20 PM, Mark Dale via Mailman-Users wrote:

Thanks for that pointer.


You're welcome.

At the moment the Postfix smtpd_timeout = 60s. I think the original 
default is 300s.


I don't see any problem with having the higher value.  Most connections 
will complete well within that amount of time.  20% of that time in 
fact.  The few that don't will not adversely effect your server.


The restart (as per Mark S.'s advice) has got the mail back to one copy. 
If it goes off the rails again I'll experiment with that timeout.


ACK

That was my bad. I had a cert error and thinking the message hadn't been 
sent, I resent it.

*

Things happen.

There is one timeout error (unrelated I think) that gets repeated every 
hour approx. for just one recipient.


So you know what the error would look like and you have the absence of 
it as the source of the problem you were asking about.


That seems like a good thing to me.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Duplicate emails being received

[Grant Taylor via Mailman-Users]

On 10/17/22 5:25 PM, Mark Dale via Mailman-Users wrote:

Does anyone have any tips or pointers?


I've seen this type of duplication when there were communications 
problems that were causing your outbound MTA to send messages multiple 
times.  This usually happens when there are communications problems and 
your sending MTA doesn't receive the confirmation from receiving MTAs 
that they have accepted the message.  This might be a result of a 
timeout setting being too low on your sending MTA.


Given that your message to the mailman-users mailing list came to the 
list twice, which didn't involve your instance of Mailman, I sort of 
suspect you have lower level / SMTP problems.


I think that your MTA's logs will be a very good place to start looking. 
 At least to see if there is evidence of problems or not.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Plus addressing

[Grant Taylor via Mailman-Users]

On 3/21/22 8:01 AM, robertowenbere...@gmail.com wrote:

Does the list support plus addressing?


Yes and no.

I believe the more proper name for this is user+detail.  I see "plus(ed) 
addressing" used more commonly more recently.


Yes, Mailman will happily accept user+detail addresses from subscribers.

No, Mailman itself won't treat user+detail@ and user@ as equal.


I am aware of the hack at:


This is what I've been doing for years.

However this does not appeal to the tinfoil hat crowd who thinks you 
are just going to sell both addresses.


There are a lot of things that don't appeal to people for one reason or 
another.



Nor do I want to explain to the masses this hack.


You have to make a choice.

Use separate addresses (and subscribe both) or don't, it's up to each 
individual.


There may very well be client side options too.  E.g. configuring the 
MUA that when you are on a folder for a given mailing list that it uses 
a different source address when composing messages.  Though this has 
it's own failure mode related to false positive / negatives.  There 
might be an MUA option to change sender addresses based on destination 
addresses.


What is the lesser evil to you / your users?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Email different content in an unique list

[Grant Taylor via Mailman-Users]

+2 for topics

On 12/9/21 11:18 AM, Mark Sapiro wrote:
For individual messages, Mailman 2.1 has a Topics feature. This is not 
yet in Mailman 3 in any form, but works for Mailman 2.1. In the Topics 
section of the admin UI you define topics via regexps to match against 
the Subject: or Keywords: (if one) message header(s) or pseudo headers 
in the message body. Each topic has a name and description.


It's possible to have Procmail scan the full body of messages for 
keywords and automatically generate a Keywords pseudo header that 
Mailman can then key off of.  I've used this with great success for years.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Viewing bounces from Mailman-generated messages?

[Grant Taylor via Mailman-Users]

On 10/12/21 9:30 AM, Jayson Smith wrote:
However, since Sendmail logs don't actually show the full rejection 
message, that's all I know, and it's not enough to go on.


I have seen tell of a patch in the comp.mail.sendmail newsgroup to have 
Sendmail log the full error message (SMTP response).


My understanding is that Sendmail only logs the first line of the SMTP 
reply.  So if there are details in subsequent lines of a multi-line SMTP 
reply, you'll need the patch.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Gmail and DKIM problems

[Grant Taylor via Mailman-Users]

On 6/30/21 4:37 PM, Thomas Gramstad wrote:

I understand that he can't do anything about the DKIM setup at gmail.


Nor should he, or anyone else, need to.


Can I as list admin do something in the list setup (Mailman 2.29)?


As others have said, remove incoming DKIM headers from incoming 
messages, and add your own DKIM headers (signature) to outgoing messages.


This is particularly important if you make /any/ changes to the message 
as it passes through the mailing list.


Also, how many subscribers are likely affected by his (or any gmail 
user's) DKIM setup?


It depends on how the sender's domain has configured things; SPF, DKIM, 
DMARC.  Chances are quite good that any sender from a domain using 
contemporary stringent settings will have problems with any recipient 
who has a mail server that honors what the sending domain publishes. 
You have zero control over what the sender's domain does.  You have zero 
control over what the recipient's mail server does.  You only have 
control of what you do with the mailing list.


That is, are most list subscribers receiving his messages anyway, or is 



this problem preventing e-mail from him going to most list subscribers?


I'd say the best that you can hope for is for messages from the mailing 
list to be filed as spam.  The worst, which may be more likely, is that 
the mailing list server develops a bad reputation and ends up blocked by 
one or more recipient domains.


More sending domains are adopting stringent settings.  More receiving 
servers are honoring stringent settings.  It's a multiplicative effect 
as time goes on.  You can either push back or you can update your 
config.  With the multiplicative effect, you will probably need to push 
back more often.


Stop and think for a moment what's actually happening:

1)  The sender's mail server is specifying which server(s) are allowed 
to send email as them and / or apply a cryptographic signature to (part 
of) the message.  They also publish this information so that receiving 
systems can easily consume it.
2)  Receiving systems are using the information that senders publish to 
be able to tell if message are legitimate based on the source and / or 
cryptographic signature.


So, when you (re)send messages from the mailing list as sending domain 
(in the SMTP envelope) you are likely running afoul of SPF.  When you 
modify any (signed) part of the message, you are breaking signatures. 
Thus, recipients see that messages aren't coming from where the sender 
says they should be and that the cryptographic signature is broken. 
Hence the receiving server is naturally treating the message from the 
mailing list as highly suspicious.


To avoid this suspicion:
1)  Send with your own SMTP envelope address (VERP).
2)  Use full personalization.
3)  Remove incoming DKIM signatures.
4)  Add your own outgoing DKIM signature.

I'd suggest updating your config sooner than later.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Okay, you can call me an idiot now

[Grant Taylor via Mailman-Users]

On 5/17/21 11:41 AM, Jayson Smith wrote:

Hi again,


Hi,

Last night I posted a message about Mailman and/or Sendmail failing to 
deliver Emails to a particular address with an upper case first letter. 


Two of you pointed out that the mail was probably stuck in Sendmail's 
outgoing queue, and if it wasn't, the Sendmail logs would show what 
happened to it. Turns out, you were right. Sendmail did not have those 
messages in its outgoing queue, and the logs didn't show what happened 
to them…until I suddenly remembered something, and realized I'd 
been 
making a stupid newbie mistake all along, and I am not a Linux newbie by 
any means!


It happens.

I'd been using Grep to search logs…and I'd forgotten that Grep 
searches, by default, are case sensitive! When I took that into 
account, the nonexistent log entries showing this user's mail going 
out suddenly started existing, wouldn't you know it!


That's why one of my pet phrases is "trust, but verify".  Especially 
when someone else is asking for help / an additional set of eyes on the 
problem.  Trust that your colleague did the proper thing.  But verify it 
yourself.  We all make silly mistakes like this from time to time. 
Don't beat yourself up.


Turns out what's really happening is that all mail from this list is 
going into this user's junk folder. I'm going to ask if he has a 
button/option to declare such mail to not be junk so hopefully this can 



be corrected.


That makes perfect sense.

Aside:  Don't you just love how you have to identify other people's 
problems so that you can convince them that you don't have a problem?



Thanks,


You're welcome.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: MM2/Sendmail failing to send messages to upper case Email addresses?

[Grant Taylor via Mailman-Users]

On 5/16/21 8:34 PM, Mark Sapiro wrote:
Why is a sendmail question. Possibly someone on this list knows the 
answer, but a sendmail list might be a better resource.


I give it about a 98% chance that Sendmail still has the message in it's 
queue or that it has bounced it.  (Possibly sending it to an unexpected 
location.)  The mail log should show what Sendmail did with the message.


If it is still in the queue, you can have Sendmail do an interactive 
delivery attempt.  I'd try the following:


   sendmail -v -qI0123456789ABCDEF

Presuming that the message ID in queue is 0123456789ABCDEF.

This should cause Sendmail to try to deliver the message again while 
showing what it's doing on STDOUT.


I think that it's very unlikely that Sendmail is loosing the message. 
It's not impossible, but I'd bet a reasonable lunch that it's less than 
0.1 % of a chance that /Sendmail/ is the reason the message is being lost.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Does mailman work well for large lists?

[Grant Taylor via Mailman-Users]

On 2/26/21 3:29 PM, david.bar...@mail.com wrote:

Good day,


Hi,

Looking for a solution to have about 50-200 lists for subscribers. 
Any good examples of mailman being used for 50+ lists you can share 
for me to see? Trying to see the feasibility of implementing a solution 
in next 90 days.


I don't think the number of lists is as important as the number of 
subscribers on each list.


I have seen many installations of Mailman (v2.x) that have had lots of 
lists.


I believe some of the Mailman lists that I'm subscribed to have hundreds 
of subscribers.


Would like to see a working one, where a user would go to a site, 
and pick a list to subscribe.


Sorry, I don't know of anything off hand.


Is mailman easy to setup and maintain?


I've found that Mailman 2.x is quite easy to set up and maintain. 
Though, I don't think Mailman 2.x is good for a greenfield deployment. 
I don't have any experience with Mailman 3.x.  Though I have heard that 
3.x has different requirements than 2.x, some of them non-trivial.



Windows or Linux server recommended?


My vote is for Linux (or another Unix varient).


Thank you.


You're welcome.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: OpenPGP and S/MIME aware Mailman

[Grant Taylor via Mailman-Users]

On 2/14/21 3:02 PM, Dennis Putnam wrote:
I was considering taking that plug-in and modifying it to at least work 
with GPG and mailman 2.1.36.


You might look to see if you can move the problem to the MTA level. 
E.g. have the MTA, or something like a milter on it's behalf, encrypt 
outgoing messages.


You can probably have something decrypt the messages between the MTA and 
Mailman.


Something like this would allow you to use a stock Mailman.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: OpenPGP and S/MIME aware Mailman

[Grant Taylor via Mailman-Users]

On 2/12/21 3:01 AM, Mailman-admin wrote:

And you need to distribute their public keys to your users.


Fortunately, S/MIME makes this simple.  All you need to do is sign the 
message.  Recipients can extract the public key from the signature.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Addressing of list messages by the server

[Grant Taylor via Mailman-Users]

On 2/10/21 10:26 AM, Christian Buser via Mailman-Users wrote:

Hi all


Hi,

My questions - just to understand it, since the list seems to work 
perfectly:


1) What does cause this different addressing


I'm guessing this is related to DMARC.

2) How does the receiving mail server know where to deliver the message 
when there is no Cc: field in the headers and the list address in 
the To: field?


Email is delivered based on the SMTP envelope addresses, which are 
completely disconnected (but often similar) to the email header addresses.



Thank you, Christian


You're welcome.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Topic hack to streamline use of topics.

[Grant Taylor via Mailman-Users]

On 10/15/20 4:08 PM, Mark Sapiro wrote:
Actually, as I note in another post, the header is Keywords:, not 
Topics:. That was my error.


*nod*nod*

I was following your lead.

Simple mistakes happen.  It's how we correct them that matters.  ;-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Topic hack to streamline use of topics.

[Grant Taylor via Mailman-Users]

While on the topic of topics ... ;-)

I implemented a hack in my LDA to search the body of messages for 
specific keywords.  When one (or more) of the keywords is found, it adds 
a specific value to the Topics: header.


This way, posters don't have to worry about defining the topics before 
they hit send.  It also allows me to be more granular and flexible at 
the same time.  I can create an "email" topic that will match on 
Mailman, Sendmail, Microsoft Exchange, GroupWise, etc.  (Sure, there's a 
little wiggle room in the pattern matching and logic.)


This has largely worked out very well for the lists that I've applied it to.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Help with Topics

[Grant Taylor via Mailman-Users]

On 10/13/20 3:51 PM, Mark Sapiro wrote:
For example, if topic1 has regexp \WMailman\W and topic2 has regexp 
\Wlist\W, any message containing a Subject: or Topics: header or pseudo 
header containing the word Mailman ...


What is a "pseudo header" in this context?

Are you referring to the first line of the message body being abused and 
treated like a header?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Alternate URL hostname in web UI

[Grant Taylor via Mailman-Users]

On 7/27/20 12:22 PM, Kevin Bowen wrote:

Hello,


Hi,

I'm trying to set up the mailman (2.1.9) web UI behind a load balancer 
in order to offload the TLS to it (because this is an ancient machine 
which doesn't support modern TLS versions, and newer browsers are 
complaining about it). I need all the links in the web UI to use 
the new hostname that's in front of the loadbalancer, instead of the 
actual hostname behind the loadbalancer. Am I understanding correctly 
that DEFAULT_URL_HOST in mm_cfg.py would be the way to accomplish 
that? And would that affect only the URLs used in the web UI, it 
wouldn't change anything about the actual mail handling under the hood?


I can't speak directly to the DEFAULT_URL_HOST.

Does the load balancer support rewriting things as traffic passes 
through it?  I know it's possible to get Apache to do this.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/

Re: [Mailman-Users] Best way to slow down all the spam to my lists?

[Grant Taylor via Mailman-Users]

On 12/13/19 9:02 PM, Mark Sapiro wrote:
As postgrey learns, it will remember triplets (sender, sending IP, 
recipient) and not delay them and in addition will whitelist domains 
that retry successfully more than a few times.


The bigger senders are doing things now (more than ever) that they 
weren't doing 15+ years ago.  Now farms of servers will try to contact 
you.  The message may first try from one IP, then from another IP, then 
from a 3rd  It may eventually try from the same IP and make it through.


I think most grey list solutions have an option to specify the network 
(frequently configured a a /24) for the sending IP.  This significantly 
helps with different servers in the same server farm trying to resend 
messages.


Another option that doesn't have this (state based) limitation is 
nolisting.  (TCP RST from first MX and subsequent MX(s) accept email.)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] LDAP routing

[Grant Taylor via Mailman-Users]

On 11/14/19 11:31 AM, Zinski, Steve wrote:
We are migrating from sendmail (virtuser) mail routing 
to LDAP routing. Setting up routing for users is pretty 
straightforward using the inetLocalMailRecipient class and 
the mail/mailLocalAddress/mailRoutingAddress attributes. But I was 
wondering what would be the best (correct) way to represent the mailman 
alias addresses in LDAP (i.e., list-admin, list-bounces, list-confirm, 
etc.). Would each get its own entry in LDAP or is there a better way? Any 
help would be appreciated.


Are your mailing lists mixed in a dedicated (sub)domain name?  Or are 
they mixed in with other non-mailing list addresses?


The former probably doesn't need much other than something akin to a 
mailertable entry.  (Is that also migrating to LDAP?)  If it's the 
former, you're going to need /something/ to cause Sendmail to recognize 
the mailing list addresses.  This probably means that you're going to 
need LDAP entries.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Maximum attachment size

[Grant Taylor via Mailman-Users]

On 6/5/19 3:59 PM, Robert Heller wrote:

I wonder if this is *mailman* or your MTA that is complaining...


It might also be a webserver thing trying to react to the pending 
moderators request / hold screen (page).




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Maximum attachment size

[Grant Taylor via Mailman-Users]

On 6/5/19 3:18 PM, Bryan Blackwell wrote:

Hi folks,


Hi,

I've run into an apparent limit in size - we send newsletters through 
one of our lists, and they can get large.  One in particular runs over 
20MB, and I get an error on the held messages page trying to process it.


I'm guessing that you are aware of the Maximum length (max_message_size) 
setting on the General Options page.


Remember that Base64 attachments become 4/3s their size.  So a 20 MB 
file attachment becomes ~27 MB of Base64 encoded content.


Also remember that the MTA's maximum message size will add any headers 
and body content onto the size.  So I'm guessing you want to be able to 
support 30 MB email messages.  This should be easily doable.  Even if 
some people (myself included) don't like it.


Currently we have version 2.1.20, I know there are updates but not if 
they address this limit or if there's some other fix.


I'm guessing that this is a Mailman and / or MTA configuration issue.

The fact that the message makes it into Mailman tells me that the MTA 
can handle the attachment.  I wonder if simply raising the Maximum 
length (max_message_size) might allow the message to pass normally.


I don't know what to think about the pending moderator requests / hold 
page's behavior.  I'll defer to other more knowledgeable people on the 
mailing list.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] question about email automation

[Grant Taylor via Mailman-Users]

On 5/30/19 8:04 AM, Fabian A. Santiago wrote:

Hello,


Hi,

i run a mailing list on mm 2.x. periodically i send out an event 
opening email to the list. this is typically followed by a conclusion 
email at the end of a specific period.


How specific is the period?  Is the end known at the start, i.e. 3 
months, or is it dependent on when a project completes?


in the interim period i would like to send out reminders of the event 
to the list but would like to automate this task.  i want the reminders 
to be triggered by my opening email and end with my conclusion email.


I don't know if it really matters, but please clarify if you're talking 
about one list that multiple events are discussed on or if it's a 
different list per event.



has anyone done this and how?


I have not.

I think one list for multiple events would be simpler from an automation 
point of view.  I say this because I'd subscribe a utility account that 
would receive copies of all messages and be able to parse them for 
specific keywords (event  starts , etc.).


I would likely have this script set up (Unix) at jobs (vs cron) as I 
think programmatically scheduling them might be easier.  The at job can 
send the emails (typical script sending email) at the specified times.


If the duration of the project is known ahead of time, you can 
pre-schedule multiple at jobs and be done with it.


If the duration of the project is not known ahead of time, I think you 
will need to have each reminder iteration schedule the next at job.  You 
will also need to have the utility account be a bit smarter and look for 
the end of job / event / project announcements.  -  In this case, I'd 
likely enhance the at job to look for a (flag) file or contents to 
determine if it should send the reminder or not.  That way, you can 
finish a job / even / project and make sure that there's not 
accidentally spurious reminders that get sent or worry about cleaning 
them up by simply removing the (flag) file or changing it's contents.


I know that it's crude.  But it will get the job done.


i've looked at ifttt and zapier but wasn't sure. thanks.


I'm not familiar with them.  Sorry.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Training Mailman to find email address from NDR

[Grant Taylor via Mailman-Users]

On 5/15/19 10:55 AM, Mark Sapiro wrote:
This message is a disaster. Is this an actual bounce as received? It 
almost looks like an RFC 3464 compliant DSN except see comment below.


~chuckle~

Agreed.

The message body is that of a MIME multipart message, but the main 
content type is text/plain instead of


multipart/mixed; boundary="66728b7fa14ce3ed"


RFC 3464 wants a Content-Type of message/delivery-status.

so the whole body is just one plain text part and is quoted-printable 
encoded so that just changing the above Content-Type: won't work because 
there is quoted-printable encoded content in the sub-parts including 
sub-part headers.


I have seen the other replies in this thread, so I'm not adding much here.

Trying to recognize this in Mailman would be a major kludge and not 
worth the effort.


I would argue against hacking Mailman to recognize this as a failed 
attempt at an RFC 3464 Delivery Status Notification.


RFC 3464 has been out for 17 years.  I think it's past time that we stop 
coddling people that can't conform to it.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Training Mailman to find email address from NDR

[Grant Taylor via Mailman-Users]

On 5/15/19 7:45 AM, Andrew Hodgson wrote:

Hi,


Hi,

Here is the bounce message, I know I can enable VERP and this problem 
should go away, but I wanted to see if I could get this working without 
VERP as we have a large mail traffic on the list. 


Did you redact anything significant from the bounce?

I don't see the expected boundary="66728b7fa14ce3ed" parameter to the 
Content-Type: header.


I'm also surprised that the Content-Type: is text/plain and not 
multipart/report.


I don't know enough about Mailman's bounce processing to know if it will 
find and process the message/delivery-status or not.  I also question 
what Mailman would do with a temporary failure, 4.7.0.


It looks like Yahoo TempFailed the message because they don't like 
SendGrid for one reason or another.


I'm also somewhat surprised that SendGrid is returning the entire 
original message instead of just the headers.  IMHO that's a good way 
for a bounced message's content to get trapped by a spam filter.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Prevent users from changing email address

[Grant Taylor via Mailman-Users]

On 4/23/19 5:02 AM, Kiffin Gish wrote:
Is it possible to configure mailman so that it is not possible for users 
to change their email address, e.g. disabling the option and including 
the service desk contact information instead?


What will prevent users from unsubscribing with the old address and 
resubscribing with the new address?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Spam / Email Spoofing Problem (SPF check possible?)

[Grant Taylor via Mailman-Users]

On 4/5/19 11:59 AM, Valentin Schwarze via Mailman-Users wrote:
Are there any settings that we as administrators of the list could 
change to end that behavior? For example, is it possible in any way, 
that Mailman only accepts emails that passed a SPF check? Or any other 
option to prevent email with forged sender adresses to be distributed 
through the mailman list?


As Mark and Carl have stated, you are better off implementing email 
hygiene in your MTA and only passing clean messages to Mailman.


Note:  SPF by itself won't do anything to protect against From: header 
spoofing.  I would suggest that you also look into DKIM and particularly 
DMARC filtering.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] FetchMail feed into Mailman

[Grant Taylor via Mailman-Users]

On 3/26/19 12:36 AM, Jim Ziobro wrote:
You won't know how important until you start getting duplicate messages 
like RFC 1047 .


How would having a local MTA change the behavior in the face of a 
duplicate message?


I've seen symptoms of duplicate messages where multiple servers up 
stream are the source of duplication.


Are you implying that local MTA alters this behavior?  Or that it 
provides additional tracing / diagnostic information?


I'm not aware of Mailman having any Message-ID deduplication 
functionality.  Nor have I really seen it as a need.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] FetchMail feed into Mailman

[Grant Taylor via Mailman-Users]

On 3/26/19 12:36 AM, Jim Ziobro wrote:
why not setup standard Mailman under your favorite mail system and let 
FetchMail do what it does best?


The unneeded complexity of a local mail system.

FetchMail & SMTP Auth would work against an ISP's email server over 
dynamic / dial up connections.


Sure, FetchMail can pull email from the ISP and inject it into the local 
server.  But what advantage does that gain you?  Is said advantage worth 
the complexity?


Especially if the ISP aliases testlist & testlist-* into one mailbox.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mailman on google comput engine

[Grant Taylor via Mailman-Users]

On 3/24/19 11:50 PM, Stephen J. Turnbull wrote:
This should work in Mailman 2, but won't in Mailman 3 (which expects 
incoming posts via LMTP).


Noted.  I think it would be possible to interject a shim between 
fetchmail that would extract what's necessary to speak LMTP to Mailman.


Is the LMTP still STDIN / STDOUT or something else (possibly a Unix socket)?

I'm trying to understand if I could drive Mailman 3 via Expect.  Not 
that I would.  I'm just wondering if I could.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mailman on google comput engine

[Grant Taylor via Mailman-Users]

On 3/21/19 4:04 PM, Dimitri Maziuk via Mailman-Users wrote:
I honestly don't remember the details but if I was passing mail to 
local MTA configured as my home MX, I don't see why mailman wouldn't 
work behind that.


I think that it should.

I'm talking about bypassing the local MTA all together.  Pipe fetcmail's 
STDOUT to a wrapper script to extract the command and mailing list 
before piping it into the mailman executable with said command and 
mailing list.  Then have Mailman act as an SMTP client directly to an 
external MTA.  No local MTA period.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mailman on google comput engine

[Grant Taylor via Mailman-Users]

On 3/21/19 2:05 PM, Dimitri Maziuk via Mailman-Users wrote:
IST vaguely R firing up fetchmail from a dip script to inject messages 
from my school mailbox into my local qmail... Plenty typical at the time.


Fetchmail itself is plenty common.  I had no idea that it was as common 
with Mailman.  209 hits on the link that Mark shared.


The 45 messages mentioning UUCP surprises me more.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mailman on google comput engine

[Grant Taylor via Mailman-Users]

On 3/21/19 11:58 AM, Adam Goldberg wrote:

There are ways around this.


I see no technical reason why Mailman couldn't function via something 
like fetchmail from a POP3 mailbox and SMTP Authentication to send.


Fetchmail would pull the messages from an external 3rd party email 
server, do a little processing on them to determine the command and list 
name before pipeing them into Mailman with said command and list name. 
Mailman would do it's thing, and then send the emails out using SMTP 
Authentication with the external 3rd party email server.


It would be quite atypical.  But I think it should work.

This might work for the OP.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mailman on google comput engine

[Grant Taylor via Mailman-Users]

On 3/21/19 12:40 AM, 황병희 wrote:
in this case i can run mailman with other port (example 625)? again 
question, Mailman can act with 625 or 1625 or 2625, ...?


No.  Not directly.

Mailman is not a mail server.  You must have a mail server (daemon) sit 
in front of Mailman.


You can make that mail server listen on a different port.  However only 
the other servers you modify to communicate with that alternate port 
will be able to send email.


You really want port 25.  Or you need something else, likely 
specialized, to make things work.


(It's likely possible that something can fetch email from elsewhere and 
feed it into Mailman, but that's something specialized.)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] email to sms?

[Grant Taylor via Mailman-Users]

On 02/27/2019 02:22 PM, Dave Stevens wrote:

Hi,


Hi Dave,

I've been using mailman to send routine announcements for a long time 
and more and more what people want is a text message. I've been able 
to discover gateways for individual carriers so that I can send to 
@..com and the subscriber gets a text, so 
phone notification which is quick and handy. This has been well received.


I've been looking at the list of carriers getting longer and have looked 
into email to sms services but what I've seen has been commercial and 
too expensive.


Is there a collaborative or open source email to sms project? Can anyone 
refer me to better information? I've been pretty much just casting around 
so far.


I don't think I've seen a collaborative or open source email to SMS 
project.  I suspect this is because of the technical nature of 
gatewaying and / or the cost associated with doing so, be it 
infrastructure or per message.


The only free services that I've seen have been operated by the cellular 
networks for their customers.


The other commercial services have all had cell phones (or other similar 
devices that interface with the cellular network like a phone) and end 
up sending lots of texts.


I don't see how to overcome either of these limitations.  Maybe there is 
a way.


I feel like sending text message is beyond the scope of what a mailing 
list manager should do.  If some of the subscribed addresses happen to 
be email address that are subsequently gatewayed, so be it.


If you really want to look into something to send SMS (or MMS) messages 
in bulk, I'd look at something in parallel with Mailman.  Let Mailman do 
what it's good at, email, and use something else for SMS (MMS).




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Automatic subscription based on e-mail subject

[Grant Taylor via Mailman-Users]

On 2/1/19 6:49 PM, Richard Damon wrote:
Yes, Mailman has a feature call topics, but that is very different 
then what the OP is asking for.


Agreed.  (I thought I covered that in my last email.  Maybe I wasn't clear.)

The Mailman 'Topic' operation basically provides the ability of the 
list owner to define topics based on Regex's on the subject (which is 
helped greatly if posters add the appropriate key words to subjects to 
allow them to be categorized).


I'm glad to know that Mailman's "Topic" feature (key word matching) 
works on the subject.  I thought it was looking explicitly for the 
Keywords: header.  That does help some.


Of course, that does rely on posters putting proper keywords in the 
subject.  Which is less than reliable.


I have long wished that Mailman's "Topic" feature would also look for 
keywords in the body in addition to the Subject and Keywords: header.


I feel like Mailman's "Topic" feature is under utilized.  :-/

I suppose one option that might satisfy the OP would be the ability for 
the subscriber to add a custom regex as a filter. That way they could 
get it to filter on the replies they are looking for, and ignore the 
rest. The biggest issue is that regex's are somewhat archaic for the 
typical user, but it would only really affect people who try to use it.


Oy vey.  I would be afraid of how that would likely not scale.  I also 
see security implications in that.  (Running subscriber specified RegEx 
(code) on a server.)  I also feel like that would be mainly usable for 
the single user that specified the RE.  Or are you proposing that the 
user specified RE show up as available "Topics" that people can choose 
to subscribe to?


I feel like this would be best implemented if the poster added a blob of 
text to their subject and configured their client side MUA filters to 
mark messages from the mailing list that don't have said blob in the 
subject as read.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Automatic subscription based on e-mail subject

[Grant Taylor via Mailman-Users]

On 02/01/2019 01:14 AM, R. Diez via Mailman-Users wrote:
Of course there is the concept of 'Topic' in a mailing list. Mailman, 
the web interface, or whatever, does know how to group topics together. 
That is an obvious feature, because people tend to work/participate in 
threads.


I believe that what Mailman (2) considers to be a "topic" is 
considerably different than what you might consider to be a "topic" or 
"subject" or "thread".


My understanding is that Mailman considers a message to be part of a 
"topic" if the message has one or more key words defined for the topic. 
I.e. any message that has SMTP could be one topic, or DNS be another, or 
Python a third.  This is decidedly NOT the "subject" or "thread" meaning 
of the word "topic" that I think you are using.


What makes this more interesting ~> problematic is that I think Mailman 
doesn't actually scan the message body for the topic(s) / keyword(s). 
Instead, I believe it requires the topic(s) / keyword(s) to be listed in 
the Keywords: header.  -  I know that I've used procmail to scan (copies 
of) messages and add the proper topic(s) / keyword(s) to the Keywords: 
header so that Mailman would see them and use it's topic filter 
properly.  -  This was a LONG time ago and I have forgotten almost all 
of the context.  This may no longer be a requirement for current 
versions of Mailman.


Suffice it to say that Mailman's "Topic" concept is different than 
concept that you and I have for "topic" / "subject" / "thread".




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Allow posting from addresses with modifiers?

[Grant Taylor via Mailman-Users]

On 01/14/2019 11:13 AM, Mark Sapiro wrote:
To place the burden on john, he can subscribe both addresses and set 
j...@example.com to nomail.


This is what I have done for many mailing lists.  —  I subscribe with 
one private address for email filtering and reply from another public 
email address.


I suggest that the member also pick one and toggle the option to hide 
(the non-public subscribed address) from other subscribers.


To place the burden on you, assuming you have access to Mailman's command 
line tools, you could periodically (via cron) run a script to list the 
members, find those with '+' in the local part and add the address without 
the +... in the local part to the list's accept_these_nonmembers. There 
is a script at  (mirrored 
at ) that can do the 
adding to accept_these_nonmembers.


I don't see any obvious security related down sides to this.  It does 
open the mailing list up to messages (spam) from some additional 
addresses.  But I can't think of any cases where u...@domain.tld would 
be different than user+det...@domain.tld.  I guess maybe some sort of 
ticketing system /might/ do something like that.  But I bet that the 
intersection between such configurations and Mailman configured as Mark 
is describing to be quite small.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler same as postfix-to-mailman.py

[Grant Taylor via Mailman-Users]

On 01/07/2019 09:59 AM, Dmitri Maziuk via Mailman-Users wrote:
We used to run irix whose sendmail sent every message from host.domain 
and every A record had to have an adjacent MX record for e-mail to even 
work. That way lies madness.


Hum.

I think Sendmail (and other MTAs that I've tested) default to 
user@host.domain too.  But that's just a default that's easy to change.


I thought that SMTP allowed for falling back to an A record to find 
where to send messages for host.domain.  Or are you saying that you used 
MX records to route email to a different machine, possibly a mail hub?


I also thought that SMTP would iterate up through the right hand side of 
email addresses looking for MX / A records and trying to connect to an 
SMTP server.  Thus it would be possible to have an MX record for domain 
and all hosts there in would cascade up to said MX record.


Or is all of this vagaries of SMTP and too unpredictable / unreliable 
and best avoided?


Rather trivial with postfix but a) we have bona fide subscribers posting 
rom their gmail instead of subscribed From: -- I want those to get 
moderated instead of bounced, b) it is of course subject to spoofing, 
and c) how much of a problem is it IRL?


A) Fair enough.  I would expect there to be a per-list tunable to either 
reject or not-reject messages based on list membership.  In the scenario 
that you describe, the messages would not be rejected based on sending 
email address and assuming the message passes other tests would be 
passed further into Mailman.


B) I would hope that other things like SPF / DKIM / DMARC would help 
reduce this considerably.  But I'm not going to hope enough to hold my 
breath.


C) ¯\_(ツ)_/¯  I suspect it's highly mailing list dependent.  -  I 
personally like to do as much as possible during the SMTP transaction. 
So if there is a reasonable way to apply some Mailman filtering logic to 
applicable messages, why not do it?


In our -- admittedly very lightly loaded -- domains, it's RBL and fail2ban 
that seem to provide best bang for the buck.


*nod*



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler same as postfix-to-mailman.py

[Grant Taylor via Mailman-Users]

Hi Jim,

On 1/4/19 3:40 AM, Jim Ziobro wrote:
Setting up mailing lists in a separate domain has a nice administrative 
appeal.


Agreed.  That's how I've always done it.

If I ever cared enough, I could set up a forward (et al) from 
l...@example.net to l...@lists.example.net.  Maybe not automatic.  But 
it does function.  (Or it did the last time I tried.)  -  I think it did 
require adding an alternate address for the list to recognize itself as.


I did a little more research to see how popular that method might be. 
I got a list of 1922 US universities and 457 have a host "lists" and 
191 have a host "list..." in their DNS.  I surveyed a few and ran 
across: Mailman, Lyris, Sympa, Listserv, Majordomo, and Google groups. 
Many universities outsource their Email to Outlook which has it own 
Group capability.


Interesting.

I can hook up any mail system.  Just give me the list of mail-lists and 
tell me how to inject messages.  Glue will be more specific to a Mailer 
and OS than either Mailman or Sympa.  I think we get a benefit if we 
make a clean interface between Mailman and its feeding MTA.


Agreed.


We can then eliminate some of the hacks like mm-handler.


Maybe.  But I think the hacks just move elsewhere, especially if you 
want other features.



I have some ideas for Mailman2.  I'll follow up.


I'd like to see some sort of integration into the Mailer (MTA) such that 
it can do some simple filtering and reject the message at SMTP time 
instead of needing to bounce it after the fact.


I think it should be somewhat easy to test the SMTP envelope sender to 
see if it's subscribed to a list that is the SMTP envelope recipient. 
If the sender is not a subscriber the MTA can reject the message.


It wouldn't be as simple, but I think similar could be done with the 
DATA phase of the SMTP transaction to filter body contents.  Though I'm 
not sure how to parse a message to see if it should be rejected without 
actually having the message pass through part of Mailman.


I also think that an LMTP and / or SMTP interface to Mailman would be 
nice.  I think that provides more features at the SMTP / DSN (maybe MDN) 
level than STDIN into Mailman can provide.


Nice work Jim.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] UTF-8 and digests...

[Grant Taylor via Mailman-Users]

On 11/30/2018 10:33 AM, Mark Sapiro wrote:

Plain text digests are encoded in Mailman's character set for the list's
preferred_language. For English, this is us-ascii unless you've changed
it. Thus, non-ascii unicodes will be rendered as '?' in the plain digest.

You can change Mailman's character set for English to UTF-8 by putting

add_language('en', 'English (USA)', 'utf-8', 'ltr')

in mm_cfg.py but this has other side effects. Most importantly, the
Python email library encodes utf-8 message bodies as base64. this makes
it difficult to find messages in mailboxes with tools like grep.

Thank you for the clarification Mark.  That accounts for what I'm seeing.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] UTF-8 and digests...

[Grant Taylor via Mailman-Users]

Is it expected that Mailman will preserve UTF-8 (punctuation symbols) in 
non-MIME digests?


I'm having errors reported to me from (non-MIME) digest subscribers to 
lists mailing lists.


Is this a known limitation of non-MIME digests?  Or is it possibly a 
symptom of a problem?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler or aliases to integrate with sendmail

[Grant Taylor via Mailman-Users]

On 11/29/2018 02:00 AM, Jim Ziobro wrote:
Mm-handler is definitely a cool idea. But it seems that once Mailman can 
update Sendmail's aliases immediately there is no need for mm-handler.


I view things a little bit differently.

Why should I need to reconfigure the MTA when I'm making a change to a 
different (sub)system.  Specifically, why to I need to add / change / 
remove MTA aliases when I'm changing Mailman?


With mm-handler, I don't need to reconfigure the MTA at all.  I can add 
/ change / remove mailing lists to / from Mailman all I want.


Granted, I am hosting my mailing lists in their own subdomain that is 
routed to Mailman.


I acknowledge that aliases are required if you want to mix mailing lists 
and mailboxes in the same (sub)domain.  (I do wonder if LDAP routing 
might change this.)


According to: 
https://mail.python.org/pipermail/mailman-users/2004-June/037518.html
it is just a matter of changing POSTFIX_ALIAS_CMD to something 
different.  I either missed the article or I didn't understand it the 
first time I looked at the docs.  This seems like it might be easier to 
maintain and setup than the mm-handler.  At least it is the way I would 
have chosen.


That purportedly works.  But I have always felt that the separate 
(sub)domain was cleaner from an MTA / email routing perspective. 
Particularly if you try to have user mailboxes (one domain) on an 
Exchange server and mailing lists (a different domain) on another server.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler v3

[Grant Taylor via Mailman-Users]

On 11/28/2018 02:39 PM, Jim Ziobro wrote:
I now realize that mm-handler would not be necessary if Mailman fully 
connected to Sendmail.  The Postfix connection looks very close.


Please elaborate on what you mean by "if Mailman fully connected to 
Sendmail".  Rather, how is Mailman not already connected to Sendmail via 
mm-handler?


Or is your goal to remove mm-handler and directly configure Mailman 
itself as what Sendmail refers to as a "Mailer"?


Note:  I'm assuming that mm-handler is configured as a Mailer and that 
Sendmail is using mailertable to route domain(s) that Mailman uses into 
Mailman via mm-handler.  -  I don't have any extra steps or intermediary 
Local Delivery Agents.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] OT - Smart .forward replacement?

[Grant Taylor via Mailman-Users]

On 11/25/18 1:03 PM, Lindsay Haisley (linode) wrote:

mail redirected through a .forward  will always fail SPF validation.


That is not always accurate.  It is relatively easy to configure an MTA 
to support Sender Rewriting Scheme, either for everything that is sent 
out or just things that don't originate from the system.


Thus a .forward is not guaranteed to fail SPF validation.  In fact, I 
would expect SPF validation to succeed on servers that are configured 
with SRS.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] OT - Smart .forward replacement?

[Grant Taylor via Mailman-Users]

On 11/24/18 10:17 PM, Jayson Smith wrote:

Hi,


Hi,

I've been using .forward to forward Email from some user mailboxes to 
other addresses. Normally this works just fine, but a few weeks ago a 
situation happened which demonstrates how it can be an epic fail. I had 
a Mailman/DNS problem after upgrading a lot of packages. A message came 
in, Mailman couldn't properly look up the DMARC policy of the sending 
ISP, didn't munge the From: and sent the message on its way, and of 
course the message was from AOL, just about everybody rejected it, I 
woke up to fifty-five bounce reports…and all those bounce reports were 
also forwarded to an Email account on an Internet by telephone service, 
where deleting them was extremely slow.


Oy vey.

What I'm looking for is possibly something that checks mailboxes from 
time to time, and forwards all incoming messages that meet certain 
parameters, taking care of DMARC difficulties along the way so the 
forwarded messages will be accepted by the remote servers. E.G. my mom 
uses that net by phone service, and would like to see Email which comes 
to her regular Email address, but doesn't want to spend time deleting 
Amazon order confirmations, Mailman moderation notices, and other 
routine, automated, or irrelevant messages. Does such a thing exist?


This really sounds like the job of an intelligent Local Delivery Agent. 
Procmail is (used to be) the quintessential LDA for unix.  I think 
Maildrop is a modern replacement.  I suspect that more complex mail 
stores have similar functionality.


In short, you configure the LDA to intelligently handle various messages 
and decide what to do with them.  You would likely want to filter 
messages matching one (or more) pattern(s) and then forward other 
messages matching, possibly with some form of munging.


It may be possible to press Mailman into this service by creating a list 
of one (or few) subscribers and relying on Mailman's filters / topics to 
decide who to deliver to.  But I feel like this is not what Mailman is 
designed to do and would likely be fraught with failure.



Thanks for any help,


You're welcome.  Good luck.

P.S.  Feel free to email me directly / off list if you want help with 
Procmail.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] GPG Sig parse error

[Grant Taylor via Mailman-Users]

On 11/01/2018 01:49 PM, Jim Popovitch via Mailman-Users wrote:
Apologies Grant it this is too much discussion of you :-) I'm only trying 
to get to the root of the issue.


No problem.

I'm using S/MIME, not PGP (GPG).

Let's see if this makes it through happier.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler support

[Grant Taylor via Mailman-Users]

On 10/31/2018 08:14 PM, Mark Sapiro wrote:

I think that would be good.


ACK

See my reply to Jim if you have opinions on how / when it's done.


See 


Intriguing.

My python is quite bad, but that looks like it reads from STDIN and 
writes to STDOUT.  Which I think is not directly compatible with milters.


But, it would serve as a starting place for a milter.

Sadly I don't think that will work as is for me.  I'm running Sendmail 
and would need a milter.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler starting version

[Grant Taylor via Mailman-Users]

On 10/31/2018 08:41 AM, Jim Ziobro wrote:

I am starting from the contrib directory file named:
     mm-handler-2.1.10
inside is line:
     $VERSION = '$Id: mm-handler 2.1.10 2008-04-14 00:00:00 $';

My goals:

  * patch upper/lowercase issue solved a decade ago
  * allow mail to postmas...@list.example.com to forward to the
    machine's postmaster.   This fix allows arbitrary personal aliases.
    (Support RFC-2142)


Jim,

I'm inclined to let you finish your changes and then add my changes to 
your finished version.  (Fewer changes in flight at the same time.)


Or would you like me to share what I have with you and you incorporate 
what you think is reasonable in your version?


One other feature that I'd like is to optionally save *all* bounce 
messages.  This is valuable for initial list creation.  Is that feature 
available elsewhere in mailman?


Assuming that all bounces pass through mm-handler, it should be possible 
to do something with a copy of them.  The trick is to recognize them. 
This is trivial to match RFC formatted Delivery Status Notifications. 
It's more problematic with other formats of bounces.


I would personally be inclined to forward the bounce, as an unmodified 
attachment, to the list owner, postmaster, or some other configured address.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler support

[Grant Taylor via Mailman-Users]

On 10/29/2018 09:22 PM, Mark Sapiro wrote:
The most up to date version is 
.
For some info on the differences between this and the original 
,
see the thread beginning at 
.


Thank you for the links Mark.

It looks like mine is based off of the original (or a close variant 
there of).


The version I'm running:

   $VERSION = '$Id: mm-handler,v 1.2 2002/04/05 19:41:09 bwarsaw Exp $';

mm-handler-5100:

   $VERSION = '$Id: mm-handler 5100 2002-04-05 19:41:09Z bwarsaw $';

It looks like the changes consisted of the following:

 - Changing how the sendmail binary is called ($SENDMAIL) to pass 
different options:

- Change the ErrorMode from m (mail back) to q (return code)
- Change the from to be the null reverse path.
- Set to never return a DSN.
- Sets outgoing DNS parameter to only return headers.
- Sets an outgoing envelope ID.
 - I extensively re-wrote / re-factored what was a simple multi-line 
print to use MIME:: modules to build a proper DNS with all three 
sections.  (The last section is just the headers b/c of the outgoing 
SMTP parameter.)
 - I tweaked the ADDR: label to return an SMTP error (553 5.1.1 
<$list\@$server>...) error message.


Let me know if you'd like me to port these changes to mm-handler-2.1.10.

I may do this anyway to be running a newer mm-handler*.

Aside:  I've often contemplated a milter that could hook into the Python 
pickles to optionally reject messages at SMTP time if a non-subscriber 
tries to send an email to a list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] mm-handler support

[Grant Taylor via Mailman-Users]

On 10/25/2018 09:22 AM, Mark Sapiro wrote:
Please make whatever changes you feel are needed and post them here, 
and I will include them in the next release.


What is the authoritative version / source of mm-handler?

I've got three different versions:

 - 2.1.10
 - 5100
 - modified form of an unknown version

I made some changes years ago to have mm-handler return a properly 
formatted DSN.  But I don't know what version it was based on.  As such, 
I can't submit patches.


I'd be willing to make similar changes to current and submit them if 
you're interested.


In hindsight I'd like to also add the Auto-Submitted: auto-generated 
header to the DSN.  And make sure it uses the Null Reverse Path.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/25/2018 04:03 AM, Stephen J. Turnbull wrote:
Let's be careful to distinguish between "DMARC" and the "p=reject" and 
"p=quarantine" policies.


Fair point.

(1) DMARC's reporting features *can* and *should* be used on all domains 
that send email, with very few exceptions.


Agreed.

(2) "p=reject" should never be used on domains that contain any 
non-transactional mailboxes (ie, mailboxes used as the From which might 
be reinjected into the mail system with changes).


I personally disagree.

I'll concede "SHOULD" in the typical sense that RFCs use it.  Thus my 
opinion is contrary to the recommendation.


This recommendation was actually in some early unofficial drafts or author 
discussions of RFC 7489, but doesn't appear to be in the Internet-Draft 
prepublication series, and it's definitely not in the published RFC. 
(I believe that keeping such verbiage out of the RFC is why the RFC is 
informational rather than normative.)


Odd.

Hey, did you really want to write that?  There's about a millennium of 
mail-RFC-writing and/or large site admin experience on the DMARC-WG.


Yes, I did.

I'm sure that people had the best of intentions.  I'm not trying to 
impugn anybody.  Mistakes happen.  Undesirable results happen.  A recent 
example that comes to mind is the renegotiation issue with a MitM on TLS 
1.2.


So, there's fundamental misunderstanding here somewhere.  DMARC depends 
on DKIM and SPF.  Neither can ensure that the *purported author domain* 
of an email can be authenticated when passed through a mailing list.


It's my understanding that one of the functions of DKIM was to allow 
messages to be forwarded, (with the body) unmodified, and still 
providing a high degree of certainty that (the signed portion of) the 
message was the same as it was submitted into SMTP.  (Assuming that the 
submission server did the DKIM signing and that it's the same domain as 
the purported sending email address.


I feel the need to pause for a moment and reflect on that assumption. 
As I type this, I realize that it's relatively easy to break that 
assumption without breaking DKIM.  …  Thus, DKIM itself can't "…ensure 
that the *purported author domain* of an email can be authenticated…"


I'm leaving that here in case it helps others who might have been 
confused by that fact like I was.


*The whole purpose of DMARC From alignment is to authenticate the author 
domain in the context of her message!*


Okay.

This is simply impossible, unless the signed portions of the message 
arrive at the destination *unchanged*, or the list is an authorized mail 
source of the author domain for SPF.


Agreed.

Much legitimate email *does* change them, however, and few lists 
cater exclusively to subscribers of the same administrative domain. 
(Of course getting list host IPs authorized as mail sources for all 
potential SPF-using posters would be a nightmare!)


You propose that mailing list should munge From (and in fact you've 
proposed that it should do so independent of DMARC, IIRC).


At a minimum, yes.  You could also state that I'm proposing regenerating 
a completely new and independent message, quite a bit more than munging 
a message.



AFAICS, this has three nasty effects (at least).

(1) It ensures that validation of From alignment of the actual author 
will *fail*, because the From header *must* be signed in DMARC.  (SPF is 
pretty useless in the context of mailing lists.)


Only if the From: header has the original sender's email address.  [1] 
If the From: header reflects the mailing list, there is no DMARC 
conflict with the original sender's domain.


[1]  I think it may be possible to move the email address into the human 
friendly portion of the address and replace the actual email address 
with that of the mailing list.  I.e.:


 From: Grant Taylor 

Becomes:

 From:  "Grant Taylor " 



It is my understanding that DMARC implementations are supposed to ignore 
the human friendly portion of the email address.  However I do not feel 
comfortable trusting that.  As such, I would likely alter the text that 
looks like an address in the human friendly portion to be something like 
this:


 From:  "Grant Taylor - gtaylor (at) tnetconsulting (dot) net" 



(2) It breaks all the quoting mechanisms in every existing MUA, which 
now instead of, e.g.,


     >>>>> Grant Taylor writes:

will insert

 >>>>> Grant Taylor  via Mailman-Users writes:


I don't know if I'd call that "broken" per say.  But I don't object to 
the point.



Some styles would look a little better, some worse.  All, gag me.


To each his / her own opinion.

This is imposing work on a lot of MUA authors, and it will be ongoing 
as mailing lists keep changing their munging styles.


I don't see how this imposes additional work on MUA authors.

Or are you suggesting that MUA authors alter what the M

Re: [Mailman-Users] ARC

[Grant Taylor via Mailman-Users]

On 07/25/2018 03:53 AM, Stephen J. Turnbull wrote:
That's not how "on behalf of" worked in practice.  What happened in April 
2014, was that a home business owner (HBO) would send a pile of completed 
order notices to intuit.com, and intuit.com would send an invoice to each 
customer on behalf of h...@yahoo.com, from h...@yahoo.com.


Will you please clarify what the SMTP envelope from and the From: header 
were in the example(s) that you're talking about?


I'm going to assume (for the sake of discussion or until corrected) that 
both the SMTP envelope from and the From: header were h...@yahoo.com.


HBO, of course, doesn't have a vanity domain, just a Wordpress or 
SquareSite (or even Facebook) home page.


~twitch~

Tens of thousands of invoices worth millions of dollars bounced off of 
personal accounts and tiny business owner accounts at Yahoo! and other 
receivers who take p=reject as a command.


I assume "bounced off of" means that the messages were rejected by 
receiving MTAs that honored Yahoo's (et al) p=reject DMARC configuration.


I'll argue that DMARC is designed to 1) detect such spoofed email 
forgeries and 2) enable Yahoo (et al) to publish what they would like to 
be done with such spoofed email forgeries.


Granted, all the rejected / bounced invoices are contrary to the 
behavior that many individuals wanted.


But this also enabled DMARC enabled receiving MTAs to detect and reject 
other less white hat spoofed email forgeries.


I assume that this detection and rejection of any email claiming to be 
from Yahoo that didn't actually originate from Yahoo is exactly what 
Yahoo wanted to happen.


I feel like this is saying "We want something to detect the bad guys and 
block them, but still allow the good guys to do the exact same thing as 
the bad guys."  That has never worked very well.


Note that if I were intuit.com's CISO, I would fight tooth and nail 
against the system you suggest, because it implies that I have DKIM 
private keys for all those subdomains owned by clients.


What would you want to see done, as Intuit's CISO, instead of what I 
propose?


My purpose of the sub-domain of the client's domain is to transition 
(some of) the trust of the client's domain to Intuit's sub-domain 
therein.  I.e. I trust ietf.org, therefor I'll also trust intuit.ietf.org.


It is possible for Intuit to use a completely separate domain, 
intuit-ietf.org.  But there is not the same implicit relationship 
between intuit-ietf.org as there is intuit.ietf.org.


The intuit.ietf.org sub-domain is a completely different DNS zone that 
has been delegated from ietf.org to Intuit for them to manage / 
administer / operate for the purpose of hosting requisite services for 
IETF to be a client of Intuit.


What would you rather see done?  Does it also convey trust the same way 
that intuit.ietf.org does?


Every spammer in the world would be trying to hack the server that has 
those keys.


Why does that need to be one server?  What if it's a separate VM per 
client?  (I'd personally like that and pay more for such separation as 
Intuit's client.)


Assume for a moment that they are separate VMs.  How does the security 
of Intuit running X number of VMs differ from X number of clients 
running a VM?


I would think that it would actually worsen security posture because I 
would assume that Intuit would have a better understanding because of, 
and more data from, the larger population of VMs to administer.


Who knows more about securing things:  The thousand different entities 
that run one (or few) instances of something, or the one (or few) 
entities that run many instances of said thing?



I could probably keep them out, but Lordy, the liability involved!


I would certainly hope that the company that I'm outsourcing financial 
transactions to could secure the systems that process money.  I'd really 
hope that they could also secure systems that only process email.  With 
the security of the former systems exceeding the security need of the 
latter systems.  One stringent security policy protects both sets of 
systems.


Less financially painful are the services that newspapers and tourist 
destinations provided (note past tense, they're mostly dead now) where you 
could sit at a terminal and send a "postcard" recommending an article or 
with a picture of the attraction to family and friends "from" yourself, 
including your email address, simply by typing name and address in. 
Not a huge loss, I guess, but 


I think that all of those systems were behaving badly.  I think that 
they SHOULD have been sending with something like this:


 From:  Uncle Sam (via My Picture Kiosk) 
 To:  Cousin Larry 
 Reply-To:  Uncle Sam 

 Hi Cousin Larry,

 Check out this cool picture!!!

 --
 Uncle Sam sent you this picture from the LAX airport.

I think anything that spoofs or otherwise pretends to send as someone 
they are not is a form of abuse.


I also believe this form of 

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:41 PM, John Levine wrote:
Quite right.  Beyond the standards theology, there is the practical 
problem that where the message list in your inbox used to tell you who 
wrote the list messages, now it all seems to come from the list alias.


That's where the human friendly portion of the From: header comes into play.

I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

This can show up in the index of a mailbox.

Or the two lines that I'm suggesting prefixing the body with.

 Grant Taylor  wrote the following:

Granted, that doesn't show up in the index of a mailbox.

Both methods tell you who wrote the message content.

Do you have any doubt about who wrote the first four lines of this 
message?  Does the fact that the From: header has my name (via 
Mailman-Users) cause you to believe that I wrote "Quite right.  … list 
alias."?


Or does the fact that there is quoting "> " change that?

In my world, some people's contributions are a lot more interesting 
than others,


Agreed.


and losing the info about who wrote what makes all lists less useful.


I'm not suggesting losing information about who wrote what.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:11 PM, Richard Damon wrote:

Do you understand how DMARC works?


Yes, I do believe that I do understand how DMARC works.

I have yet to have someone show me something (else) about DMARC that I'm 
not aware of.


Yahoo.com has an entry in their DNS that says they want DMARC protection, 
and if you can’t verify that the message came from them unmodified to 
reject it.


Yep.

I'm doing exactly that.

Unless the mailing list claims authorship of the message by changing the 
From: of the message (and thus making it hard to tell who really said the 
words), the list relaying the message with the slightest modification 
of the Subject or Body will cause it to fail DMARC, as DMARC says that 
the From: header is the king for verification.


I am talking about modifying the From: header such that the message no 
longer had any conflict with the original published DMARC records.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

Thus removing any conflict with any DMARC records published by 
tnetconsulting.net


Since the message is now from the Mailman-Users mailing list, it's 
perfectly possible to insert a line at the start of the message like the 
following:


 Grant Taylor  wrote the following:

Only if you think that mailman-users is the author of your message here, 
and that your mailing list is the proper author of every message that 
goes through your mailing list.


I believe that the Mailman-Users mailing list is the entity responsible 
for sending the message to each and every subscriber.  I believe the 
content that the Mailman-Users mailing list is sending is strongly based 
on content provided by someone that sent a message to said mailing list.


I know that the mailing list did not generate the content.  I also know 
that it is sending content heavily based on content from someone else.


Base SPF isn’t an issue. All messages leaving my mailing list pass 
SPF because I publish a SPF record, and the message have an envelope 
From of my mailing list.


What is (was) your (original) motivation for munging the envelope to be 
from the mailing list?  Are (were) you (originally) doing it because you 
want to take advantage of V.E.R.P.?  Or are (were) you (originally) 
doing it to avoid SPF issues?


I know a number of people that only started munging the envelope from 
address because of SPF issues.


You may also run into issues with SPF alignment with DMARC if you don't 
also modify the From: header.


(I can't tell what domain you are referring to.  I don't see SPF / TXT 
records for damon-family.org and I don't know if you are referring to 
some other domain.)


Again, I can verify the DMARC of the incoming message, but unless I want 
to claim authorship by changing the From, I can not send it and have it 
pass DMARC.


Which, IMHO, is what DMARC is supposed to be able to enforce.

Only if you consider the mailing list the Author of every message relayed 
by it.


I do consider the MLM as being the author / creator / submitter of the 
SMTP message.


I view the person that sent the message as being the author / creator / 
submitter of the body content in said SMTP message.


The MLM DOES change the Envelope from, it really wants to so it gets the 
bounces back so it can process it. That means the outgoing message can 
pass SPF as SPF is written. What it doesn’t pass is the modification 
to SPF that DMARC specifies that says that the only domain to validate 
in the inside From: Header, the Envelope doesn’t count.


Yep, VERP.

So you REALY want to see your view of the mailing list as EVERY message 
is ‘From’ Mailman-users, with no indication of who wrote really 
wrote the message? Thus you lose the ability to easily block


Not quite.

I would much rather have the human friendly portion of the address 
remain what was originally sent.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

I would also be interested in something like the following.

 From: Grant Taylor gtaylor at tnetconsulting dot net via 
Mailman-Users 


I believe that retains the attribution that I believe you (and many 
others) want to retain.


Seeing as how the new outgoing message is completely new, it's perfectly 
possible to add something like the following as the first two lines of 
the message:


 Grant Taylor  wrote the following:

So you don’t think mailing list should do any modifications to the 
message, or they need to claim authorship.


"DMARC says that if you get a message from me, it MUST have come 
straight from me"


The key being "it MUST have come straight from me".

Thus messages that pass through a mailing list (or forwarded in any way) 
fail the "come straight from me" portion.



So you see this thread as the mailing list arguing with itself?


I see this thread as a friendly / academic discussion from many 
different mailing list subscribers who send messages to and receive 
m

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:59 PM, Richard Damon wrote:

You CAN’T strip DMARC.


I can most certainly strip any DKIM related headers from messages that 
are coming into my server on their way to my mailing list.


I'm not talking about altering other people's view of DNS.  (That's a 
completely different topic.)


If a domain has activated DMARC for itself (via its DNS record) then it 
is telling all other domains in the world that any mail that says it is 
from this domain MUST pass the DMARC test.  This means that either it 
must be validly signed BY THEM or come from a server THEY have indicated 
is them. A setting of reject (which is what AOL and YAHOO use) indicates 
that other people are not to accept messages that appear to be from them 
that fail these tests.


Agreed.

I'm saying that the email server hosting the mailing list should strip 
DKIM (related) headers from messages before they go into the mailing 
list software.


I'm also saying that said email server should apply all the enforcement 
checks that you aptly described.




See above, a re-mailer that changes a message fails DMARC.


I believe the SMTP path between the originating sender and the mailing 
list is distinct and completely different from the separate SMTP path 
between the mailing list and subscribers servers.


I'm free to make any and all changes to the message as it passes through 
the mailing list as long as I do the following:


1)  Remove any and all security headers from messages going into the 
mailing list.
2)  I (re)add appropriate security headers to messages exiting from the 
mailing list.  Note:  These headers should reflect the mailing list and 
NOT the original sender.



See above


Hypothetical scenario:

Message from subscri...@aol.com comes into my email server hosting a 
Mailman mailing list.


1)  Apply all applicable filters (reverse DNS, SPF, DKIM, DMARC, Spam, 
Virus, etc) as early in the SMTP process as possible.  Reject (as 
appropriate) anything that fails respective tests.

2)  Strip all applicable security headers between the MTA and the MLM.
3)  Mailing list manager does it's thing, including munging the From: as 
it generates new messages that go out through the local MTA.

4)  Local MTA adds appropriate new security headers to the messages.

Note:  #4 absolutely MUST use data that reflects the local domain / 
sending server.


I still see nothing that prevents the MLM of doing anything and 
everything that it wants to do to the messages that pass through it.


Note:  There is ZERO association between the inbound message and the 
many outbound messages, save for body content being based on the 
original incoming message.


So you don’t see the problem with AOL and YAHOO changing there settings 
so that 99% of the discussion mailing list (guesings at percentage) are 
unable to deliver mail from subscribers who are AOL or YAHOO users, and 
if they try, they get back delivery errors that make the list software 
think that those users have bad email addresses and get unsubscribed 
for delivery errors.


I think your percentage is high.  I just don't know how high.  But that 
nuance doesn't really matter.


I see what was being done before (and some still do now) as a problem. 
A problem that pre-existed AOL and Yahoo or their use of DMARC.  They 
just happened to be early adopters that did a cannon ball into the 
otherwise relatively calm pool.


I believe that similar problems happened when people started using -all 
in their SPF records too.  Granted, VERP, which had been adopted by many 
mailing lists, altered that somewhat.


I view the equations as being the same, just with significantly 
different values in the variables.


Those other systems now have a very tough choice, don’t honor the DMARC 
setting, and thus allow forgeries from banks and such to go through, 
or honor it to the detriment of their customers trying to use mailing 
lists.


I believe that mailing lists (or their hosting MTAs) SHOULD do DMARC 
(and DKIM and SPF) filtering in as strict a manner as the purported 
sending domain desires.


Thus blocking the undesirable messages that you refer to.

When they first did this and the problems started, one solution that 
was being proposed was to just kick all AOL and YAHOO users off all 
mailing lists.


I do not believe that the problem started then.  It may very well be 
that it became well enough known as enough people were effected that 
people that didn't know about it before suddenly learned about it.


I believe the problem was known about before AOL and Yahoo implemented 
DMARC.


I feel like kicking AOL and Yahoo users off of mailing lists is an 
unnecessary Draconian knee jerk reaction.  Something that should be 
avoided at all costs.



The problem with DMARC is that it DOES attempt to protect end-to-end.


I obviously disagree.  Particularly on what the receiving "end" is.

If you view the message to am MLM as as separate end-to-end delivery 
process from the message from an MLM 

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:51 PM, Mark Sapiro wrote:
The stolen address books were used to send phishing emails purportedly 
from the owner of the address book the the addresses in the book.


I.e., a message From: a_known_fri...@yahoo.com saying things look at 
this great thing I found and a URL to evilsite.com.


Trivial to harvest addresses, but not trivial to know a known associate 
to send the mail From:.


I hadn't thought about the association of the metadata.  Thank you for 
clarifying.


I do question how much more spam was sent by stealing address books from 
large providers compared to viruses / malware doing the same with 
address books on infected machines.


In this context, the innocents are subscribers to mailing lists who 
find themselves unsubscribed by bounce processing because their ISPs 
reject list posts From: other_us...@yahoo.com and the operators of those 
mailing lists.


Indeed, unfortunately "friendly fire".  :-/

Of course, you seem to feel that these lists were wrong from the beginning 
for not claiming authorship of the posts by replacing the From: header,


Yes, that's in line with my current view.


but at the time, this wasn't even an option for most lists.


Lack of an option does not preclude the need for it.

Similarly, ignorance of an option does not preclude the need for it.

Admittedly, I've long struggled with how I thought discussion mailing 
lists should behave.  Originally I hadn't given any thought to munging 
the From: like is suggested for DMARC.  That being said, I did want to 
direct replies back to the discussion list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 03:16 PM, John Levine wrote:
Turning it on for aol.com, yahoo.com, and other domains with user 
mailboxes,


So, are you stating that DMARC should NOT be used on domains that 
(predominantly) contain end user mailboxes?



to outsource the pain of the spam they were getting


I'm not completely following you.  Are you referring to filtering of 
inbound email that AOL / Yahoo / etc. were having to do?  If so, I don't 
see how publishing DMARC effects that.  (I assume that they did not need 
to publish records to enhance filtering email from themselves.)  Or are 
you referring to "the pain" as being the push back / flack from the rest 
of the email industry for spoofed messages purporting to be from AOL / 
Yahoo / etc?



due to letting user address books be stolen.


I don't know about AOL's security posture, but I do have a little idea 
about how bad Yahoo's was.  -  I still don't know that I would say that 
they allowed it, as in welcomed it.


IMHO it has been trivial to harvest email addresses for a LONG time.  As 
such, I think that address books are simply a convenient list and not 
strictly related.  Please correct me if I'm wrong.


Right, thereby causing a great deal of entirely legitimate mail that 
DMARC cannot describe to go missing, along with a certain amount of spam.


"legitimate mail that DMARC cannot describe"  That sounds distinctly 
like a problem with the DMARC specification, /not/ with use there of.


Aside:  The (relatively?) recent conversion from analog TV to digital TV 
broadcasting in the US comes to mind.


I feel like DMARC requires a paradigm shift in how email is forwarded 
and handled by mailing lists.  (I'm sure there are some other uses that 
I'm forgetting.)  Much like the aforementioned conversion from analog TV 
to digital TV.


Or similarly the requirement for reverse DNS for mail servers.  Personal 
opinions aside, it seems as if the email industry has decided that 
requiring reverse DNS is a mostly good thing.  Or that the good 
(slightly) outweighs the bad.



We've been cleaning up their mess ever since.


I question if the mess is /really/ AOL's or Yahoo's doing, or if instead 
the problem was really related to (what I'm going to describe as) a 
questionable way of operating that we now must change to play well with 
DMARC.


Yes, they explicitly decided that the costs they imposed on innocent 
bystanders were Not Their Problem.


Please elaborate on what "the cost" is and entails.  Are you referring 
to anything more than the fallout of not being able to (easily) forward 
email in a DMARC compliant manner?


I suspect "imposed on innocent bystanders" and "not their problem" can 
also be used to describe requiring reverse DNS, SPF, and DKIM.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 04:25 PM, Richard Damon wrote:

What actions do you think mailing lists are doing improperly?


I personally believe that mailing lists are their own end entity, just 
like our individual mailboxes.  (Particularly discussion mailing lists.) 
 I also believe that SPF, DKIM, and DMARC are meant to protect between 
said endpoints; message submitter and terminal mailbox.


Thus I think that DKIM and DMARC should be stripped from messages prior 
to entering the mailing list.  The mailing list does it's thing.  Then 
DKIM and DMARC are applied anew to the messages as they leave the server 
hosting the mailing list.


Note, the subject modification is a long standing feature of mailing 
list, which is one thing that breaks DMARC, though I might be willing 
to give that up.


Mailing lists, as I view them, are free to mung messages to their hearts 
content in the paradigm that I use.


The modification of the message body to add a header or footer is also 
common, and in some places effectively required by law.


Agreed.

Such is perfectly compatible with my paradigm.

If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t 
have been quite as bad. But they ABUSED DMARC by their settings.


I still don't grok what you are considering "abuse" in this context?

Rather than speculating, please clarify what the abusive activity was.

By the design of DMARC, AOL and Yahoo should have informed their users 
that they were changing the Terms of Service of their email systems, 
and now all their users are effectively prohibited to use any form 
of re-mailing systems, including most forms of (external) mailing 
lists. Instead they just told the world, we aren’t going to follow 
the normal rules, you deal with it.


I have a different interpretation.

My understanding is that AOL and Yahoo leveraged DMARC to expressly 
identify messages that originated from AOL and Yahoo.  Or said another 
way, they leveraged DMARC to make it easy for receiving servers to 
identify messages that are not being sent from AOL or Yahoo servers 
/during/ that current SMTP transaction.


I feel the need to insert a nod towards the fact that postmasters are 
free to run their infrastructure the way that they see fit.


I also do not feel like the terms of service between AOL or Yahoo and 
their end users changed.


AOL and Yahoo simply published information to make it easier for the 
world to identify if messages in the scope of an SMTP session are coming 
from AOL or Yahoo servers.  They also published their desire for 
receiving servers to reject messages that don't pass said published 
information.


Did they do so knowing that there would likely be a problem with 
traditional .forward(ing) and mailing lists?  Quite likely.  Was an 
internal business decision made that publishing such information and 
dealing with the ramifications of .forward(ing) and mailing lists more 
important than allowing bad actors to continue pretending to be AOL or 
Yahoo?  Extremely likely.


IMHO AOL and Yahoo made a business decision.  Would you make the same 
business decision?  Maybe, maybe not.


Note:  Both AOL's and Yahoo's business decision works perfectly fine in 
my paradigm.


Yes, there is a fundamental issue with email that it is easy to 
spoof. Fixing it is going to be a significant issue, and possible a 
complete recreation of the system.


I don't see a specific need to recreate the system.

The issue is that to create such a new system is a major job. Such a 
redesign would need to look at ALL current uses and either decide that 
such uses were no longer valid or to accommodate them.


I am interested to see what others would propose that offers the same 
good points of our existing system (SMTP) without any (or at least 
fewer) bad points.


DMARC somewhat intentionally did not consider mailing list, because they 
didn’t have a good solution to handle them, and their intended usage, 
the protection of ‘valuable’ mail somewhat excluded the use of such 
services.


I think you and I have a fundamentally different view of what is being 
protected and not.


In my view, SPF, DKIM, and DMARC do a perfectly fine job of protecting 
messages between the sender and the mail recipient that they specify.


In your view (as I understand it), SPF, DKIM, and DMARC do a 
questionable job protecting messages between the sender and the ultimate 
mail recipient through an unknown number of intermediaries that may 
forward and / or expand to one or more other, different, recipients than 
the sender stated.


IMHO, much like STARTTLS protects a segment of the over all 
communications path between the sender and the ultimate recipient(s), 
SPF, DKIM, and DMARC only protect one portion.  And I happen to think 
that they do it well.


It basically required that any service that wanted to use DMARC needed to 
separate valuable protected mail from less valuable mail with different 
domains. AOL and YAHOO just decided to ignore that in their 

Re: [Mailman-Users] ARC, was non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 11:02 PM, Stephen J. Turnbull wrote:
You're misunderstanding.  The ARC community doesn't discourage 
whitelisting other sites.  The work to do whitelisting does.


Thank you for clarifying Stephen.  I was afraid that you were somehow 
implying that there was some sort of guideline on what sits should and 
should not implement ARC.  I didn't think that was what you were meaning 
to imply, but the doubt was there, hence the questioning.


Mailing lists are *known* to *frequently* (almost always) break DKIM 
signatures in a way amenable to repair by ARC.[1]


ACK

The other main pain points for DMARC are third-party services that 
are authorized by the owner of a mailbox to send mail "on behalf of", 
without participation of the adminstrator of the mailbox's domain. 
An example is invoicing services.  These do not benefit from ARC *at all* 
because they have a valid DKIM signature from the originating domain, 
who can be trusted for that service, but don't get such a signature from 
the mailbox's domain as required for DMARC From validation.


I hear and acknowledge what you're saying.

I would think / hope / expect that such services would be from a 
different (sub)domain of the client that they are sending email on 
behalf of.  I would also expect the from address to reflect the 
sub-contractor's (sub)domain with a Reply-To: directing replies to 
proper main (parent) domain.  (Or some mailbox associated there in.)  I 
would also expect to see some sort of verbiage stating that "This 
message was sent on the behalf of $Parent by $3rdPartyContractor."


I would also hope / expect to see some sort of linking text / 
acknowledgement from the parent that they have (sub)contracted some 
services to a 3rd party.


But, I learn more and more every day that I have different expectations 
than most people.


The other *possible* use case for ARC would be non-mailing list 
forwarding.  But these almost never break the DKIM signature of the 
originator.


They may not break DKIM.  But depending on how they operate, they may 
break SPF directly (re-sending with the original SMTP envelope From: 
thus violating SPF) -or- indirectly (re-sending with something like SRS) 
thus breaking DMARC alignment.


My understanding is that DMARC can be configured to require both SPF and 
DKIM alignment.  Maybe it's only for reporting and not for pass / fail 
tests.  I'd have to go back and re-read the specifics about DMARC again.


The point being that simple .forward(ing) may still break things.

I maintain that detecting such is one of the functional purposes of 
DMARC.  This is independent of is such benign or malicious.


I guess large services like GMail can eventually add a feature where a 
user can configure GMail to recognize and whitelist specific sites where 
they have mailboxes set to forward to GMail.  But I doubt this will 
ever be a standard feature of MDAs.  It will be complex and fragile to 
implement, and almost never used.


Agreed to both aspects.


Footnotes:
[1]  Note that I disagree somewhat with John.  I suspect that humongous 
providers like GMail, Yahoo!, and Microsoft will automatically accept 
ARC in the presence of a RFC 2369 List-* header, and blacklist on bad 
behavior, as they do now.  That's not perfect from a list admin's point 
of view---it requires a lot of resources to do that well, so small sites 
probably won't---but it's not too bad.


I question the wisdom of making processing of ARC conditional on RFC 
2369 List-* headers.  I mainly say this because there is nothing that 
prevents malicious actors from inserting (possibly bogus) List-* 
headers.  (Or lots of tiny lists of single recipients.)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 02:03 PM, John Levine wrote:
No, it was specified in full knowledge that it would break pretty much 
every mailing list on the planet if used on domains with human users, 
instead of its intended target of notices from robot domains like 
paypal.com.


I choose to believe the mailing lists were behaving improperly.

To me, DMARC (including SPF and DKIM) is a method to determine if a 
message is coming from the original source (or authorized delegate). 
Where email is a combination of the message data and SMTP transaction 
delivering said message.


That's why we have ARC, once AOL and Yahoo abused it to solve the problem 
they created when they let crooks steal their users' address books.


I assume you are referring to "DMARC" when you say "…abused /it/ to solve…".

I feel like AOL's and Yahoo's actions are just additional gas on the 
fire that has been burning for a long time.  The problem of bad actors 
spoofing message senders exists independently of AOL and Yahoo.  Did 
their (in)actions make the problem worse, probably.  Did they cause the 
problem?  No.  Did they exceed critical mass?  I don't think so.  Rather 
I think it was past the critical mass long before AOL and Yahoo fueled 
the fire.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] ARC, was non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 02:05 PM, John Levine wrote:

Every domain added to a whitelist like this involves manual work.


Yes.

Why would you waste time on domains that aren't likely to send mail with 
ARC headers?


I'm not suggesting wasting time on domains that wouldn't send ARC headers.

I'm questioning why domains that do use ARC headers that don't run 
mailing lists should not be white listed.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 04:59 PM, Phil Stracchino wrote:
Actually, mailing lists and other redistribution are among the places 
DMARC notably breaks.


Does DMARC actually break or otherwise behave in a manner contrary to 
it's specification?


I personally believe that DMARC (and SPF and DKIM) are doing exactly 
what they are supposed to do.


The problem is that they are doing what they are supposed to do when 
people want them to not do that.


I don't even consider this to be a false positive.  -  If someone trains 
a dog to bark constantly (alert) when they see someone approach with a 
gun, I believe that the dog is doing exactly what they are trained to do 
when an armed police officer walks up.  The dog is doing exactly what 
they were trained to do.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] ARC, was non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/21/2018 02:24 PM, John Levine wrote:
I know people working on whiteish lists to use with ARC, to say that 
these domain are known to host real mailing lists so you should believe 
their ARC assertions.


Is there some place that I can find out more about these people and / or 
their projects?


Aside:  What does hosting mailing lists or not have to do with believing 
their ARC assertions?  -  I would hope that the ARC white lists state 
that these senders are probably trust worthy, independent of mailing 
lists or not.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/20/2018 12:40 AM, Jayson Smith wrote:
Could either of these milter solutions linked previously be adapted for 
use as a Sendmail milter? I'd love to find something which would query 
Mailman about the status of a particular sender address at the RCPT 
stage of the SMTP transaction so spoofed mail can be rejected right 
away, however, this might not be possible for one reason or another. Any 
thoughts would be appreciated.


Have you tried using the alternate milters?  Postfix implemented 
Sendmail's milter protocol.  So I think they are directly compatible 
with each other.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 05:27 PM, Mark Sapiro wrote:
The problem is downstream has to trust me. If I'm gmail.com, I'll probably 
be trusted. If I'm msapiro.net, probably not. Python.org, who knows.


Yep.

I've not yet seen any indication that there will be any good way to 
establish this trust relationship, save for traditional 
Business-to-Business methods.  At least I'm not aware of anything more 
automatic.


Thus I question how useful ARC will be for small operators.  :-/



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 06:22 PM, Mark Sapiro wrote:
If Mailman is asked to remove or replace DKIM headers, the 
headers affected are DomainKey-Signature, DKIM-Signature and 
Authentication-Results.


Good to know.

Thank you for clarifying Mark.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 04:16 PM, Mark Sapiro wrote:
Mailman can be configured to remove DKIM related headers from 
incoming mail before sending.


ACK

I'm lumping various in as well, which I'm not aware of Mailman being 
able to remove.


Authentication-Results:

I think there are others that fall into the same category, but I don't 
recall them at the moment.


When first implemented, this was done unconditionally. There 
were strenuous objections, see the thread at 
, 
and removal was made conditional on REMOVE_DKIM_HEADERS which defaults 
to No.


ACK

The bottom line is that the DKIM standard (RFC 6376) says that invalid 
signatures SHOULD NOT be treated differently fro no signature, and people 
feel the invalid signature may have forensic value.


I agree that headers should not be modified between the sender and the 
recipient.  The catch is, I believe the mailing list is the recipient 
and a subsequent (re)sender of a very similar but different message.  As 
such, I think that DKIM (and related) headers in a message going to a 
mailing list are unrelated to DKIM (and related) headers in a message 
coming from a mailing list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 03:11 PM, John Levine wrote:
Well, you know, this is what DMARC is intended to address.  While DMARC 
checks on mail that has passed through mailing lists has all sorts of 
well known problems, doing DMARC checks on mail that arrives at a list 
server would be pretty benign.  It's pretty rare for the path from a 
user to the mailman server to do things that would cause DMARC fails.


Yep, that's what I was referring to.

If you want to reinvent DMARC, you could add an option to say that all 
submissions from me must have a DKIM signature or validated SPF from 
domain X, where X would usually default to the domain in your e-mail 
address.


I have no desire to reinvent DMARC (or DKIM, SPF, etc.).

I'd argue that it's best to:

1)  Do all the typical DMARC, DKIM, SPF, etc. filtering on email inbound 
to the mail server.

2)  Strip DKIM (related) headers from messages going into Mailman.
3)  ...Mailman w/ DMARC friendly settings...
4)  Apply new DKIM signatures as messages leave the mail server.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 11:44 AM, Robert Heller wrote:

All of which can be spoofed.


Yes.  Just about everything can be spoofed to some degree.  It really 
depends on what information the owner of the purported sending domain 
publishes and what filtering / consumption of said information the 
receiving server exercises.


I personally feel like Mailman, and many other similar things, should 
sit behind an external / edge SMTP server that does some of the heavy 
lifting and provides detection of and possibly protection against many 
spoofs.


Mailman does not make any checks of the "Received:" headers (where the 
bogosity of the other headers can be determined or can flag messages as 
containing possibly spoofed headers).


I agree that there is some data in the Received: headers that may 
indicate a problem.  But such information is difficult to consistently / 
reliably / accurately extract or parse /without/ false positives.  It 
can also be difficult to correlate information across headers and 
determine what should and should not be allowed.  Let's not forget that 
it's equally easy to spoof Received: headers as it is to spoof other 
headers.  }:-)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 06:16 AM, Robert Heller wrote:
I mean it does not check things like the Received: headers*by default*. If 
the email part of the From: header is a list member address, Mailman 
will consider that the mail is from that member and pass the message on 
to the list,*even if the From: header is spoofed*. I expect that this 
is what happening with the OP. It is a common spammer hack: somehow get 
a list of member addresses (or really hack a member's E-Mail accoung or 
PC and go from there).


Yes, Mail mail can be configured to check other headers, but this requires 
some configuration settings.


I have often wondered about enhancing Mailman, or augmenting it with a 
milter, to be able to test the SMTP envelope from, to, and body content 
against list parameters and be able to reject messages during the SMTP 
delivery transaction.


IMHO it's a bit more difficult to spoof SMTP envelope details and bypass 
SMTP level detections.  This does assume that the sending domain does 
publish the required info and that receiving mail servers actually 
filter based on that.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Spam Subscriptions

[Grant Taylor via Mailman-Users]

On 06/03/2018 04:11 PM, Mark Sapiro wrote:

Ban list regexps are case insensitive.


Thank you for the clarification Mark.


The fact that the ones I saw never had periods following the plus sign.


ACK



--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Spam Subscriptions

[Grant Taylor via Mailman-Users]

On 06/02/2018 09:29 PM, Mark Sapiro wrote:

I use this regexp in the GLOBAL_BAN_LIST

^[0-9a-z.]{8,}\+[0-9a-z]{4,}@gmail\.com$


Are you not looking for capital letters?

I can see how the period in the first class would work, but I don't see 
that in the second class.


What am I missing?



--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/31/2018 09:33 PM, incoming-pythonli...@rjl.com wrote:
I wrote scripts that read the list and generated a rule per network. 
It can be slow, but has worked reliably for many years.  Since it is a 
mailserver, performance has not been a big issue.  I am in the process 
of designing a replacement.  If you enter your list of networks  as a 
separate iptables list, then you only need to call that list when the 
traffic is on the relevant port(s), so you avoid traversing the list 
for other services.


*nod*

Thank you for sharing.

I've done something similar with IPSets and recently using routing with 
reverse path filtering.


I've found all of the above to be quite effective.



--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/31/2018 06:37 PM, incoming-pythonli...@rjl.com wrote:
Both are valid alternatives.  There may be performance advantages, 
to stopping attacks at the firewall level instead of higher up in the 
application stack.


Agreed, on both accounts.

Firewalls also have a tendency to protect multiple machines, not just 
one. (I'm referring to network appliance type firewalls, not host based.)


No, this is not security through obscurity.  It runs on a different 
port so I can add firewall rules that effect only mailman service and 
not other web applications.


Fair enough.

I need to give my users a url that they can easily remember.  It's too 
complex to have to give them urls with port numbers in them, and since 
this is not security through obscurity, it is not a problem.


Fair.


yes


*nod*

There are many ways to implement the same thing.  Before there were 
modules in the kernel for this, I simply pulled lists of address blocks 
out of databases and incorporated them into my IPtables lists.  There are 
better tools to do this today.


ACK

I'm curious, did you use IPSets or just a rule per network / IP?

It was unclear from the OPs initial posting whether it was a private 
or a public mailing list.  What I describe here probably would not be 
appropriate for a public list and the best solution there is probably to 
upgrade to mailman 3 if they need a more secure interface that is wide 
open to the public.  VPN and/or fwknop (which is primarily SPA though the 
older port knocking is still supported) are more suitable if you have 
a private list where user membership must be approved anyway and your 
moderators and admins might use these tools to have access to mailman, 
but the web GUI would be blocked from public access.


Certainly adding web server based username authentication sounds pretty 
cumbersome to me because users would have to login twice,


Maybe, maybe not.

I've seen applications that can re-use the web server's authentication 
mechanism.  This would likely be a code change to Mailman.  (I have no 
idea how big.)


though from a security standpoint it would help protect from 
vulnerabilities in the mailman web GUI.


;-)

There's no one answer to solving these problems.  I'm only sharing 
ideas that have worked for me.  The less of the public Internet that 
can apply brute force attacks on your web interface, the less likely 
you are to have a compromise.  Also, the less junk in your log files, 
the easier it is to monitor the logs.


Nope.  Hence my interest in what others have done and why the did it. 
I'm always interested in observing and hopefully learning.


I plan to go to mailman 3, but in the meantime I have minimal issues with 
attacks on my mailman GUI.  Maybe not the perfect solution for everyone, 
but it is effective.


If it does what you need it to and you feel comfortable maintaining it, 
then more power to you.




--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/31/2018 03:05 PM, Dimitri Maziuk wrote:
What exactly is it about mailman usernames and passwords that you are 
trying to protect with HTTPS?


I wasn't talking about Mailman usernames (email addresses) and 
passwords.  I was talking about the usernames and passwords for Basic 
HTTP(S) authentication.  As in authenticating to the web server and 
having it control who can access the Mailman Web UI.


There's always the fact that HTTPS (SSL/TLS) protects both sets of 
credentials.


I was replying to the original poster, Michael P., suggesting that 
HTTP(S)'s Basic Authentication can be used to protect the Mailman Web UI.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/31/2018 01:18 PM, Dimitri Maziuk wrote:

Yeah, I too once thought that was a good idea.


I'm not quite following you.  Are you saying that you now dislike 
HTTP(S) usernames & passwords specifically?  Or are you saying that you 
dislike hosting something yourself?


And then heartbleed came along, and our knee-jerk security department 
cut off everyone who hasn't patched in 24 hours -- at the gateway.


Problems happen.  It's how you (or the powers that be) respond to 
something that matters.


As Murphy would have it, I was traveling across the Atlantic and our 
other IT guy was driving across North America. And of course cut-off at 
the gateway meant no mail, no ssh, no way to know what happened and no 
way to fix it.


Yep.  Murphy and his law will get you when you least expect it or are 
least able to respond to it.


This stuff sounds like it's coming from the same security experts. 
Proper answer with those guys is don't run mailman. Export the subscribers 
and use it as CC list in Orifice'365: you can't go wrong with "industry 
standard".


I'm going to disagree with you there.  You most certainly can go wrong 
with "industry standard" or "what everybody else does".




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

I feel like I'm missing something and as such have some questions.

On 05/31/2018 11:42 AM, incoming-pythonli...@rjl.com wrote:

Depending on where your users are coming from, it might be easier to
limit access to the GUI using a firewall.


Why are you using a firewall instead of leveraging the web server's 
ability to filter by IP?



What I do, is to run the mailman GUI on a non-standard https port.


Okay.  (Additional) security through obscurity.  Sure.  I do similar 
with various things.


I then create webserver URL rewrites that redirect url access to that 
port.


Why?  I feel like this voids hiding the Mailman Web UI on an alternate port?

I use my firewall (IPTABLES), to control who can access the GUI.  If all 
of your users come from a LAN inside an office, you can easily restrict 
access to only those on the LAN.


Or is this purely so that you can protect the Mailman Web UI via the 
firewall without impacting other web resources running on the default ports?


I've also used thing like GEOIP, and other tools to limit access to 
specific countries or specific geographic areas or specific service 
providers.  Alot of attacks come from outside countries and limiting 
access substantially reduces attacks on my servers.


I've not messed with GeoIP filters in a long time.  I don't know how 
IPTables' GoIP feature set compares with Apache's / Nginx's GeoIP 
feature set.



You could also require users to use a VPN or fwknop in order to access
the GUI.  This is easy if your users already access your site over a VPN.


I can see a VPN for corporate users.  I think it's a high bar for most 
public mailing lists.  Maybe not for the (few) administrator(s).


I feel like port knocking is a REALLY HIGH BAR for most public mailing 
lists.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/31/2018 12:25 PM, Grant Taylor wrote:
IMHO the web server has a LOT more experience at user access control 
than most web applications. As such, I feel like the web server probably 
has a better handle on how to do it.


Apache (and I suspect Nginx) has the ability to use client side TLS 
certificates to authenticate the client to the server.  —  I have yet to 
see any Web UI leverage this.  —  It's built into the web server.  }:-)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How do I run 2.x mailman more securely?

[Grant Taylor via Mailman-Users]

On 05/30/2018 03:36 PM, Parker, Michael D. wrote:
I've been assigned the task of attempting to secure our current 
implementation of GNU MailMan.


One thing that I've not seen (or missed) in this thread is the idea of 
leveraging HTTPS usernames and passwords to protect the web interface.


IMHO the web server has a LOT more experience at user access control 
than most web applications. As such, I feel like the web server probably 
has a better handle on how to do it.


As for the default ugly username & password dialog box, there are ways 
around that.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] GDPR

[Grant Taylor via Mailman-Users]

On 05/22/2018 07:46 PM, Stephen J. Turnbull wrote:
Many posts will include their names in CCs, especially on lists that 
munge Reply-To.


Don't forget the munged reply.  }:-)

Some of these may be hidden (eg, Reply-To is normally not displayed; 
I don't know offhand if it's in the mbox files).


Yes, Reply-To: is a standard header and included in mbox files.

However, I think that what that clause means is not "all data items 
that mention you," but rather "what personally identifying information 
(PII) is stored," ie, name, email, postal address (.sig!), phone number 
(.sig!), blog and other website URLs, etc.  The right to be forgotten 
would imply at least redacting *all* instances of such PII.


Agreed.

If the archives are private, this is seriously problematic if it provides 
access to nonsubscribers who "are afraid" they were mentioned.  Do you 
really want a stalker trawling through your private lists just because 
somebody "might" have called him out by name?


Yep.  There are all sorts of implications here.

What "disproportionate" means will have to be decided by courts or 
further legislation (I'm not familiar with how this works in the EU). 
I suspect that a sed script redacting name, nickname, email addresses, 
SNS aliases, phone, postal address, and geographical address (perhaps 
even as minimal as city) will be the bare minimum expected for mailing 
list archives to the extent that they are covered by GDPR.


The technical implications of that in and of itself astound.

What if part of the data is wrapped across lines?  What if it's quoted 
printable encoded with =20 breaking sed scripts trying to deal with line 
breaks?  What if it's base 64 encoded?  What if it's hosted on an 
Exchange server (or something else that uses as massive SIS type DB)?


... trying to think about ways to do this ...
...
... failing ...
...
... giving up

Nope.  I want to NOT go there.

This could easily be thousands of posts in a long-running mailing list. 
Really, you'd want it done in bulk, using sed on an mbox or SQL on a 
database, rather than URL by URL in the HTML.


Wasn't it the owner of Lavabit that gave the master decryption key to 
the courts in tiny font printed on hundreds of pages of paper?  —  He 
complied with the court order, but did not make it easy.


Consider the example provided later in the thread of a private email 
forwarded to the list by a subscriber.  Through no action of their 
own, the private mail's author's PII was distributed over dozens (and 
in really extreme cases it could be 100s) of posts in a long thread.


Or if it's Gmail (or the likes) where the messages being replied to are 
hidden and perpetually added to in each reply.  *HEAVYsigh*


Anyway, as pointed out above, I'm pretty sure GDPR envisions *all* 
instances of PII being redacted.


It's my (mis)understanding that it's the right for $individual to be 
forgotten, which means anything and /everything/ that identifies them. 
Emphasis on "everything".


Because if it turns out later that that PII was found in your archives, 
you will definitely be considered guilty of negligence or worse.  You 
really cannot expect either users who want their PII redacted or courts 
to be at all sympathetic to the mailing list managers on this point.


I mostly agree.

I think there is some small room for good faith effort.  I.e. we found 
and removed 10,000 instances of $plaintiff's PII.  We're sorry for 9 
that we missed.  We've removed them and contracted with 
$external3rdparty to see if we missed anything.


The proverb, "the law is an ass", applies.  But that doesn't mean people 
of ill-will can't abuse it, and people in a panic (eg, stalking victims) 
may not care about your problems when they are literally at risk of 
being murdered if found out.


I would hope there is some small room

GDPR is not reasonable for mailing list operators who maintain archives, 
period.  The problem is not the intent of lawmakers, who mostly are 
horrified by the abuses that hackers have made of private information 
leaked from various databases, and want to address those problems as 
well as stalkers of various types.


I agree that it's black hat hackers that do a lot of the exfiltration. 
But I think it's more the B2B selling of information that causes more 
concern (to me) than what hackers do with it.


I think we've seen enough breaches here in the US (I'm not up on the 
rest of the world) where little if anything makes the news about what is 
done with our the outcome there of the leaked information.


I've heard more about businesses using contact info for marketing.

I follow someone on Twitter who was complaining about Yubico and Linode 
because they used his information from business consumer / contractual 
information for pure marketing purposes.  —  IMHO that's a breach of 
intended use of the information.  —  That being said, it's within the 
CAN-SPAM Act in that there is an established business relationship.


The problem is 

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/22/2018 07:33 PM, Stephen J. Turnbull wrote:
I would imagine that it is the subthread rooted at the first post 
containing complainant's PII -- "Personally Identifying Information".


I feel like that's a self referencing definition.

A "thread" is "a subthread rooted at the first post containing PII".

I agree that's where the focus should start.  But I don't think it 
defines a thread in the way that I'm asking.


What is their working definition of "thread"?

Let's say:

1)  Bla
2)   +--- Re: Bla
3)   +--- Re: Bla
4)   | +--- BlaBlaBla
5)   +--- Re: Bla
6) +--- I hijacked this thread because I need help!!!

Let's say the PII was in message 3 and the person replying to it in 
message 4 removed the PII.  Do messages 3 and 4 need to be removed (or 
otherwise modified)?


Let's say that message 1 had the PII, messages 2, 3, and 5 quoted it, 
but 4 did not and 6 is a hijacker that hit reply on the most convenient 
message (under his cursor) and removed all content.  Do messages 4 and 6 
need to be removed?


What is the "(sub)thread" that needs to be removed?

That is going to depend on the presence of PII in the messages.  If *whole 
messages* are to be deleted, that would presumably involve content that 
somehow identifies the person.  I would expect that we don't have to 
delete whole bug reports on this list just because somebody requests 
their PII be redacted.


I agree that it's possible to remove / redact PII without deleting the 
items containing the PII.


Think about it this way, spooks don't shred the entire sheet of paper, 
instead they take a black marker and redact just the pieces that need to 
be removed.


I'm afraid that the infinite wisdom of politicians will say that the 
entire paper needs to be shredded.


I think it also significantly depends on what needs to be redacted. 
Removing "supercalifragilisticexpialidocious" is a LOT different than 
removing "Grant Taylor" from the Mailman-Users archive. 
"supercalifragilisticexpialidocious" would be like reference to an 
event.  "Grant Taylor" would be any mention of my (or an impostor's) name.


The former is likely MUCH simpler to do than the latter.  The latter 
will also impact MANY more messages.


What worries me more is the implications for blockchain, or more 
precisely, DAG-based VCSes that use hashes for integrity check like git: 
the identity of commits will change if authors and emails are redacted, 
including if a commit log refers to PII of a bug reporter as they often 
do.  I guess you'd need to maintain an index of pointers from old commit 
ids, or at least for branches and tags (we do have the reflog in git).


I don't want to try to work that out.

And heaven help you if you're a security conscious group like the Linux 
kernel and use signed commits.  I guess the person who does the redaction 
would sign the new commits, but that's pretty yucky -- that person could 
do anything and nobody would know when it happened because you have to 
delete the old commits and blobs that get redacted.


Yep.

As I understand the "right to be forgotten", it's *not* a right to 
arbitrarily edit content stored by someone else, it's the right to redact 
*all* PII in that content.


Agreed.

In this case, I don't think that supercalifragilisticexpialidocious 
qualifies under GDPR's right to be forgotten.  }:-)


It's not just messages from a person, it's headers containing their name 
and email address, attribution lines for quoted material, quoted .sigs, 
etc etc.


Agreed.

What about headers containing message ID from an uncommon / single user 
domain like mine?  I'd say that anything that can be used to identify 
less than a group of 1000 people would probably need to be redacted.  (I 
just chose 1000 arbitrarily, but it's a starting point.)



You're missing

0)  Randos accessing public archives.


What other modes have we collectively missed?


For (0), the only logging would be IP addresses in the webserver.


True.

No.  The accessing IPs will be in the webserver logs, but I don't think 
there is any logging in either Mailman 2 or Mailman 3 of authentication 
data.  All there would be is the implication that authentication was 
successful if that data were accessed.


Okay.

I wonder if there's any correlation between the IP that authenticated 
and the IP that accessed data.


In Mailman 2 there's no PII data whatsoever except for email address 
and (maybe) display name in the subscriber data.


I expect that either of those, the email address -or- the display name 
are enough to count as PII.


I believe it's fair to say that people expect gtaylor (at) 
tnetconsulting (dot) net to reference a single person.  I also believe 
it's fair to say that most people expect most email addresses to 
identify be associated with one person.  The only exceptions to the rule 
being things like positional addresses; sales@ or info@ or webmaster@.


I suppose you could put phone #s and junk like that in the display name, 
but GDPR 

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/17/2018 02:56 AM, Bernd Petrovitsch wrote:

FWIW and IMHO, I think we are in violent agreement here.


:-)

In the old-school life: the sender (because s/he said it on her/his free 
will) - I hope;-).  But the person who overheard it may tell the story 
to a third person.  And it's just/only hear-say - even if it's actually 
100% correct (which it is almost never ever the case). And there starts 
actually the real "forgetting" or "doubts" ...


I agree that fan-out can be a problem.  IMHO the root cause is the 
person that said it, the sender.


But in a "everything is written" world, that is massively different: 
In the old-school world, a "written proof" had a quite large value 
because it wasn't trivial to have such a thing.  Nowadays - with almost 
every communication over the Internet - it's the normal, that there is a 
"written proof" aka recorded/logged/whatever.


That's an interesting point, but I'm not seeing who's at fault, the 
person who overheard what I said (the archive) or me for saying it in a 
non-secure manner (the sender)?


I'm not diving into differences of "how some judge may value some so- 
called proof" in some given (somewhat Western) country, but most people - 
even in Spring 2018 - don't realize, what's really going on and try to 
get back the world from the 1960s (or so;-) - well, "thinking before 
talking" was always a hard job;-)


True.

A court order may "force" you to not tell it to anyone but it can't make 
you forget it (or write it down and hide it somewhere safe).


Where force = order under some form of penalty, sure.

So in general: No. And that's exactly the problem with the "right to 
be forgotten".


:-)

Good ideas usually start to have problems when they are taken too far.

Of course.  But only for (somewhat obvious) very good (including legal) 
reason like really hard law issues like - at least in .at and .de - 
Nazi stuff and/or (everywhere I hope) certain forms of pr0n.


Even with those issues, the court can only order you, under some 
penalty, to not do something.  They still can't cause you to unsee or 
forget something.


At least I'm not aware of any such technology yet.  (My ignorance of 
such technology does not preclude it from existing.)


But for some claims of "please remove my email address?"?  If that email 
address can be found (via Google) on hundreds of sites, the removal of one 
instance doesn't change anything.  Ooops, and a chicken-egg problem 


I think it does.

IMHO it's the issue of multiple people doing the same wrong thing does 
not make the thing in question correct.


Case and point, is it wrong to ask someone specific to stop spamming me 
when considering that multiple other people could be spamming me?


Or, more along the lines of your example, saluting in a Nazi-esq manner? 
 (I'm not saying I agree with anything there in, I'm just using it as 
an example.)



That question should be answered by some copyright/authors right lawyer.


Hum.

I would be interested in what their take is.

I suspect it's going to come down to misrepresentation.  Either trying 
to falsely claim credit for someone else's work, or trying to attribute 
something to someone who didn't say it.


Short of significant persuation to the contrary, I'm going to continue 
to believe that admins / owners of system have the right to modify what 
was said in very specific cases when it comes to what enters / passes 
through / is stored on their systems.  IMHO this MUST be done in a 
manner that makes it clear that this was done.


Yes, and everyone writes that in the mailinglists charta (including 
that all mails go into a public archive, are never edited, censored, 
deleted, etc.).  Just from that point of view, everyone sending mails 
to the mailinglist has implicitly agreed to the rules including the 
publication in a Google-indexed archive.


I have some issues with that.

 - Corporate policy, regional laws, technical capabilities, etc. can 
conflict.

 - Agreeing to a E.U.L.A. does not mean that you actually understand it.
   (I'm hearing where this is being starting to be challenged in courts.)
 - Index ability is independent of publicity.

BTW: I cannot do everything I want with it because I cannot choose to 
plain simply ignore modification requests from a court.


Hence regional laws above.

Everyone can claim a lot of things - the hard question is how to proove 
it;-)


Yep.

Any serious business won't send me any "newsletters" if I request that 
without any legal backing (if only that I continue to buy from it in 
the future and don't tell anyone that they ignore such simple things - 
and because it's "just the right thing to do"(TM)).


Sadly, I've seen legitimate businesses fail and do exactly that.  Use 
contact details specifically for the contracted service inappropriately 
for marketing reasons.


Yup, but there are other companies or folks using selling addresses and 
other personal data (if only for "scientific purposes"[0]).


I feel 

Re: [Mailman-Users] GDPR

[Grant Taylor via Mailman-Users]

Duly noted.

On 05/15/2018 07:04 PM, Mark Sapiro wrote:
Actually, the easiest way is to just redact the cumulative 
LIST.mbox/LIST.mbox file and rebuild the archive with 'bin/arch --wipe' 
but that can have undesired side effects.


Doesn't that run the risk of renumbering messages, thus breaking 
existing links to messages?  Or at least disassociating them such that 
they link to the wrong message?




--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/15/2018 03:08 AM, Andrew Hodgson wrote:

What do I redact or remove in this instance?

- Personal details about the original poster and the event who had not 
consented to having their email posted to the mailing list;


I would likely have (presuming sufficient motivation):

1)  Get mailman into a state that I can safely modify the archive.
2)  Run a script (likely sed) to REDACT the contents.
  sed -i$ticketID 's/phone number/REDACTED/g;s/Eventbright 
Link/REDACTED/g;#etc'

3)  Restarted Mailman and possibly web server serving the archive.
(Or otherwise flushed caches.)

I quite like "REDACTED" as it shows that there was something, and that 
it was removed, but it does not show what that something was.


In the end I removed the phone numbers, her personal address and the 
Eventbright links from all messages, including some messages from other 
people where they had re-echoed the Eventbright links as part of their 
conversation to help other people.


Fair enough.


She wasn't very happy,


I doubt there was much more that you could have done.  She's free to be 
upset.  But she shouldn't be upset with you.  You did her a favor that I 
don't think you were strictly compelled to do.


but worse is the person who forwarded it to the mailing list refused to 
understand what they had really done and believed they had the right to 
send the post anywhere as they believed it was in the public domain.


*sigh*

I don't know what to say there.

I feel like that's between her and the event owner / organizer.

Just an example of the type of stuff that I may get asked to remove 
in future.


IMHO that is not unexpected, if not somewhat typical.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/15/2018 03:18 AM, Andrew Hodgson wrote:
At the moment the list administrator and moderator account is accessed 
via no username and a single password.  If that password is shared, 
I have no audit trail of who logged into the system.


ACK

I like to run Mailman (et al) administration pages behind htaccess 
protection.  Thus I have the username that authenticated to the web 
server to corroborate who's actually accessing things.


Also the system currently doesn't log specific access, for example admin 
A exported a load of addresses, admin B added 100 subscribers to the 
mailing list etc.


Can you not tell what was done based on the web server logs and the 
requested URLs?  I know that won't catch POST data, but it will give you 
more information than not looking at the web server logs.


Aside:  I personally consider the web server to be part of the 
application framework.  As such, I exercise and use it to (what I think 
is) my advantage.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/14/2018 04:11 PM, Bernd Petrovitsch wrote:

Seriously, these folks don't know what they imply.


Nope.  Politicians (almost) never fully understand what's going on.

And to be honest: If person X fullquotes and the email ends in an archive, 
who's fault is it?


Obviously the archive's (or more it's owners), not?


I don't think so.

Who's at fault in this scenario:  The person who overheard what I said 
(the archive) or me for saying it in a non-secure manner (the sender)?


Is there any legal method that I can use to compel a person to forget 
what they overheard me say?


For the author's rights side to it: I answer an email (and happen to 
quote just the relevant parts of other emails) to a public mailinglist 
with a public archive.


I don't think that the archive's admin or anyone else should have the 
right (let alone the duty) to edit or change my email in there - or even 
worse: remove it completely.


I disagree.

I believe that the admins / owners of the archive have the right to 
remove something from the archive (or prevent it from going into the 
archive in the first place).


I don't believe that admins / owners have the general right to modify 
what was said.


I do believe that the admins / owners have the right to modify what was 
said in very specific cases, like REDACTING something.  As long as they 
do so in a manner that is clearly identifiable that something was REDACTED.


After all, it is their system, they administer / own it and can do what 
ever they want to with it.


They should go out of their way to not misrepresent what you said / did.

They could also claim that your message was modified before it got to them.

Enter rabbit hole.

PS: The whole "right to be forgotten" idea is absurd per se - think about 
private archives (and I don't think about 3-letter organizations only). 
Can't we define the public archive to be an necessary and important part 
of a public mailinglist and be done with it?!  For almost everyone else, 
some "important reason" is good enough too.


I feel like the idea that you can compel someone to forget something is 
absurd.


I think you can compel businesses to no longer use your contact 
information.  —  Which is my naive understanding of part of what the 
spirit of GDPR is.


I can see a scenario where a company completely removes any and all 
traces of someone, then buys sales leads which contain said person, and 
ultimately contact said person again.  —  Is the company in violation of 
GDPR?  They did (and can prove *) that they removed the person's contact 
information and thus forgot about them.


Or should the company have retained just enough information to know that 
they should not contact the person again?  I.e. a black list.


(* Don't talk to me about proving the negative.  Assume a 3rd party 
oversight of some sort.)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/14/2018 04:02 PM, Ángel wrote:

IMHO they would mostly fail under §18 and GDPR wouldn't apply:


Okay.

What happens if a subsequent data breach (malware / infection) causes 
said individual archives to become public information?  }:-)


Of course, if a company was using the mailing list to process personal 
data, it should have been stated the whole time.


I half way suspect this happens much more commonly than you might think.

I've seen info@ or sales@ or the likes positional addresses be front 
ends for mailing lists (of one form or another) that redistributes the 
email to multiple (usually) internal (usually) employees.  I have never 
seen these types of expansion contacts disclosed as such.


Being nitpicky. What about sysadmins subscribed to this list as part 
of their professional activity ?


I know that this happens.  But I would argue that the SA should not 
subscribe themselves.  Instead there should be an additional monitoring 
email address specifically for that purpose.


I'd really like to see an intelligent Mailing List Manager have the 
ability to subscribe an address like this that is used as a feedback 
loop.  I.e. Did the MLM receive a copy of the message that it sent 
yesterday.  I'd assume that it would be something like 
<$list>-fbl@<$list_domain> to avoid recursive loops.


That would allow the MLM to self monitor and escalate if there's a problem.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/14/2018 06:33 AM, Andrew Hodgson wrote:
- Archive purge requests. We have discussed the same items as on the 
list to date.  I am looking at doing a simple grep for the relevant 
person's details and changing that.  The main reason for doing this is 
that if we just remove the author's messages they will be in a thread 
of other messages and our users typically don't remove quoted material.


ACK

This seems like the lowest common denominator.

Current advice from the GDPR people is we may have to delete the whole 
thread.


What‽

What is their working definition of "thread"?

Consider this scenario:  a LONG running thread and the person exercising 
their right to be forgotten simply adds a "me to" or an insult at the 
very end.


Does that thread, which obviously had a lot of value to the thread 
participants need to be deleted?


Why can't just the individual's message(s) be delete?  Or better 
redacted to not reflect them?


Still under discussion, this is also complex because threads and subjects 
change, if we delete the whole thread there may be messages from the 
same author in other threads that don't have correct atribution etc.


What does GDPR have to say, if anything, about subscribers having their 
own archives, which will not be redacted in any way?  —  Is the mailing 
list owner / administrator in any way, shape, or form, responsible for 
expunging those records too?


- Audit logs for data access.  it is not clear who is accessing 
subscription data for the list as there is just a single owner and 
moderator account.  Unsure if current logging data in either MM2 or MM3 is 
"good enough" for this.  MM3 may solve the issue about single accounts.


I guess I don't understand the problem and / or make invalid assumptions 
about MM.


I see six modes of access to the data:

1)  List subscribers
2)  List owners / administrators
3)  Host system administrators
4)  Administrators that are in the downstream SMTP / HTTP path and can 
track things.

5)  Backups.
6)  Ongoing Discovery.

I would expect that #1 requires authentication to MM for subscribers to 
see data, and I expect that this is logged in some (indirect) capacity.


I would expect that #2 would have access to the data as part of their 
role of owning / administering a mailing list.


I would also expect that #3 has the capability to access the data.  But 
I would also expect that #3 would not access the data in normal day to 
day operations.


Are you saying that GDPR is going to complicate things related to #3 and 
make it such that there is more of a union between #2 and #3?  I.e. 
exclude 3rd party site hosters from being able to be #3?


What say you / them about #4?

- Relevant people seem to be happy that running a discussion list not 
used for marketing purposes should exempt us from some of the marketing 
type rules regarding data processing.


What is their working definition of "marketing"?

Does someone saying "Hay, I've got a hand knitted blanket for sale, 
contact me directly if you're interested." count as marketing?  What 
about a news list from a library saying "Bob is managing the sale of 
used computer equipment."?  They both refer to items for sale and how to 
contact someone off list.


To be really ornery, what if Bob is the person exercising his right to 
be forgotten.  —  Can you simply redact his name & contact info?  Can 
you replace it with someone else's?  —  Or do you need to delete the 
entire thread and send out a new message / thread?


IMHO:  History happened.  (Some) People will remember (some) details 
(for a while).  Removing evidence of them does not mean that history did 
not happen.


- People seem happy with the system default logs as long as we can audit 
access to the logs (which we are able to as there is little access to 
the boxes themselves).


Please forgive me for questioning if all of your bases are covered.

Are #5 and #6 accounted for?  What about #4 downstream?  Or something 
like the NSA's PRISM program.


- Likely that I will have to move the lists to a host the charities 
control themselves and a separate host for each charity.  This will 
increase costs so we may need to look at an alternative solution like 
a hosted list service as I am not setting myself up as a list hosting 
business.


I understand why you say this.  But to me this is an unacceptable 
solution.  It certainly will not scale.


I fell like there should be a GDPR counterpart of reasonable level of 
effort in good faith.  —  I.e. redacting things in existing files and 
stating that backups are expunged after X number of days.  —  I'm 
perfectly fine responding to someone saying "I've REDACTED you from live 
files, and old backups will automatically expunge…" in a short time 
frame after the ""amnesia request.  Yet knowing that I can't mark 
something as completely resolved until after the backups do expunge.


I'm not quite sure what to do in a situation of a litigation hold that 
suspends expunging of 

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/12/2018 03:35 PM, Bernd Petrovitsch wrote:
Well, it's the very nature of an archive that everything stays there 
(similar to a backup).


Yes.  But I believe that GDPR has implications on expunging things from 
archives / backups too.  Not doing so is not within the spirit of 
forgetting someone.


The other aspect of a mailing list archive is that one can find it and 
may want to ask the original author something about the issue there.


Yes.  IMHO that's one of the wonderful things about public email archives.

On the other hand deleting the mail address (on the mail server side by 
the author) also kills that communication line.


I would rather have a GDPRed (read: anonymized) copy of a message than 
no message at all.


Consider if you will, someone publishing a How To for something quite 
rare, including all the necessary steps and minutia.  Then they 
subsequently leverage GDPR to be forgotten.  Would you want their how to 
to be removed (possibly taking the only / best source of said 
information with it) or simply anonymized so that it no longer reflects 
the sender?


I personally would STRONGLY prefer the latter.  The former causes 
destruction / loss of usable information that is not related to the sender.


One other thing: And if someone (as a current or former mailing list 
member) has the right to get the email address, name and signature removed 
in one mail, does the mailing list admin has the right to delete *all* 
the instances or only the actively requested/mentioned ones?  And what 
about other mail addresses of the same person?


My understanding of (the pertinent part of) the spirit of is that the 
person has the right to be forgotten.  Thus, I would think that any and 
all references to the person would need to be modified so that the 
person is forgotten.


So I do believe that means that the mailing list admin would have the 
obligation to modify all instances of the requester in the archive.


Now, this brings up a question:  Is the mailing list administrator also 
responsible for my private archive of messages that I received while 
subscribed to a mailing list they administer?


Does anyone know how the "blockckain is the solution to everything" 
faction handles these issues?  It's not that they can ignore that either 
- if only to discuss the question how personal the wallet address (or 
whatever it is called) is.


First, IMHO blockchain is NOT the solution to everything.  It is a 
technique that happens to be a buzzword.


Further, blockchain is specifically designed to detect modification. 
What is done when something is detected is likely implementation dependent.


Remember that blockchain is a LOT more than just crypto currency. 
Crypto currency happens to be a heavy user of blockchain because it is 
possible to detect modifications.


Blockchain can be used for a LOT of other things.  I've heard references 
to using it for system logs as a way to prove that logs have not been 
modified after the fact.  Or at least detect if they have been modified.


My understanding is that blockchain is meant to make the historical 
portion of what it's used for be immutable.  (Or detectable.)


Or can we kill the whole problem by using a blockchain for a mailinglist 
archive archive?


I think using blockchain for mailing list archives would be the wrong 
way to go.


1)  We have no motivation (problem that needs to be fixed) to migrate 
away from what's been used for decades.

2)  Moving to blockchain would be seen as an attempt to avoid GDPR.
3)  The attempt would quite likely fail in and of itself.
4)  The bad motivation would be known (see #1) and as such, invalidate 
any attempt to migrate to blockchain for mailing list archives.

5)  We would still need to have a way to delete things.
6)  We would likely get into trouble with GDPR for going out of our way 
to snub our faces at GDPR.


I think most uses of blockchain are bogus and I'm ready for the buzz 
word to go away.


I mentioned it because GDPR and blockchain are sort of antipodes when it 
comes to the right to be forgotten.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] [Mailman-cabal] GDPR

[Grant Taylor via Mailman-Users]

On 05/12/2018 02:39 PM, Stephen J. Turnbull wrote:
It would be a much more annoying matter if they claimed the right to be 
deleted from third party posts that quoted and identified them, though. 
If there is a "right to be forgotten" that impinges on mailing list 
archives, that seems plausible to me, though who knows what the High 
Court would rule.


I wonder if the entire post (and any partial / quoted copies) must be 
deleted or if it is sufficient to modify them so that they do not 
reflect the author but still retain (non-PII) content.  That would be 
less of a negative impact on archives.


God forbid if blockchain was used on the archive.  }:-)



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 'from' header at delivered email from inside / outside organization

[Grant Taylor via Mailman-Users]

On 04/19/2018 04:17 AM, kan...@yamachu-tokachi.co.jp wrote:

Hello Mailman experts,


I'm not an expert, but I've got questions.

I created a mailing list (i.e. a...@ml.abc.co.jp) with mailman in our 
organization.


I don't think it matters, but I want to make sure I'm not assuming 
anything incorrectly.


It looks like your Mailman list is configured in a sub-domain of your 
copmpanies main domain.  I'm assuming that means that email for the 
mailing list is routed to the server hosting Mailman independent of your 
main email server.  Correct?



Does anyone know how to configure mailman to achieve expected behavior?

Expected behavior:

a.	When a sender is outside of our organization (abc.co.jp), the 
received mail should show original sender's email address at 'from' 
header.


Okay.  No from header modification.

b.	When a sender is inside of our organization and receiver is 
outside of our organization, the received mail should show ML address 
(a...@ml.abc.co.jp) at 'from' header.


What from address should receivers inside the organization see from 
senders also inside the organization?  Do they need to see the real 
internal from header?  Or is it okay that they see the mailing list address?


If it's okay that internal recipients see the mailing list instead of 
the actaul internal senders, then the problem can likely be simplified 
to be "internal senders should have their from address rewritten to the 
mailing list address."


I want to know sender's email address if it's from outside our 
organization but do not want disclose employees' email address in our 
organization when they send emails to outside our organization.


This almost sounds like an MTA masquerading issue.  I don't know if 
mailman can help with this or not.  Especially if it's supposed to 
conditionally happen based on the sender and the recipient.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] (relatively) new DMARC issues - and Gmail

[Grant Taylor via Mailman-Users]

Have you considered sending your message to the Mailop mailing list?

I know that there are a couple of Gmail admins / coworkers that are 
subscribed to Mailop and will respond to issues like this.


Plus, it might also be a better forum and get more engagement / 
suggestions / gratitude by others learning from your toils.


On 03/31/2018 12:31 PM, Lindsay Haisley wrote:
At some point Amazon (amazon.com) started publishing a DMARC 
"p=quarantine" policy, which means that any email which gets redirected 
and hits my dmarc_shield piece is going to have its From address re- 
written to "postmas...@fmp.com" (fmp.com has a proper SPF record).


I'm sure that Amazon is just one of /many/ companies that are working 
with DMARC.  -  Seeing as how some ~> more governments are (going to be) 
requiring DMARC, I expect that we will see more of this.


I don't know what Gmail's policy is with regard to "p=quarantine" 
- whether it rejects such email outright or relegates it to the 
recipient's spam folder. I know that if the sending site publishes 
"p=reject", redirected email is refused by Gmail at the front door. 
I'll have to test the "p=quarantine" behavior.


I'm confident that Mailop subscribers can respond to this.

Here's the really annoying thing. My dmarc_shield processor rewrites the 
From header as per SOP for Mailman with the proper switch turned on. The 
From header address becomes "postmas...@fmp.com" with the original From 
address in the address comment (from xxx at yyz.com). If the email didn't 
already have a Reply-To address, the original From address is inserted 
as the Reply-To address. If a Gmail user replies to such an email, the 
reply goes to the Reply-To address, but Gmail **whitelists** the From 
address! Thereafter, any email which comes in with a munged From address 
is accepted, bypassing Gmail's otherwise pretty good spam filtering. I'm 
noticing a lot of spam email going out with From addresses for which 
a DMARC "p=reject" policy is published, which means that any such spam 
redirected to the Gmail user via FMP is also whitelisted. Bah! It's a 
fucking war zone out there!


I'm confident that Mailop subscribers can respond to this too.  Probably 
including reasons as to why something is done.


I speculate that it's to prevent abuse of meaningless addresses being 
used in the From: address and causing replies to go somewhere other than 
back to the (purported) sender.


The only possible solution here would be to randomize the username portion 
of the rewritten From address, which makes the email look more like spam, 
and the Gmail user would end up with a whole lot of useless whitelisted 
address which would need to be deleted. Not to mention the fact that 
FMP's mail server might be blocked from sending ANY email to Gmail.


I initially thought about something like an MD5 hash of the (purported) 
From address.  Though that still suffers from the multiple addresses 
being white listed.  Despite that, I'd consider forwarding from a 
"forwarding" (sub)domain.  Something to hopefully help articulate to the 
human looking at the complaints that the message is forwarded.  Plus 
this I would expect this to help differentiate email reputation for 
fmp.com from the (sub)domain used for forwarding.  (I don't know if a 
sub-domain would suffice or if it should be a different parallel / 
sibling domain, fmp-forwarding.com.)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Yahoo rejects

[Grant Taylor via Mailman-Users]

On 03/16/2018 07:54 PM, Grant Taylor via Mailman-Users wrote:

Has there been any noise about Yahoo on mailop about this new behavior?


I just read a handful of messages on mailop where multiple people are 
reporting this issue.


One of the last messages indicated that the problem might be clearing up.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Yahoo rejects

[Grant Taylor via Mailman-Users]

On 03/16/2018 01:57 PM, Jim Dory wrote:

-- Forwarded message --
From: MAILER-DAEMON@domain2.example
To: nome-announce-bounces@domain1.example
Cc:
Bcc:
Date:
Subject: Delivery failure
Message from domain2.example.
Unable to deliver message to the following address(es).

>:
This user doesn't have a domain2.example account (redacted1@domain2.example
) [0]


Okay.  That seems like a generic "non existent user" type response.


(I've snipped the address)


;-)


I got this delivery failure on perhaps 30 yahoo users over the last couple
days, and it is repeating. When I write to any of the users personally,
they respond that - yes, they are still there.


Okay.  So Yahoo is returning 5xy errors that make it seem like the 
recipient address is invalid for known good recipient addresses.


It sounds like some sort of filtering is either mis-behaving or poorly 
configured to me.


Has there been any noise about Yahoo on mailop about this new behavior?



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] How to remove "cc" of sender but retain "sender"?

[Grant Taylor via Mailman-Users]

On 03/08/2018 05:22 PM, Richard Johnson wrote:
(1) set the "From" as the list address, while also (2) NOT including 
the sender in to any "CC" list, and instead including the sender in a 
"Sender" header.


That really sounds like something that I would tackle with Procmail or a 
specially written filter (Perl or Python).


1)  Extract and save the From:.
2)  Remove all To: / From: / CC: headers
3)  Add a new To: set to the list.
4)  Add a new Sender: set to the saved From:.

Aside:  I'd likely also remove other headers that tend to break things, 
like DKIM* / Authentication* / et al.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org