ople will stop using / supporting them.
Do what you think you need to do. But please think about it at least
one more time before you stop supporting these addresses.
--
Grant. . . .
--
Mailman-Users mailing list -- mailman-users@python.org
To
ion 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
-
x27;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-User
en 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.or
th 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 li
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
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
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
ich 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
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
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
(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 Cry
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.
--
Gr
y 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 w
hance 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 m
ield 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.
--
Gr
going 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 Sign
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
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/lis
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
smim
gely 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
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 a
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.
twork
(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.)
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.
ately, there are quite a few comcast.net users
on this list, making this really difficult to find the offender.
Oy vey!
Do any of you have any ideas for me to identify this serial
'mark-as-spammer'?
Are you using VERP?
I would think that the VERP data would survive Comcast's re
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
w 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
smi
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 mailin
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:
re
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
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
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/ma
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:/
nnections.
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
Descri
s 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 Cry
cal 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.
--
. 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
ut 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/mai
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.
l 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. . . .
uni
is 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 Cryptograp
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
-
..@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
D
lly 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
P 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
--
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-
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?
--
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.
main(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
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 Sign
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
-
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. .
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.
--
Gra
d 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/list
age.
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
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.pytho
m: 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 ac
gService in
place of ClamAV.
N.B. By "intended," I mean to admit that my wording in the previous post
strongly suggested that they would start with the assumption that mail
is benign until proven otherwise. I can't fault you for taking my words
literally. :-)
Thank you
rtion 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 do
shed 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 t
ity
is that some types of email can reasonably use some techniques that are
just not appropriate for others due to the type and use of that email.
I disagree.
--
Grant. . . .
unix || die
--
Mailman-Users mailing list Mailman-Users@python.o
unging
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/listi
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.
il
aren't eligible to the same level of protection as other services
(non-humans) because we as email administrators can't figure out how to
make things work in a way that supports both.
--
Grant. . . .
unix || die
--
Mailman
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
r
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
C 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/listi
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@
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
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 Arch
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-U
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
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: h
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://mai
ly 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. }:-)
--
Gran
t 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
--
Mai
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
ssing?
--
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:
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
M
an 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
--
tication 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
Securi
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://wi
n 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 pu
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
ce.
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. . .
ith the scams currently being promoted that ban
subscriptions or even commercial transactions simply because the IP
address is allocated to Europe.
Agreed.
I think multiple court cases here in the US have shown that an IP
address is not PII. It's a contributing piece of information
hat 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 arch
d mailinglist archive in HTML
actually subject to the GDPR? It's not that is really structured and/or
organized like e.g. some SQL- database.
I think that any data collection / aggregation is likely going to be
subject to GDPR, for bet
, 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/listinf
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
---
ation 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://
m.
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
-
e 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 pr
I'm sorry if I am. I'm
simply bringing up things that I think are potential concerns that the
powers that be probably need to consider, and have a pat response to.
--
Grant. . . .
unix || die
--
Mailman-Users mailing list Ma
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
---
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.
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
warded. 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
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
1 - 100 of 342 matches
Mail list logo