configuration error in lists.isc.org

[Lawrence K. Chen, P.Eng.]

On 2015-08-06 19:00, /dev/rob0 wrote:
> 
>> My SPF record doesn't include lists.ist.org, of course and it never
>> will. Furthermore it ends with "-all" so all my messages to the
>> list are being rejected by list members who have spf aware servers.
> 
> No, GNU Mailman (which is the software behind lists.isc.org) does the
> right thing, setting a proper *envelope* sender address in the ISC
> domain.  Proper filtering would go on the envelope sender.
> 

Hmm, I had thought look, but I see that now....which seemed that it should be 
the ideal way to go.... People here have gotten angry when something changes 
headers on them.  Office 365 rewrite From lines...and its not a fixed 
way....as it breaks my mail filters every now and then.  The rewriting had 
angered users here, since for some of us what we put with our email address 
in the from is important or consistent (its what I sent my from to when I 
first started here, not sure what people would think if I changed it....  
Though there'll be a point where I might want to stop paying for right right 
to use it...


>> Just wanted to let you all know about it as I can imagine I'm not
>> the only person who has outgoing SPF.
>> 
>> And the worst thing: If you have a record ending with "~all" your
>> messages will be accepted but probably end up in a spam report
>> container slowly eating away the good anti-spam-reputation your
>> server has.
> 
> Unfortunately a lot of sites do silly things, so there may be a bit
> of truth in that.  But it's not a reason to join in on doing silly
> things.
> 

In looking through the received headers I see that there's no SPF for 
lists.isc.org....

We used to have ~all for our SPF, but eventually we went with -all, and that 
has caused some weird rejections for people.

Like a research needs to email expenses some .gov address, which is just a 
forwarder to the real person's address....but the mailer for that address, 
doesn't see their forwarder as an allowed address for us, so its bounced the 
bounced the emails back.

I don't see why I need to list the .gov as ours...when the people that run it 
don't trust it.  But, various reasons didn't seem to calm the person down.. 
went over our heads but never heard about the issue again.

OTOH, we have caved on adding systems that aren't 'ours'...though how much of 
Office365 is actually 'ours'....but I think we currently have a couple 
includes for mass emailing solutions or our survey system (normally we push 
for them to use a subomain, our old in-house survey system was on its own 
subdomain, which the new one can use, but its more flexible on what users can 
use....it then comes down to whether there's a SPF rule in their way or not.

>> So ISC: please fix your list servers, let them rewrite the From
>> headers!
> 
Seems to me this is the Listserv way.... though we haven't yet upgraded to 
that version of Listserv.  Otherwise I had thought about using mimedefang to 
rewrite the envelope so that our old Listserv could continue...current is 16 
ours is 14....really need to get it upgraded for other reasons...and though 
they were going to finally go live while I had been away, but now it might be 
not be until next year?  Suspect there's something between our generating 
class lists automation.... while our mainframe is gone the the automation, a 
collection of nearly 150 ReXX scripts...lives on.  And, it does things that 
Listserv is not supposed allow ...like prevent users from unsubscribing from 
a list...though that's basically processes notification that somebody has 
unsubscribed, and send commands to resubscribe them....

While Mimedefang can also rewrite Fron/To/Subject, etc I'm person don't like 
such things

Especially the rewriting because it thinks the email is spam (or I am and 
changes it so the email can't be replied to, etc.)

Though the frequency of complaints over this seems to have dropped off 
here...though  its summer and most people haven't noticed yet that the new 
listserv did not go live on June 1st.....


-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
                                    with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally