User Tools

Site Tools


club:services:lists

Mailing lists

  • club@comssa.org.au — general discussion; all club operations that aren’t confidential
    • What happens when you write to that address? you post to the list (subject to moderation)
    • Who can skip the moderation queue? current and former committee members
    • Who can subscribe to this list? no restrictions
    • Some of the aliases for this list: member, members, membership
  • committee@comssa.org.au — enquiries; private discussions between current committee members
    • What happens when you write to that address? you post to the list (subject to moderation)
    • Who can skip the moderation queue? current committee members
    • Who can subscribe to this list? current committee members
    • Some of the aliases for this list: dreamspark, talks, theoffice
  • veterans@comssa.org.au — private discussions between current and former committee members
    • What happens when you write to that address? you post to the list (subject to moderation)
    • Who can skip the moderation queue? current and former committee members
    • Who can subscribe to this list? current and former committee members
  • wheel@comssa.org.au — private discussions regarding our technical services
    • What happens when you write to that address? you post to the list (subject to moderation)
    • Who can skip the moderation queue? current committee members
    • Who can subscribe to this list? current committee members
    • Some of the aliases for this list: wang
  • comssa@lists.curtin.edu.au — our old mailing list, superseded by committee@comssa.org.au
    • What happens when you write to that address? you post to the list (subject to moderation)
    • Who can skip the moderation queue? current committee members
    • Who can subscribe to this list? current committee members
    • We now use this address for exactly one purpose: renewing our DreamSpark subscription
      • Microsoft only allows us to do this with a *@curtin.edu.au or a *@*.curtin.edu.au address
      • comssa@lists meets this requirement, and it’s not tied to a particular student or staff member
  • comssa@mail.tidyhq.com — our TidyHQ list for announcements and enquiries
    • What happens when you write to that address? a message is created for us on TidyHQ
    • Who can subscribe to this list? current and former members of ComSSA

How to view the archives

If there’s a private in the URL, you’ll be asked to log in to the mailing list.

Don’t omit the trailing slash, or most of the links won’t work!

How to find your password

How to clear the filters

  1. For each of the following lists, log in with the list’s moderator password:
  2. For each of the messages that have been “held” for moderation (grouped by From: by default):
    • Don’t “Reject” a message unless you really know what you’re doing
    • Don’t “Ban” a sender or “Add” them to a sender filter unless you really know what you’re doing
    • If it’s obviously spam, choose “Preserve messages for the site administrator” and “Discard”
    • If it belongs on a different list, choose “Forward messages (individually) to:” and “Discard”
    • If it’s appropriate for the list that you’re currently considering, choose “Accept”
  3. Choose a message number (e.g. [1]) or “view all messages from” to read and/or act on individual messages
  4. Choose “Discard all messages marked Defer” to treat every “Defer” like a “Discard”
  5. Choose “Submit All Data” to commit your changes

Introduction to email

Email is one of the oldest uses of the Internet as we know it — it’s much older than the World Wide Web. Email is a system for submitting, transferring, delivering, and retrieving messages. Messages consist of:

  • An envelope, with an originator address and one or more recipient addresses
  • One or more header fields, each of which is a key/value pair with some information about the message
  • A body, which contains the vast majority of what you see when you read a message

Here are some important header fields:

  • Message-ID:, Date:, To:, Cc:, Bcc: — these are pretty easy to understand
  • From: — one or more addresses go here (note that you can put any address here, pretty much with impunity)
  • Subject: — your choice, but software can mess around with this to prepend e.g. Re: or Fwd: or [ComSSA]

When you reply to a message, forward a message, or quote a message, the Message-ID field of that message is added to the References field of your message. In computer science terms, References: fields form a directed acyclic graph of message relationships. In email terms, we call these collections of related messages “threads”. A decent email client will try to group messages that are in the same thread together.

When you “Reply” to a message, your client will probably fill out some fields by default:

  • If that message has a Reply-To: field, To: is set to all of the addresses in Reply-To:
  • If that message doesn’t have a Reply-To: field, To: is set to all of the addresses in From:

When you “Reply to all”, the same thing happens, but more addresses are usually added:

  • All of the addresses in that message’s To: are added to your message’s To:
  • All of the addresses in that message’s Cc: are added to your message’s Cc:

Introduction to mailing lists

You could hold a group conversation over email with little more than a very long To: field and “Reply to all”, but this would soon become unwieldy. A mailing list (or just a list) is a list of email addresses (the list’s subscribers). When you post a message to a list, the list’s software sends your message to all of the list’s subscribers. A list may have its own email address, and sending a message to that address may post a message to the list (but not all mailing lists behave this way).

Mailing lists can be used in a bunch of interesting ways:

  • For discussions, where anyone can post, and anyone can subscribe
  • For enquiries, where anyone can post, but only committee members can subscribe
  • For announcements, where anyone can subscribe, but only committee members can post

Authentication issues

Until relatively recently, email was a real free-for-all:

  • There were many email servers through which you could send any message you like, without even having an account
  • You could send messages “from” any email address you like, and there would be no way to stop you from doing so
  • You could modify any message in transit, prevented only by heavily involving the sending user (e.g. S/MIME or PGP)

Some attempts have been made to fix these problems over the last couple of decades:

  • Those servers — open relays — were aggressively ostracised, and new ones end up on global blocking lists right away
  • SPF allows the owner of a domain name to say “if you get a message “from” me, it should have been sent by one of these servers”
  • DKIM allows the owner of a domain name to say “if you get a message with a signature “by” me, check it against this public key”
  • DMARC allows the owner of a domain name to say “if you get a message that doesn’t pass SPF and/or DKIM, reject it (for example)”

The repulsion for open relays isn’t a problem for mailing lists — all we need to do is configure our email servers correctly.

SPF isn’t a problem either, because it looks at the originator on the envelope, not the From: address in the message, and a mailing list would use a new originator when sending a message to all of its subscribers. If delan@azabani.com sends a message to club@comssa.org.au (in order to post to the list), the initial message would be “from” delan@azabani.com, but the messages to the list’s subscribers would be “from” club-bounces@comssa.org.au. Even though From: would continue to be set to delan@azabani.com, SPF doesn’t care about From:.

DKIM and DMARC can be annoying for mailing list operators to deal with. DKIM works by cryptographically signing a message’s body and a subset of its header fields. Mailing lists often do many things that would change these parts of a message, breaking DKIM signatures:

  • A list might want to add a “header” or a “footer” to the body of each message
  • A list might want to change the Reply-To: address to the address of the mailing list
  • A list might want to change the Subject: of a message to add [ComSSA] to the beginning
  • A list might want to filter out some attachments (including but not limited to HTML messages)

Before the advent of DMARC, to break a DKIM signature would not be the end of the world. SpamAssassin might add a few tenths of a point to the “spam score” of a message that has a broken signature, but it wouldn’t really make a difference.

DMARC is the first authentication mechanism that takes From: into account. If the address in a message’s From: field is on a domain that enforces DMARC, and the message doesn’t pass SPF and/or DKIM for that domain name, the message is marked as spam at best, or flat out rejected. Recall that when club@comssa.org.au sends a message from delan@azabani.com to all of its subscribers, SPF would only apply to club-bounces@comssa.org.au, the originator of those messages. When it comes to DMARC, the domain name in From: (azabani.com) is what matters, and with SPF out of the question, the DKIM signature must succeed.

Here are three ways to avoid tripping DMARC authentication:

  1. “Munge” the From: address in all messages that go through a mailing list
  2. “Munge” the From: address if that address is on a domain that enforces DMARC
  3. Configure our mailing lists to ensure that they don’t modify messages in any way

To “munge” a message is to change its headers from this…

From: Delan Azabani <delan@azabani.com>

…to this (essentially disabling DMARC):

From: Delan Azabani via Committee <committee@comssa.org.au>
Reply-To: Delan Azabani <delan@azabani.com>

The mailing lists on comssa.org.au currently use the second option, but we’re considering the third option.

