Mailman-Users March 2017

mailman-users@python.org

38 participants
48 discussions

Re: [Mailman-Users] Unable to send emails with mailman/postfix
by Adam Goldberg 07 Mar '17

07 Mar '17

Check your firewall settings on the VM. You may need to open up 25. Adam Goldberg 202-507-9900 On Tue, Mar 7, 2017 at 11:49 AM -0500, "Scott Jones" <sjones(a)scisat.ca<mailto:sjones@scisat.ca>> wrote: Hi Mark, I've managed to forward port 25 to my VM. I am still not receiving messages sent from my gmail address (on the list) to the mailing list. The only other thing I've learned is that I can send mail to that same list from the command line with 'mail -s', which leads me to believe postfix is OK. Thanks for all of your help, Scott On Mon, Mar 6, 2017 at 4:08 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 03/06/2017 01:01 PM, Scott Jones wrote: > > > > Just as a recap, I'm currently running mailman on a Ubuntu VM hosted on a > > Ubuntu server. Perhaps then I need to forward port 25 to the VM somehow? > I > > did have this working fine from hard disks, but with some server troubles > > we wanted to keep mailman more self-contained. > > > Yes. That is your issue. You need port 25 connects to the host server to > forward to Postfix on the Mailman VM. If your VM has its own IP address > and DNS, this isn't an issue, but if DNS for the MX points to the host > server, it needs to forward that port to the VM. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > ------------------------------------------------------ > Mailman-Users mailing list Mailman-Users(a)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/ > sjones%40scisat.ca > ------------------------------------------------------ Mailman-Users mailing list Mailman-Users(a)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/adam%40agp-llc.com

1 0

Possible to get list mbox archives anywhere?
by Brett Delmage 06 Mar '17

06 Mar '17

I unsub'd from the list from 2015-07-05 through 2016-12-15. I'm admining Mailman again and it would be nice to have a local archive I could search through quickly for answers. Ya, I know the list web archives are searchable... Can anyone connect me with a list archives (mbox format) I can fill the hole in my local list archives with? Thank you! Brett

2 1

delay on mailman sending out messages
by Bruce Harrison 06 Mar '17

06 Mar '17

2 1

delays in mailman sending out email
by Bruce Harrison 06 Mar '17

06 Mar '17

I'm running Mailman 2.1.7 In the past month or two. I'm seeing Mailman delaying sending out messages. In the logs I see where it's posted, then in /var/logs/maillog I see sending start immediately and then somewhere along the line a delay of an hour or two, then it finishes sending. Or it delays initially then starts sending. This hasn't been happening in the past. We in the process of moving a lot of our mail users to O365 Not sure what's going on or how best to troubleshoot. Any ideas? Bruce Harrison Univ of Tennessee at Martin Post Log Mar 03 13:34:57 2017 (1223) post to information from munger(a)utm.edu<mailto:munger@utm.edu>, size=37061, message-id=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, success log /var/logs/maillog Mar 3 09:11:23 mailman sendmail[17197]: v23FBNsO017197: from=<munger(a)utm.edu<mailto:munger@utm.edu>>, size=35583, class=0, nrcpts=1, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=mail-dm3nam03lp0023.outbound.protection.outlook.com [207.46.163.23] Mar 3 13:34:56 mailman sendmail[22801]: v23JYu9r022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=150, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:34:56 mailman sendmail[22801]: v23JYu9s022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=500, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:34:57 mailman sendmail[22801]: v23JYu9t022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=500, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:34:57 mailman sendmail[22801]: v23JYu9u022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=500, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:34:57 mailman sendmail[22801]: v23JYu9v022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=8, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:34:57 mailman sendmail[22801]: v23JYu9w022801: from=<information-bounces(a)mailman.utm.edu<mailto:information-bounces@mailman.utm.edu>>, size=37061, class=-30, nrcpts=7, msgid=<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Mar 3 13:35:02 mailman sendmail[22811]: v23JYu9v022801: to=<trinitypresb(a)frontiernet.net<mailto:trinitypresb@frontiernet.net>>,<mcochran(a)wljt.org<mailto:mcochran@wljt.org>>,<khicks(a)utfcu.org<mailto:khicks@utfcu.org>>,<trinitypastor(a)frontiernet.net<mailto:trinitypastor@frontiernet.net>>,<mshumake(a)wljt.org<mailto:mshumake@wljt.org>>,<mnperry(a)comcast.net<mailto:mnperry@comcast.net>>,<mreese(a)wljt.org<mailto:mreese@wljt.org>>,<mfield(a)charter.net<mailto:mfield@charter.net>>, delay=00:00:05, xdelay=00:00:05, mailer=relay, pri=331061, relay=xmail.utm.edu. [10.51.0.154], dsn=2.0.0, stat=Sent (<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>> [InternalId=7717462] Queued mail for delivery) Mar 3 13:35:02 mailman sendmail[22805]: v23JYu9s022801: to=<thibbard(a)utm.edu<mailto:thibbard@utm.edu>>,<clovette(a)utm.edu<mailto:clovette@utm.edu>>,<dahender(a)utm.edu<mailto:dahender@utm.edu>>,<mbrooks(a)utm.edu<mailto:mbrooks@utm.edu>>,<afulle14(a)utm.edu<mailto:afulle14@utm.edu>>,<kroudenb(a)utm.edu<mailto:kroudenb@utm.edu>>,<bjohnson(a)utm.edu<mailto:bjohnson@utm.edu>>,<ndavis(a)utm.edu<mailto:ndavis@utm.edu>>,<jimerson(a)utm.edu<mailto:jimerson@utm.edu>>,<sburliso(a)utm.edu<mailto:sburliso@utm.edu>>,<thutche2(a)utm.edu<mailto:thutche2@utm.edu>>,<hchen38(a)utm.edu<mailto:hchen38@utm.edu>>,<nashbaug(a)utm.edu<mailto:nashbaug@utm.edu>>,<mparish1(a)utm.edu<mailto:mparish1@utm.edu>>,<jjohn275(a)utm.edu<mailto:jjohn275@utm.edu>>,<tgallien(a)utm.edu<mailto:tgallien@utm.edu>>,<sgoldmon(a)utm.edu<mailto:sgoldmon@utm.edu>>,<agardner(a)utm.edu<mailto:agardner@utm.edu>>,<ddietrich(a)utm.edu<mailto:ddietrich@utm.edu>>,<jfishe37(a)utm.edu<mailto:jfishe37@utm.edu>>,<ahuffma2(a)utm.edu<mailto:ahuffma2@utm.edu>>,<kwheel19(a)utm.edu<mailto:kwheel19@utm.edu>>,<lmccurley(a)utm.edu<mailto:lmccurley@utm.edu>>,<kelmwhit(a)ut.utm.edu<mailto:kelmwhit@ut.utm.edu>>,<khammond(a)utm.edu<mailto:khammond@utm.edu>>,<jscott61(a)utm.edu<mailto:jscott61@utm.edu>>,<aricha54(a)utm.edu<mailto:aricha54@utm.edu>>,<rpruit10(a)utm.edu<mailto:rpruit10@utm.edu>>,<ewheeler(a)utm.edu<mailto:ewheeler@utm.edu>>,<lgibson(a)utm.edu<mailto:lgibson@utm.edu>>,<shalkias(a)utm.edu<mailto:shalkias@utm.edu>>,<akeller(a)utm.edu<mailto:akeller@utm.edu>>,<phewitt(a)utm.edu<mailto:phewitt@utm.edu>>,<dabel(a)utm.edu<mailto:dabel@utm.edu>>,<dryan11(a)utm.edu<mailto:dryan11@utm.edu>>,<jdavis(a)utm.edu<mailto:jdavis@utm.edu>>, [more], delay=00:00:06, xdelay=00:00:06, mailer=relay, pri=15091061, relay=xmail.utm.edu. [10.51.0.154], dsn=2.0.0, stat=Sent (<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>> [InternalId=7717459] Queued mail for delivery) . . . Mar 3 13:35:30 mailman sendmail[22805]: v23JYu9s022801: to=<jjones98(a)utm.edu<mailto:jjones98@utm.edu>>,<pwatkins(a)utm.edu<mailto:pwatkins@utm.edu>>,<dmccull1(a)utm.edu<mailto:dmccull1@utm.edu>>,<dwilliams-boyd(a)utm.edu<mailto:dwilliams-boyd@utm.edu>>,<jbyrd24(a)utm.edu<mailto:jbyrd24@utm.edu>>,<ajohn171(a)utm.edu<mailto:ajohn171@utm.edu>>,<jgoyret(a)utm.edu<mailto:jgoyret@utm.edu>>,<sholt(a)utm.edu<mailto:sholt@utm.edu>>,<mgibson(a)utm.edu<mailto:mgibson@utm.edu>>,<jhende33(a)utm.edu<mailto:jhende33@utm.edu>>,<bgiles(a)utm.edu<mailto:bgiles@utm.edu>>,<lwarren(a)utm.edu<mailto:lwarren@utm.edu>>,<mtraynom(a)utm.edu<mailto:mtraynom@utm.edu>>,<blee37(a)utm.edu<mailto:blee37@utm.edu>>,<jjohn324(a)utm.edu<mailto:jjohn324@utm.edu>>,<rjones(a)utm.edu<mailto:rjones@utm.edu>>,<sdyer(a)utm.edu<mailto:sdyer@utm.edu>>,<sperry19(a)utm.edu<mailto:sperry19@utm.edu>>,<djorda19(a)utm.edu<mailto:djorda19@utm.edu>>,<cposadny(a)utm.edu<mailto:cposadny@utm.edu>>,<tharri70(a)utm.edu<mailto:tharri70@utm.edu>>,<gfelts(a)utm.edu<mailto:gfelts@utm.edu>>,<cnichols(a)utm.edu<mailto:cnichols@utm.edu>>,<jlavalle(a)utm.edu<mailto:jlavalle@utm.edu>>,<jschomme(a)utm.edu<mailto:jschomme@utm.edu>>,<volds(a)utm.edu<mailto:volds@utm.edu>>, delay=00:00:34, xdelay=00:00:06, mailer=relay, pri=15091061, relay=xmail.utm.edu. [10.51.0.154], dsn=2.0.0, stat=Sent (<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>> [InternalId=7717507] Queued mail for delivery) Mar 3 14:41:17 mailman sendmail[24288]: v23JYu9w022801: to=<chaamerw2000(a)yahoo.com<mailto:chaamerw2000@yahoo.com>>,<jesse.kowalewski(a)sodexo.com<mailto:jesse.kowalewski@sodexo.com>>,<kevin_mclemore(a)hotmail.com<mailto:kevin_mclemore@hotmail.com>>,<msudzum(a)worldtrav.com<mailto:msudzum@worldtrav.com>>,<njanemiller25(a)gmail.com<mailto:njanemiller25@gmail.com>>,<sully12980(a)aol.com<mailto:sully12980@aol.com>>,<vlhiggs(a)gmail.com<mailto:vlhiggs@gmail.com>>, delay=01:06:20, xdelay=00:00:02, mailer=relay, pri=481061, relay=xmail.utm.edu. [10.51.0.154], dsn=2.0.0, stat=Sent (<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>> [InternalId=7719913] Queued mail for delivery) Mar 3 14:42:43 mailman sendmail[24288]: v23JYu9r022801: to=<dsimmons(a)utm.edu<mailto:dsimmons@utm.edu>>,<emoser(a)utm.edu<mailto:emoser@utm.edu>>,<epritch2(a)utm.edu<mailto:epritch2@utm.edu>>,<ereed21(a)utm.edu<mailto:ereed21@utm.edu>>,<esimmons(a)utm.edu<mailto:esimmons@utm.edu>>,<espivey(a)utm.edu<mailto:espivey@utm.edu>>,<ewhite38(a)utm.edu<mailto:ewhite38@utm.edu>>,<ffackler(a)utm.edu<mailto:ffackler@utm.edu>>,<gbrown(a)utm.edu<mailto:gbrown@utm.edu>>,<geckert(a)utm.edu<mailto:geckert@utm.edu>>,<gibson(a)utm.edu<mailto:gibson@utm.edu>>,<hknox(a)utm.edu<mailto:hknox@utm.edu>>,<jash5(a)utm.edu<mailto:jash5@utm.edu>>,<jclark(a)utm.edu<mailto:jclark@utm.edu>>,<jdonal11(a)utm.edu<mailto:jdonal11@utm.edu>>,<jesbensh(a)utm.edu<mailto:jesbensh@utm.edu>>,<jforsyt5(a)utm.edu<mailto:jforsyt5@utm.edu>>,<jgreenwood(a)utm.edu<mailto:jgreenwood@utm.edu>>,<jhahn(a)utm.edu<mailto:jhahn@utm.edu>>,<jjone239(a)utm.edu<mailto:jjone239@utm.edu>>,<jlamb5(a)utm.edu<mailto:jlamb5@utm.edu>>,<jlongac1(a)utm.edu<mailto:jlongac1@utm.edu>>,<jmack(a)utm.edu<mailto:jmack@utm.edu>>,<jmathern(a)utm.edu<mailto:jmathern@utm.edu>>,<jonrmitc(a)ut.utm.edu<mailto:jonrmitc@ut.utm.edu>>,<jstreet7(a)utm.edu<mailto:jstreet7@utm.edu>>,<jyocum(a)utm.edu<mailto:jyocum@utm.edu>>,<kcurrie(a)utm.edu<mailto:kcurrie@utm.edu>>,<kelliot4(a)utm.edu<mailto:kelliot4@utm.edu>>,<kericson(a)utm.edu<mailto:kericson@utm.edu>>,<kevans31(a)utm.edu<mailto:kevans31@utm.edu>>,<khealy(a)utm.edu<mailto:khealy@utm.edu>>,<kprzybeck(a)utm.edu<mailto:kprzybeck@utm.edu>>,<krimfuhs(a)ut.utm.edu<mailto:krimfuhs@ut.utm.edu>>,<kwill126(a)utm.edu<mailto:kwill126@utm.edu>>,<ldavis(a)utm.edu<mailto:ldavis@utm.edu>>,<learls(a)utm.edu<mailto:learls@utm.edu>>, [more], delay=01:07:47, xdelay=00:00:05, mailer=relay, pri=4771061, relay=xmail.utm.edu. [10.51.0.154], dsn=2.0.0, stat=Sent (<320E686FEA4720449A309FC08FC6F49D01023D575A(a)EXCH2010MBOX2.utm.edu<mailto:320E686FEA4720449A309FC08FC6F49D01023D575A@EXCH2010MBOX2.utm.edu>> [InternalId=7719987] Queued mail for delivery)

