Re: Fwd: Re: mailing list question

I'm getting pretty confused :-(  To summarize what I picked up:

  - Over the past couple of weeks, more than 100 people have been removed
    from the list and more follow every day.  That is clearly unacceptable.

  - It seems that none of the work-arounds is nice.  The most promising I've
    seen is mailman's 2.1.16's plugin, which Chris claims is so ugly he'd
    consider unsubscribing.  I understand it is ugly, but is it also
    ugly to the users, or merely one of these things no sane computer
    scientist should want, but that `kind of works'?

    The second question is whether the hoster is willing to update mailman.

  - If the above doesn't seem to work, we could disable bounce processing
    in mailman, but that too seems a short-term solution that will
eventually
    polute the server and is the cause that many Yahoo (and if Jon is right
    also other providers in the future) not to receive some messages.

So, what other options do we have?

  - Start a new list on some other place that somehow works fairly well?
    E.g., a Google group?

  - Start using a forum.  Which?  Where?  I've asked this a couple of
    years back and clearly people wanted to keep a mailing list.  Did
    this change (also in the light of the above)?

    Ideally we'd merge the forum with the website and profit from the
    automatic linking to the manuals.  I'm afraid it is quite a bit of
    work to write a nice forum server though :-(

  - For programming questions, we could point people to stackoverflow.com.
    Unfortunately, that doesn't work well with discussions which they
    effectively try to avoid.

Other suggestions?

	Thanks --- Jan


On 04/28/2014 09:40 PM, Chris Fox wrote:
> On 2014-04-28 19:31, jon judge wrote:
>> There's no logical reason why me submitting an email to the swi list
>> /must/
>> be treated as an smtp 'forward', with the list server acting
>> effectively as
>> an smtp proxy (but dumping the contents on the web at the same time),
>> retaining the original 'From:', and then failing DMARC verification as
>> it is
>> not a configured proxy by the sender domain.
> 
> In my experience, there are practical, ergonomic reasons for retaining
> From addresses on mailing lists. I have been on MS-Exchange forwarding
> service that rewrote all the headers in the way suggested. It was not a
> pleasant experience. I would rather not be on a list that adopted such a
> policy.
> 
> Strict SPF and DKIM enforcement also breaks other things that are useful
> for spam control, such a disposable forwarding addresses. Perhaps
> ironically, one option for Yahoo users troubled by DMARC-reject is to
> use Yahoo's From spoofing settings to change their From address to a
> forwarding address in their control which is in turn configured to
> bounce email back to the Yahoo address. This then disables the DMARC
> checks...
> 
> These strict DMARC policies seem selfish; those that apply and enforce
> them are themselves using features (such as From spoofing) that break if
> everyone else were to play the same game. This is a lot of trouble for a
> policy that does not seem very good at controlling spam; there are
> reports that a significant volume of spam is now routed through Yahoo's
> servers, and so passes the DMARC checks -- as with SPF before it, we may
> well reach a point where spam is often more likely to pass these tests
> than ham.
> 
> Chris
> 
> PS There is a From-address rewrite plugin for Mailman
> (https://launchpad.net/mailman/2.1/2.1.16) but it is ugly IMHO. I would
> probably unsubscribe if this were implemented
> 
> 
>> Me sending a message to the list could be just repackaged and sent as a
>> fresh email from '[email protected]', whose identity /can/ be
>> verified by looking up eg. swi-prolog.com and verifying the email servers
>> are allowed to send email for that domain, with dkim, spf and dmarc
>> verification by the receiving email server.
>>
>> The underlying / temporary problem here is that sending email used to
>> have
>> no authentication.. it was the wild west out there... which is why we
>> moaned
>> about spam so much... and there will be teething problems along the way.
>>
>> And DMARC might be a flawed implemention, but it has been implemented
>> by ALL
>> the big email ISPs (google, yahoo, aol, hotmail, and xs4all, yeah.net,
>> ).. I
>> have DMARC reports to prove it, and we have to deal with it, or our
>> mailing
>> lists won't work.   Yahoo has just tightened their criteria to 'reject'
>> expect the others to do the same as soon as the lessons were learned from
>> Yahoo's strongest attempt yet at turning the screw on spammers.
>>
>> In the meantime, replacing 'From: [email protected]' to
>> 'From:'[email protected]', or whatever is the first step/only
>> game
>> in town, so far as I know.  DMARC is very fussy when it comes to
>> subdomains,
>> and can still reject  an email because it came from
>> [email protected] rather than
>> [email protected], so
>> read up DMARC and subdomains, and also ensure that if you have
>> subdomains,
>> then they have mx records set up too, else it will still bounce.
>>
>> If it's true that Yahoo/others are/will be insisting on a 100% compliant
>> DMARC policy for verifying sending domains, then you might have to
>> also get
>> all the spf/dkim records & keys set up on your dns - be 100% compliant,
>> before it will not get bounced.
>>
>> Assuming your mx server reputation is not already destroyed of
>> course... in
>> which case all bets are off / you need to start with an uncompromised
>> domain
>> / ip address for your mx servers as well.  But hopefully this will be
>> a last
>> resort.
>>
>> Also have a google around for 'dmarc testing' - I used online tools to
>> verify that my dmarc/dkim/spf dns records were configured correctly
>> before I
>> started sending emails.  And you can see from email smtp headers in your
>> email client/mailing list server) whether DMARC passed or not - the
>> headers
>> will show what passed or failed, on a message by message basis.
>>
>> It's a big mess, but we are where we are. Repeat: moving from yahoo to
>> temporarily looser/different email provider probably won't help you in
>> the
>> long term.
>>
>>
>>
>> -- 
>> View this message in context:
>> http://swi-prolog.996271.n3.nabble.com/Fwd-Re-mailing-list-question-tp14894p14906.html
>>
>> Sent from the SWI Prolog mailing list archive at Nabble.com.
>> _______________________________________________
>> SWI-Prolog mailing list
>> [email protected]
>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>