One of the Internet's most frequently encountered & classic mail list robots (eg FreeBSD used to use it. Debian Linux uses it at 2013-03-14, NetBSD uses it at 2013-03-14 Worth the small effort to learn: many of the basic concepts apply equally to other list robots. (There's also a web interface called Majorcool, which is in FreeBSD-9.1/ports but is not in FreeBSD-current at 2013-03-14.

Top Of Index and Top Of Page

It's Majordomo that manages lists on the Berklix hosts. If you want to subscribe or unsubscribe a list you need to use Majordomo, List owner can't do it for anyone manually any more, he's got no more free time for administrative trivia for hundreds of subscribers.

Top Of Index and Top Of Page

Email your instruction to the Majordomo subscription service.

Top Of Index and Top Of Page

•   Set Your Mailer To Send Plain Text (Ascii/ Ansi)
  No HTML, No MIME enclosures, No signature, No quoted-printable, No Rich Text
  (Avoiding HTML & MIME enclosures is no longer strictly necessary but still best).

  • Subscribing & Unsubscribing may fail or appear to fail: If you unfortunately post to list using HTML, HTML uses MIME Enclosures, so MIME will make list footers invisible to some readers If you mail HTML: Majordomo will usually (**) not understand your HTML format, & will reject each line back to you, with error message "command not recognized". If by chance you also mail a complete good command line to majordomo, such as unsubscribe you@your-company.com Then Majordomo will obey your command. ( (**) It is possible to embed useful plain text (Ascii/ Ansi) strings of Majordomo commands within HTML, & so long as one avoids all HTML junk on those lines, those lines will work, though errors will appear from HTML lines adjacent; however, that's something for computer computer people, Normal people should simply Not Send HTML. Set your mailer to send Plain Text (Ascii/ Ansi), or if you can't set it, switch to using different mailer software that can. Majordomo does Not forward your HTML junk to its human owner, to sort out your failure. Do not waste time sending HTML. Mail in Plain Text (Ascii/ Ansi) ! No Signature/ Footers If you send a signature footer (corporate disclaimer etc) to Majordomo, Majordomo will reject those lines back to you, complaining it cannot execute those commands. Majordomo will however execute any commands that precede them. To avoid Majordomo complaining about your signature you can put a single word "end" on a line on it own, after your last command to Majordomo before your signature . If your mailer sends mail in multiple parts using MIME formatted enclosures, probably sending duplicates in Ascii & HTML: Majordomo will obey the Plain Text (Ascii/ Ansi), but also reply with error messages on the HTML. The Plain Text (Ascii/ Ansi) will work though, (if your commands to Majordomo are correct).   Ensure the part containing your instructions is set to eg charset="US-ASCII" not UTF: Example of something OK - --part.1234.boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Example of UTF that will most probably fail: - --part.1234.boundary Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en Hints If your mailer breaks lines up (as seen from quoted-printable junk format, (also used by UTF), inserting spurious "=20" sequences, unseen by sender, but seen by Majordomo & visible in eg programmers editors : Turn quoted-printable Off. It will stop Majordomo understanding you Avoid quoted-printable junk format It damages command lines for Majordomo before it leaves your computer, so Majordomo can't work. quoted-printable format inserts spurious line feeds & other junk in mid line. Here is an example of quoted-printable junk format someone sent to Majordomo, that Majordomo rejected as junk, that the human then forwarded to Majordomo owner, further mangling his mail with more quoted-printable junk. >>>> auth 0bd37b64858e488ee32c5f0d50c783c3 unsubscribe walk W______ K___= el **** The address you supplied=2C W______ K___el **** does not seem to be a legal Internet address. You may have supplied **** your full name instead of your address=2C or you may have included y= our **** name along with your address in a manner that does not comply with **** Internet standards for addresses. **** It is also possible that you are using a mailer that wraps long line= s **** and the end of your request ended up on the following line. If the **** latter is true=2C try using backslashes to split long lines. (Split= the **** line between words=2C then put a backslash at the end of all but the **** last line.) >=20 **** unsubscribe: invalid address 'W______ K___el' >>>> wk___el@hot____.com **** Command 'wk___el@hot____.com' not recognized. If you read above, Majordomo even guessed the problem, But the person didn't think. The person was told more explicitly by the Majordomo owner: Mail Majordomo with Plain Text + Do Not to send quoted-printable junk format, then Majordomo worked fine. One way to recognise if your mailer sends quoted-printable junk is: send any normal (non subscription mail to any friend who has a programmers editor, ask them to look at it & reply. If you are sending junk quoted-printable format, you'r likely to receive replies with lots of spurious '=' at the end of your quoted lines, & some '=' in the middle too. ... but only when they quote the lines your sent them, not in their reply text to you, ie all the quoted-printable '=' junk is coming from your mailer.. & corrupting the commands you are sending to Majordomo .. so it won't work. If you use a mailer that sends both HTML And Plain Text (Ascii/ Ansi) (eg AOL): although Majordomo will spew error messages for every HTML line & the lines of the MIME separator, eg --part1_25d.80f9a3c.313f078f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit It still will honour the Plain Text (Ascii/ Ansi) subscribe instructions. (though you may have a had job finding the confirmation text string (password) to return & confirm your request, buried among all the error messages Majordomo will also emit, for each line of HTML & separator in your first mail. If your character set displays German umlauts properly, it's likely (but not necessarily) no good for sending the necessary Plain Text (Ascii/ Ansi). If you don't understand what character sets are about, & want to understand, ask for a computer lesson over a beer, else simply do what you'r told, & switch to Plain Text (Ascii/ Ansi) when sending to Majordomo. Mail Majordomo only plain text (Ascii/ Ansi). Do not mail HTML, or use Mime, or Word etc.

• Mail Majordomo commands only in the body of an email, not in the subject line.
• Mail Majordomo commands such as

  lists help end

  & you will receive a list of mail Lists you can subscribe to.
• Normally commands such as

  info bg-announce subscribe bg-announce unsubscribe bg-announce

  are sufficient, but you can also look at your headers, then specify eg:

  unsubscribe bg-announce optional-address-header-may-show-you-forward-from@abc.de

• If you want a list called bg-announce@, & you send a mail to bg-announce-request@ with the single world subscribe or unsubscribe, that should be sufficient, assuming you are at your normal address, & your computers &/or company gateways do not different addresses for external mail.
• If you mail from a temporary different address, trying to subscribe your normal address, try eg:
  subscribe bg-announce "Jack at Normal Address" <jack@normal.com>

Top Of Index and Top Of Page

Majordomo has no use for your human name, only your email address. Mis spell your human name, & it won't care, misspell your email address, & Majordomo will certainly fail to work as you want. If you accidentally scramble your name & address, putting in line breaks or screwing up "quote marks" or <brackets> etc, Majordomo may search to delete your human name instead of your email address, & will fail to find your address. If you don't understand mail name & address punctuation, simply omit your human name, & just give your email address without any surrounding punctuation, keeping any unsubscribe as plain as you can, EG When you subscribe your new address (eg to a list called bg-announce), it's safe to give your full human name & email address, EG Again, the human name is not essential, but it's nicer to have it: It helps the list owner & mail recipient sort things out manually if something goes wrong either end.

If you have problems, use just your email address, & omit your human name. As some people don't know the difference between their human name & their email address (yes really !) Here's some examples. Bear in mind that when mailers send both human & email address, they put the human name in "Quotes" and the email address in <less and greater than signs>.

Your irrelevant human name, (that might confuse Majordomo, that you can if you wish omit) is in this case John Smith, MicroStuff js@msv.com, The email address you must include is John_Smith@msv.com

Top Of Index and Top Of Page

Do not send an anonymous request such as Best send eg: At least send: Why:

• Send Plain Text (Ascii/ Ansi) where you can.
• Do Not Send HTML. It's spammers format. Not all mail readers support like or want HTML. & HTML is superfluous. HTML also uses MIME.
• Avoid posting MIME Enclosures (usually for HTML): It used to cause footers to become invisible (footer contains the important "How To Unsubscribe" etc), so MIME enclosures were forbidden.

  MIME was Not Allowed on lists up to 2011_09_11, & mails containing them were automatically rejected to the list owner
  

  Majordomo & the Lists now (as of 2011_09_12) also filter postings to Lists , & subscriptions & un subscriptions, automaticly converting HTML to plain text (Ascii/ Ansi) text.
  • This makes subscribes & unsubscribe & posting easier for technicly clueless etc people who don't know or want to know:
    • What HTML is
    • How to turn off their mailer from sending HTML.
  • MIME enclosures (such as HTML) now get forced to plain text (Ascii/ Ansi), so HTML postings will no longer get discarded to list owners, but should go to list.
  • Technical details & explanations, not for most list subscribers, just for a few (berklix servers have a range of mail lists with subscribers ranging from computer unskilled to highly skilled).
    • freebsd.org description
    • freebsd.org/ports/mail/demime CVS
    • Why MIME was blocked before
    • How MIME was unblocked:
      To various lines in /etc/mail/aliases one can add |/usr/local/bin/demime -8 -| both for: majordomo@: To let HTML subs & un-subs work; & lists@ aliases: To force footers to be visible, but that does however kill MIME inc PDF & JPEG etc.
• Avoid mass excretia from Microsoft Outlook (new name Entourage) at top, eg: PADDING-RIGHT, MARGIN, etc.
• Avoid appearing like spam, eg: colour, underlining, fonts, surplus spacing.
• Do Not Send MS-Word format etc Never send proprietary non publicly defined formats (EG Microsoft's Word, Power Point Excel, & most or all formats that start ms-*, etc).
  Posting monopolist proprietary formats or fonts etc to a berklix public list, would fly in the face of all the berklix servers are for & based on, inc. public open standards software, admin work committed, hardware donated, & hosting resources provided.
• Acceptable where & if necessary (but see note about MIME above): Publicly defined formats such as .gif .jpg .tiff .pdf .ps etc are acceptable if not avoidable. But we don't waste list bandwidth sending surplus big pictures to many who won't use them or need them. Just send an http:// or ftp:// URL (web ref.) to your original, for those few who want it. .
• Best Avoid: Public formats that need monstrous applications EG Open Document Format for Open Office.
  Why not Open Office format:
  • burdensomely enormous as a tool merely to read mail.
  • Needs 4 Gig of source to build, (or needs you to trust others to build binaries - defeating one of the major benefits of open source - security of not using imported un examinable binaries)
  • Needs manual fetching of some sources (deliberately crippled by Sun, for their licence reasons.
  • Depends on other web sites that break
  • Depend on too much other stuff that tends to break.
  • Depends on java (more pain - versions etc)
  • That even as a binary (if you'r prepared to trust & run foreign binaries (& some are not!), needs mammoth resources, & won't run on old or light weight &/or portable hardware.

• Do Not Send PC (i386,4,5,686 Pentium etc) architecture dependent formats. Formats (eg flash) that need applications that only run on eg Intel i386, but not AMD64, Vax or Sparc etc are bad news.

Stick to Plain Text (Ascii/ Ansi). It's minimal light & painless.

Top Of Index and Top Of Page

(Some mail providers foolishly set Content-type: multipart/alternative as their default (to also send HTML). Some mailers set Content-type: multipart/mixed to support sending signature/disclaimer block as a seperate MIME enclosure. You need to change that as Content-type: multipart/ is automatically Rejected to prevent

• Footers Breaking
• Junk HTML duplicates that waste bandwidth.

So You Need To:

• Change your mailer settings.
• How To Send Plain Text(Ascii/ Ansi)
• About Formats

multipart/alternative wastes about 70% of mail disc space & server time in repeated HTML bloat. (Imagine every small car in the world, pointlessly towing a big colourful Pakistani style truck behind it ! - That's about what HTML added to Internet mail)

Microsoft users, click "Format" then click (If English) "Plain text" or if German: "Nur-Text" You do Not want: "Rich-Text Or HTML".

Do not send bulk - EG big pictures :

• Postings if too big get automatically rejected.
• Realise some lists have well over 300 members. If you attempt to send such lists eg 2 big pictures & a map, the mail system adds protective wrapping, tries to send 6 Meg x 300 = 1.8 Giga Byte & rejects you instead.
• If the announcement is for an imminent event, First send just your text announcement, to ensure the server sends it out to all in time. Then if the map of where to go is bulky, send it as a seperate email.
• Unless pictures are really necessary, to show where to go, omit them.
• Recipients providers (ISP) also give low priority to receiving your bulk).
• Shrink your picture before sending. Shrink to half by half size frame & you shrink data by 4 ! Reduce JPEG quality 25%, down to 75% & its hard to see the difference, but you shrink data by a factor of 10. Do both & you achieve massive savings.
• Bulk creates a pointless peak load, as not all people need the pictures, especially they don't need them at exactly the same time.
• It delays other mail on the server
• Peak traffic during business hours, & wasted telecom traffic costs can make us unpopular with sites that support / subsidise our servers.
• Not all recipients have fast DSL download, some have slow modems (or corporate gateways), & some complain to sender or list owner. Don't be cause of complaints.
• Some recipients have low quotas on their mailboxes
• Your unexpected bulk pictures will overflows numerous recipient mailboxes, leaving no room for more important mail.
• Some receive list mail at work, their boss may also complain to them about irrelevant pictures.
• Those mailboxes automatically complain to list owner, wasting his/her time while he/she checks the error report type.

Put pictures on yours or some other person's web site, & just announce to list the URL (Uniform Resource Locator = web ref.) If you don't have web space, just announce they're available, & you'll private mail, or ask some friend to web host them for you (Not the over worked unpaid mail lists owner though please).

Top Of Index and Top Of Page

At least mark all but one of the lists with bcc in header so we don't risk receiving a storm of replies from other lists. ( If very occasionally a cross posting is appropriate, Please post clearly to One list only, Use a BCC to the other list, & make a clear statement in body of mail, to direct all follow up discussion to one list only. )

To clarify, as "cross posting" is likely a new non self evident term to some, Assume:

• General & Beer garden list bg-announce@ doesn't need walk detail, as walkers are on walk@
• General & beer garden list bg-announce@ doesn't need ski detail, as skiers are on ski@
• General lists don't need ski detail, as skiers are on ski@
• ski@ doesn't need beer garden or walk announcements etc.
• "Walks to beergardens": If it's a long walk with proper boots, post detail to walk@, else to bg-announce@.

Top Of Index and Top Of Page

Postings with enclosures in certain formats are automatically blocked, eg: These formats deprecated as bloated, proprietary, risky, & not open to all, Please use a different public format eg PDF or something else. For more background:

• English: http://www.gnu.org/philosophy/no-word-attachments.html
• German: http://www.gnu.org/philosophy/no-word-attachments.de.html
• http://www.berklix.com/~jhs/std/no_ms_format.txt

If you want virus alerts, subscribe a virus alert list. If you don't want viruses, either buy a virus filter, or dump your inferior virus prone commercial software, & use higher quality free software such as FreeBSD that doesn't suffer from viruses. or Linux that also generally doesn't suffer from viruses. (Both BSD & Linux have the capability to avoid viruses totally, but as Linux has more users & some of them have markedly lower skills, it's potentially more exposed if ignorant users choose to run systems insecurely. This is Not a technical fault of Linux but a problem of user skill/ education).

Top Of Index and Top Of Page

Many people have multiple email addresses. They subscribe one address, Receive list postings to it, Then later post to the list from a second address. As they haven't subscribed the new address, Majordomo@ berklix.org doesn't know they're not a spammer. Such postings may get silently dumped, or may be forwarded to a list owner, who is Not paid to waste time on it. This author owns many lists on berklix.org. He/she is too busy to waste time approving such mail. If he/she has enough time to do more than just delete it, he rejects it back to sender with this standard reply, to make both sender & others who sender may complain to, realise he/she won't do their work of maintaining their own subscribed address. Note

• Majordomo@ berklix.org will of course allow you to subscribe multiple addresses. S
  • Some mailer tools allow automatic reduction of duplicate received mail. A
    • Future list manager I intend to install will allow a more sophisticated approach.

    Top Of Index and Top Of Page

Never include our list address on any Internet scannable resource. We do not want web crawler robots harvesting our mail address to be sold to spammers.

Top Of Index and Top Of Page

Berklix mail list policy forbids all automatic response to list mail.

Avoid mail bounces & noise back to the Majordomo owner, list owner, or list etc. Bounces might be for many reasons, but Please spare the list owner work to deal with your problems, eg:

Keep To Remit Of List

Keep To Subject

Do Not Send Abuse & Flames

Criticism Of Organisers

Avoid Time Wasting

Please Help The Clueless !

Received: from ****.berklix.com [194.221.32.**]

unsubscribe bg-announce jill@the_address_she_long_ago_subscribed_as.com

• The berklix mail lists servers are generally modelled after BSD ( http://www.freebsd.org, http://www.netbsd.org, http://www.openbsd.org ) mail server configurations, (though FreeBSD has moved to Mailman since).
• I don't necessarily feel bound to configure everything BSD fashion though. I don't take, claim, nor blame BSD as the final arbiter of the perfect mail list.
• I belong to many list, including some BSD, many non BSD, some berklix & many non berklix. I observe good & bad points on those many lists.
• A few egotists occasionally act as if they have a personal right or God given insight to personally define how all mail lists should function in general, & how berklix mail lists should work in particular; often quoting a few lists they're on & I'm not, that operate in a different way. as if that's relevant or statistically significant, ... & if I don't agree I'm wrong & I Must change the servers according to their whim.
• No one pays for Majordomo & list owners time configuring & running berklix mail lists, & none have the right to impose their unilateral demands on me while I work free, running servers & lists. I _Must_ do nothing, except in last resort, maybe chuck off egotists if they persist in really annoying & wasting Majordomo & list owners.
• For any server option some feel should be changed, there's usually others of the opposite opinion, & Majordomo & list owners have got better things to do with their time usually, than get involved in debate.
• A few suggestions have been useful, more have not, some were blinkered demands, EG "I'm used to something different than what you'r providing & I don't want to change""
• Some configuration change suggestions might still be useful in future, keep it to a friendly Suggestion, not a Demand & you'll do us both a favour, rather than annoy us both, & waste time of both of us!
• Some options below are Not open for further debate, you are discouraged from wasting time discussing those, Thanks !

Top Of Index and Top Of Page

Assert Reply-To: on your individual postings if you want. The list servers used not to assert the Reply-To: field. Some @berklix lists now do. Sometimes people ask Why : It depends partly what you'r used to, what you like. What the nature of the list is (announce or discuss), the skill of the users etc. Some are used to lists that do assert. Some are used to lists that do not.

The Majordomo source doc/FAQ reads:

• 3.4 - How should I configure resend for Reply-To headers?
• Whether you should have a "Reply-To:" or not depends on the charter of your list and the nature of its users. If the list is a discussion list and you generally want replies to go back to the list, you can include one. Some people don't like being told what to do, and prefer to be able to choose whether to send a private reply or a reply to the list just by using the right function on their mail agent. Take note that if you do use a "Reply-To:", then some mail agents make it much harder for a person on the list to send a private reply. The most important reason why Reply-To: to the list is bad is that it can cause mail loops if any of the members of your list are running fairly-common but broken software which doesn't know what an envelope address is. (Many Microsoft products, as well as many other PC-based non-SMTP/Internet mail systems which work through an SMTP gateway.)
• You should read the following FAQ on why you shouldn't set the Reply-To: field. http://www.unicom.com/pw/reply-to-harmful.html

Not asserting Reply-To: doesn't please everyone, but then when I turned it on for one list, that didn't please everyone either. You can't please all the people all the time.

Top Of Index and Top Of Page

Subject prefixing is spurious. Of the hundreds of subscribers on many berklix lists just two I recall have asked for this. I tried it on one list, & got numerous complaints. You won't get it on berklix.org lists.

If you want to filter mail lists into seperate mail sub-directories:

• If you have the (Free!) luxury of working on a Unix system, then use Procmail, my example is here.
• If you use Micro$oft, I'd suggest you dump it ! I don't know if Procmail will run on Micro$oft, but procmailrc is public source code, so go check their web, &/or pay a programmer to port it to MS if you want. If you won't dump MS, I can't advise you further, but if anyone else wants to provide a URL to a page of mail filter tools advice for MS, do so.

Top Of Index and Top Of Page

This is On, restricting lists to only accept postings from subscribed addresses. To help protect against spammers.

Occasionally someone receives on an old address, but posts from a new address. This get bounced to the list owner as potential spam, (as from an unlisted sender). If the list owner knows the human sender, the list owner may choose to forward the mail, embedding headers so the sending human can see which old address they sent from, so the human can unsubscribe, & subscribe their new current address. Headers In Body

Top Of Index and Top Of Page

Sometimes the list owner forwards a posting with some headers in the body of the posting, (which looks dead ugly): Why it's done is explained below:

Mostly the problem ia a regular list member who has failed to coordinate his/her sender address with his subscription receiving address.

Some subscribers do not react when list owners ask them to re-subscribe their proper sender's address. They ignore the requests & continue posting from a non subscribed addresses. That wastes list owner's time with repeat forwardings (& they & list would be inconvenienced if list owner was away & not available to manually keep forwarding on time).

Options then are to silently delete bad postings (as some list owners do), until sender learns he/she Must fix his/her wrong subscription address, or sometimes to be a bit more lenient for a while, & forward with headers so senders realise:

• Their postings are a mess,
• They didn't get it right
• They need to re-subscribe their sending address
• They can see what their sender's address appears to be, so they can compare it with their receiving address in their incoming header, & then send off a correct pair of unsubscribe & subscribe commands to Majordomo (Sometimes people may find it particularly hard to know who they are subscribed as or apparently sending as, if eg masquerading is involved, & if they don't have headers to inspect.

In cases where list members are too incompetent to understand, other list members can see the headers to help them (Not all lists on this mail server are for technically competent people, some need help, & help is more easily offered from fellow list members, when the fellow list members can see the headers.

List owners usually remember to strip the part of the header between the list server & their private routing as irrelevant. List owners may leave headers between wrongly subscribed list members & mail list server as relevant. Sometimes list owner might strip a bit more, but better to strip too little than too much: removing too many clues for sender as to where they sent from & what they need to fix their end.

Top Of Index and Top Of Page

Some (later all) Berklix servers reject mail from non R-DNS compliant senders. (to reduce spam incoming). Senders to berklix addresses may need to configure their mailer to use their ISP's mail relay host for their outgoing mail. (This is the default for most major ISPs, but not for eg D-Telekom, who charge an extra 3 Euro/month. Any sender who runs mail servers at home, from behind dynamically allocated IPs that are not R-DNS compliant, who does not use a smart (relay) host with fixed IP with valid Reverse DNS (Domain Name Service) record will get bounced or lost. SASL is a method of authenticating a client to a remote smart host mail server. BSD users who have a login on Berklix servers, can ask for a SASL password.

Top Of Index and Top Of Page

No Terminal Mime Boundary

We used to get some spam, as lists run as instant relay, not content moderated or slowed waiting for human approval. Many lists are now only open for members to post to. Numerous spammer domains are blocked, inevitably some others are not. If you are paying me for internet consultancy I'll discuss spam prevention, domain black holing etc.

Top Of Index and Top Of Page

Spammers & others regularly forge mail senders addresses. Internet designers are adding secure non forge-able mail, but it's not commonly available yet (& there are good technical reasons Not to adopt some schemes). The openness stems from the way the Internet evolved: from an open trusting group of computer scientists & other academics exchanging technical info, to a net that was later adopted by business & general humanity including a full share of spammers criminals perverts lunatics & idiots etc. It's thus possible for the malign to forge instructions to, & responses from, Majordomo, you, I, or anyone else. Including instructions for subscription change commands etc, & forged responses. That's why Majordomo never trusts your first request, but always mails you back, with a confirmation password to be returned, to prove you are really you, & not some impostor, & that you still want whatever you previously asked for, actually to be done. Obviously, if you personally did Not ask for something to be done, you should Never send a reply quoting an authorisation password !

Top Of Index and Top Of Page