1 0

add_virtualhost with single argument
by Greg Sims 06 Mar '17

06 Mar '17

I completed a migration to a new server over the weekend. We were able to send all the needed email this morning so the basics are in place. I reviewed mm_cfg.py in the migration process. I found some add_virtualhost statements that I am not sure do anything. I would like to delete them if this is the case. Here is one of them: add_virtualhost('lists.raystedman.org') It appears that mailman needs to understand the mappings between url and email per: # "add_virtualhost(urlfqdn, emailfqdn)" to add new mappings. What does having an add_virtualhost with only one parameter mean to mailman? What would happen if I were to delete the add_virtualhost above? Trying to clean things up along the way. Thanks, Greg

2 1

Re: [Mailman-Users] Unable to send emails with mailman/postfix
by Mark Sapiro 06 Mar '17

06 Mar '17

On 03/06/2017 10:33 AM, Scott Jones wrote: > > The Google message is just the bounce back I receive informing me that > the message could not be delivered. It seemed to be pointing me toward > an smtp problem. The virtual server itself is just on a Ubuntu machine. > > I don't see anything in any of the logs you mention, so it seems you're > right that mailman and postfix are not talking. When I sign up for a new > list, I do get the confirmation email from mailman, so yes it is running. So your issue is that mail sent to Mailman is not delivered to Mailman. I.e. the non-delivery notice you receive is about the message you sent to Mailman and mail from Mailman, e.g., confirmations, is delivered. This is actually not surprising as the <https://help.ubuntu.com/community/Mailman> document you followed is totally f****d when it comes to setting up delivery from Postfix to Mailman. It conflates delivery via aliases with delivery via the unsupported, 3rd-party postfix_to_mailman.py script. See <https://wiki.list.org/x/15564817>, and decide which delivery method you want to use, and if you still have issues, we will try to help, but be aware that we are much happier supporting the standard delivery via aliases rather than postfix_to_mailman.py. Also: 1) Please keep this on the list. 2) If you have further DSNs from google regarding delivery to a list, the actual content of the DSN would be helpful. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Unable to send emails with mailman/postfix
by Scott Jones 06 Mar '17

