[Linux-aus] SPF problems too

[David Bell]

Because I'm finally making an attempt to catch up on email I thought I'd
share my perspective as a moderator/admin of the mailing lists for LCA2016
(and lca-announce) as well as a user of mailhost for normal email.

Following this thread the admin team disabled greylisting and SPF on
mailhost which affects mail flow into LA's mailing lists (including LCA)
and the various inboxes used by Council, the Admin Team, and the LCA team
(among others). Whilst mail was delivered slightly quicker, the quantity of
spam also increased notably.

Across 8 mailing lists, 11 RT queues (most of which had email addresses
published somewhere), and 6 inboxes you can imagine that would be quite a
time sink.
This meant:
 - more messages clogging our moderation queues for Mailman (including the
endless notifications and then the bounces as well), this might have meant
that some false-positive moderated messages didn't get released as quickly
as they should have or may have even been accidentally dropped.
 - many spam RT tickets (and again more bounce messages) creating more work
for the team to clear the queues so actual tickets could get our focus.
 - so many SEO emails. I'm not sure who they think is competing for '
linux.conf.au' search traffic but it was endless. If I had a dollar for
every SEO email maybe we might have been able to afford some paid SEO.

Based on these experiences (which I'd expect the other mailman
moderators/admins, mailhost users would echo) I'd recommend the Admin Team
enable greylisting and SPF once again. If configured well (as I believe it
was previously) most users should barely notice a delay as repeat senders
do not get greylisted again within certain time frames.

Thanks,
David

On 17 January 2016 at 17:23, Russell Coker <russell at coker.com.au> wrote:

> On Sun, 17 Jan 2016 03:44:32 AM Brent Wallis wrote:
> > > On 01/15/2016 08:57 PM, Russell Coker wrote:
> > >> Thanks for the vote of confidence in my abilities.   I do make
> mistakes
> > >> on occasion, and in retrospect just adding a DMARC entry and sending
> > >> mail to lists was a mistake.  But a correctly behaving list won't
> > >> unsubscribe people
> > >> because of a mistake made by one member.
> > >
> > > In all seriousness, how will the list server know what happened here?
> You
> > > were experimenting with DMARC, there was a configuration error made ( a
> > > mail server error? from RC? uh oh Brent, better find some tightey
> > > whiteys), and a flurry of bounces came in. Mailman did what mailman is
> > > programmed to do.
> >
> > Meh..... how dare _anyone_ make mistakes! ;-)
> >
> > I think I stand corrected?
>
> I did not make any mistakes in the configuration of my mail server/DNS as
> such.
> The mistake was in deciding to configure it that way at that time.
>
> I think this lets Brent off on a technicality.  ;)
>
> > So be it... but someone will have to track me down the street with a
> > "bucket" for those offended to the point of nausea...
> > Perhaps even collect coins for a charity of someones chosing.
> > Thankfully... my under garb is generally knee length lycra and a discrete
> > cod piece...
> >
> > ....and honouring my commitment at 2am one Tuesday should definitely
> > minimise social damage....
>
> Remember, pics or it didn't happen.  ;)
> _______________________________________________
> linux-aus mailing list
> linux-aus at lists.linux.org.au
> http://lists.linux.org.au/mailman/listinfo/linux-aus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20160229/41191705/attachment-0001.html>