The first option requires GNU Mailman 2.1.18 or newer, and in a way, it’s the safest. There’s nothing a mailing list can do to modify a message, deliberately or not, that would trip on DMARC.

The second option requires GNU Mailman 2.1.18 or newer, and it’s just as safe as the first option. It’s less ugly, in that “only Yahoo!” (and any other domains that enforce DMARC) will be subject to munging, but for the same reason, it’s also less consistent.

The third option doesn’t require a particular version of GNU Mailman, and it’s the cleanest, but we must configure our mailing lists as follows:

  • from_is_list = 0 (No)
  • anonymous_list = 0 (No)
  • dmarc_moderation_action = 0 (Accept)
  • first_strip_reply_to = 0 (No)
  • reply_goes_to_list = 0 (Poster)
  • subject_prefix = ''
  • msg_header = ''
  • msg_footer = ''
  • scrub_nondigest = 0 (No)
  • filter_content = 0 (No)

The third option has a couple of snags:

  • We can’t modify messages in any way, even if only to change a Reply-To: address or stick [ComSSA] on the front of a Subject:
  • If a message is changed in any way, it will trip on DMARC and get marked as spam or rejected (it’s all about the edge cases — for example, a Yahoo! user with no display name will send Reply-To: <delan.azabani@yahoo.com>, but Mailman 2.1.18 will inexplicably rewrite this as Reply-To: delan.azabani@yahoo.com, which breaks DKIM, which trips on DMARC, which marks the message as spam)

How to filter messages with Gmail

  • {list:comssa.lists.curtin.edu.au to:comssa@lists.curtin.edu.au}
  • {list:club.comssa.org.au to:club@comssa.org.au}
  • {list:committee.comssa.org.au to:committee@comssa.org.au}
  • {list:veterans.comssa.org.au to:veterans@comssa.org.au}
  • {list:wheel.comssa.org.au to:wheel@comssa.org.au}

Administrative messages for subscribers

To isolate or exclude some of these messages, add one of these snippets to each of your filters.

kind of message query
regular password reminders from:mailman-owner subject:"mailing list memberships reminder
when you are added to a list from:request subject:("Welcome to the" "mailing list")
when you are removed from a list from:bounces subject:("You have been unsubscribed from the" "list")
when you ask for your password from:bounces subject:"mailing list reminder"
when your post is successful from:bounces subject:"post acknowledgement"
when your post needs to be approved from:owner subject:("Your message to" "awaits moderator approval")

Administrative messages for owners and moderators

To isolate or exclude some of these messages, add one of these snippets to each of your filters.

kind of message query
when a post wants your approval from:owner to:owner subject:("post from" "requires approval")
summaries of posts that are waiting from:bounces to:owner subject:"moderator request(s) waiting"
when a member is added to a list from:mailman-bounces to:owner subject:"subscription notification"
when a member is removed from a list from:mailman-bounces to:owner subject:"unsubscribe notification"
when a member bounces a post from:mailman-bounces to:owner subject:"Uncaught bounce notification"
when a member bounces too much from:mailman to:owner subject:"Bounce action notification"

How to write your own filters

intent query
complement (not) -foo
grouping (or) {foo bar}
grouping (and) (foo bar)
grouping in order (and) "foo bar" or foo.bar or foo-bar
Subject: contains a query subject:meeting
List-ID: contains a query list:club.comssa.org.au
Message-ID: is a specific identifier rfc822msgid:foo@mail.gmail.com
Delivered-To: address contains a (part of an) address deliveredto:delan@azabani.com
(part of an) address ∈ (From:To:Cc:Bcc:) delan@azabani.com
(part of an) address ∈ (To:Cc:Bcc:) to:delan@azabani.com
(part of the) local part of an address ∈ Cc: cc:delan@
(part of the) domain name of an address ∈ Bcc:

——————————————————————————————————– GSUIT Domain is registered through names cheap and will need to be renewed each year. You can find the login details in passwords section.

club/services/lists.txt · Last modified: 2019/05/12 01:47 by simeon