06 Mar '17

Mailman version: 2.1.20 OS version (virtual): Ubuntu LTS 16.04.2 Hi, I've set up a mailman client on a virtual server that I am able to connect to from the outside world. I see all of my mailing lists and have followed this document: https://help.ubuntu.com/community/Mailman when configuring. However, none of my test messages are being sent. I do not see anything in the mail logs and further, when I send a message using 'mail -s' it works perfectly. I eventually get a "The recipient server did not accept our requests to connect" receipt from Google. Any suggestions as to what to try next? Thanks,

2 1

Fwd: Re: Mailing list membership.
by willi uebelherr 02 Mar '17

02 Mar '17

Dear friends of Mailman, in the IETF discussion list we have a discussion about the bounces, that are created based on the DMARC processing. I know, from a discussion in this mailman list, that mailman follow strong the RFC 2821 (SMTP) and reject this DMARC nonsense. I send you my answer to Theodore and Khaled in the IETF discussion list for verify. I have not so much experience with that. But i know from many mailman lists that they have always this bounce-errors. The consequence should be, that the members in the list should change her mailbox servers to avoid this "bounce errors", based on DMARC processing, or not? For me, i don't like any form of work arounds. We need a clear base. And this can only be the standard RFCs. What you think about? many greetings, willi -------- Forwarded Message -------- Subject: Re: Mailing list membership. Date: Wed, 1 Mar 2017 16:29:01 -0300 From: willi uebelherr <willi.uebelherr(a)riseup.net> To: IETF discussion <ietf(a)ietf.org> Dear Theodore, many thanks for your explanation to the RFC 2821 (SMTP). The answer from Khaled i have included, because it goes to me as a private message. Maybe, based on my bad english, i feel some confusion with the terms. 1) Khaled, like i and you, is member of the IETF discussion list. This means, he receive all emails that are distributed over the list. 2) Khaled, like i and you, use the maillist server mailman from IETF discussion list to distribute his messages to all members in the list. 3) The IETF discussion list don't follow the DMARC processing. This means, it act only outside. 4) Khaled, like i and you, use a mail box server system as the interconnection point to the list. Khaled use hotmail, you use mit.edu, i use riseup.net. This means, the actors are the mailbox servers with the mailman maillist server IETF discuss in both direction. I understand and agree absolutly, that the maillist server never change the From-line in the header. He create the Return-Path-line and/or Error-To-line for error response from the receiver mailbox server system. The bounce-information. The mailman maillist server use bounce-counters for every member and some limits for this bounce-counter. If the limit exceeds, and the admin-group do nothing, then the maillist server mailman disable the delivery. It is not an unsubscription. The admin-group have to follow the incremental increase of the bounce-counters to understand, what is the background. Maybe, the mailbox is full, or don't exist or is the result of this stupid DMARC processing. The DMARC processing is defined in the DNS info. But we can ignore it, or not? The admin-group can inform the member to change her mailbox server to "avoid more errors" like Khaled wrote. The IETF discussion admin-group can only inform about the error sources. The members have to change her mailbox servers, or not? Based on that process, we can clean all this nonsense in our IETF lists environment and work strong based on the RFC 2821, like mailman do it. What do you think about? many greetings, willi On 01/03/2017 07:50, Khaled Omar wrote: > Hi Willi, > >> Mailman never change the "From"-header. Therefore, the From-Header always points to the author of the email. What you think, is that the correct, compatible way? I think, yes. > > Such case is out of our hands, other e-mail service providers are welcome to be used just if this will add a value and avoid more errors. > > Best Regards, > Khaled On 01/03/2017 01:49, Theodore Ts'o wrote: > On Tue, Feb 28, 2017 at 05:29:24PM -0300, willi uebelherr wrote: >> >> related to the problem, what Khaled explained, what is your proposal? >> >> What are your "compatible with internet mailing lists" mail systems? > > RFC 2821, Simple Mail Transfer Protocol, section 3.10.2 > > "To expand a list, the recipient mailer replaces the > pseudo-mailbox address in the envelope with all of the expanded > addresses. The return address in the envelope is changed so that all > error messages generated by the final deliveries will be returned to > a list administrator, not to the message originator, who generally > has no control over the contents of the list and will typically find > error messages annoying." > > This is the SMTP Envelope From field. The FROM field is not changed, > but the SMTP return address is changed, so that bounces go to the > mailing list administrator as opposed to the person who sends mail to > the mailing list. > > Unfortunately, if you are using a system whose domain requests that > all recipients enforce DMARC alignment, this specifically instructs > recipients to bounce mail if the SMTP Envelope return address doesn't > match the FROM field in the header. This means that they won't see > mailing list mail as defined by the IETF Standards Track RFC 2821, > which specifically says that is acceptable (and in fact a good thing) > to change the SMTP envelope return address so that bounces (caused by > people changing where they work, etc.) go to an administrator who can > deal with them. But if the mailing list administrators gets too may > bounces, and it's because the sending domain is requesting that mail > be bounced, the only thing they can do is to unsubscribe the sender or > the recipient. > > Hence mailing list systems that enforce DMARC, or request DMARC > processing, are fundamentally incompatible with mailing lists as > defined by section 3.10.2 of RFC 2821. > > If you want to participate in such mailing list, one of the best ways > is to change to a mailing list system that doesn't do DMARC. > > Best regards, > -Ted

3 2