[dns-operations] OT: mail list handling question
brad at stop.mail-abuse.org
Sat Jul 8 09:11:51 UTC 2006
At 11:52 AM -0400 2006-07-07, Edward Lewis wrote:
> I sent some mail to the list this past week that evidently was seen
> and is in the archives, but it wasn't delivered to me.
I got a copy.
> Is there any reason that the list wouldn't have sent it back to me?
> I did get the CC to myself. If anyone got it and see that it might
> have hit a spam flag, let me know.
There is a "nometoo" flag that can be set within your list
membership configuration, and in that case when a message hits the
server, Mailman will look through the list of recipients shown in the
"To:" and "Cc:" headers, and if it sees duplicates that are also
subscribed to the list with those exact same addresses, then it will
avoid sending them an additional copy of that message.
This is a pretty standard feature of most MLMs, although I'm
most familiar with Mailman.
Disclosure: I am also on the postmaster team for python.org, and
co-moderator of the mailman-users and mailman-developers mailing
lists that are hosted on python.org.
> The mysteries of mail. Why can't everything be as simple as DNS?
I've been specializing in mail and DNS for around fifteen
years. These things are surprisingly hard to get right, a fact that
has laid low more than a few hot-shot programmers who thought they
could whip up their own MTA or nameserver overnight.
Part of the problem is the very nature of these services.
They both cross over multiple areas of turf, and it's easy for them
to get screwed up either by multiple different groups/people fighting
over them or not wanting to touch them.
DNS is the only network service I know of that doesn't
typically reside on a dedicated box. Think about hubs, switches,
routers, etc.... They're all nice cold pieces of hardware with names
like cisco, Juniper, Extreme, or whatever, and network guys are paid
to understand them. But DNS typically runs on an icky host of some
sort, and someone else is likely to be responsible for administering
that machine, and if the nameserver administrators are responsible
for adminstering their own OS on that box then the odds are they
probably don't do as good a job of it as the "regular" host
Moreover, the "regular" host administrators don't understand
all these weird network things. Of course, all network services are
mission-critical, so having a mission-critical network service that
is not itself particularly reliable because there are too many cooks
in that kitchen, or no cooks that understand how to prepare all the
parts of the dish, is a recipe for disaster.
It's not strictly required, but nameserver "appliances" can
at least make the OS administration part of this equation something
that your average network administrator is more likely to be able to
deal with, and reduces the probability of things getting dropped
through the cracks, or people fighting over who gets to manage what.
OTOH, e-mail is the only mission-critical application I know
of. Every single place I've ever been, if e-mail isn't working then
you might as well just shut down the whole rest of the company. The
three-star general who is head of the Agency can probably get by just
fine if his secretary or admin assistant can't get to the word
processor right now, but you damn well better believe that all bloody
hell breaks loose when he can't get to his e-mail.
The one thing that gets ported to any new service or device
before anything else almost always seems to be e-mail. A device is
actually useful if it can get you to e-mail, otherwise it's probably
just a nice toy to have but you could live without it.
E-mail is the killer app of the Internet, indeed perhaps the
killer app of all electronic communications.
Both of these things are a hell of a lot harder to do right
than almost anyone ever gives them credit for.
Brad Knowles, <brad.knowles at skynet.be>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>.
More information about the dns-operations