Jim Popovitch writes:
> On Thu, Jun 12, 2014 at 10:18 AM, John Levine <johnl(a)taugh.com> wrote:
> > * Forwarding signature
> It seems to me that a non-DMARC subdomain, for users, would be easier and
> better for all..
No, the mailbox providers already can do that and it's not because
they were caught with their shorts down that they didn't. They really
really mean "p=reject" for users. A senior admin at Yahoo! was very
clear on damrc@ietf that they want their vanilla users covered by
"p=reject" because the threat model (which is not phishing, it's
"recommended by friend" spam) involves user mailboxes.
She also said that (as of a week ago) the attack based on stolen
contact lists was continuing to flood their incoming MXes, despite
over a month of "p=reject" (contrary to AOL's claims that "p=reject"
stopped the attack). No explanation has been given why the spammers
are continuing to spend their resources on the attack.
> > * Submit and sign
> Oh god, NO!
Oh, c'mon, Jim. This is just the evil kind of thing we *want* to do
Jim Popovitch writes:
> Unless I am mistaking things, the sheer irony here is that Yahoo's
> bastardized version of DMARC, which is necessary to stave off
> collateral damage from their past security breach(es?), needs to be
> further augmented with even less user security in order to be secure.
I don't see why the OAuth version of John's proposal would be less
If you want real irony, look no farther than Yahoo! Groups' From:
header field. Yahoo! is using DMARC to get "yahoo.com" out of the
From: field in list traffic, and Groups is putting it right back in.
Jim Popovitch writes:
> > What changed that you object to?
> One of the original __High-Level Goals__ was:
> DMARC is intended to reduce the success of attackers sending
> mail pretending to be from a domain they do not control, with
> minimal changes to existing mail handling at both senders and
> receivers. It is particularly intended to protect transactional
> email, as opposed to mail between individuals.
Actually, that word wasn't present in Murray's original -00 draft, and
was added in two places (along with a definition in terms of "business
transactions") in the -01 draft at the same time Ms Zwicky was added
as editor, in July '13. :-P According to Chrome's search function,
all three uses are still present in the current (April '14) draft (in
section 1.2 "Anti-Phishing" and section 2.1 "High-Level Goals" (which
contains exactly the text quoted above).
Based on what I've seen on dmarc@, the word "transactional" has
controversial connotations besides ruling out Yahoo!'s use case. The
problem is that Yahoo!'s problem ("acquaintance-recommended spam") is
a genuine problem, and could be addressed by DMARC "p=reject" if only
Yahoo! users would stop posting to mailing lists. :-) It's not just
Although Elizabeth and I aren't on good terms at the moment because of
difference of opinion about Yahoo!'s behavior, I haven't seen anything
from her that would indicate that she thinks "p=reject" is a *good*
idea ... except that at the moment it's their *only* idea. :-(
Jim Popovitch writes:
> > Do you have specific complaints?
> Yes. Unless it's not already understood... the original idea
> behind DMARC centered around non-human transactional emails
> (Banking notifications, Facebook status updates, etc.).
This was understood, and is why I call what Yahoo! and AOL are doing
But what is wrong with the spec itself, besides the potential for
> Elizabeth got involved and the spec was morphed (i say bastardized)
What changed that you object to?
I'm not just nagging, I really want to know. I've been over the spec
a couple of times, in a fair amount of detail, and I don't see it.
But if there are specific aspects to it that are broken when used as
designed, I (and John) may have some input into getting it changed.
Murray Kucherawy (the other author of the current Internet-Draft) and
Dave Crocker (who's authored more RFCs than the average bear) seem far
more on our side than on Yahoo!'s, and there are a couple of other
people who have posted intelligent comments (and of course, the usual
complement of Net.Kooks without which no standardization effort is
complete). Even Elizabeth seems quite reasonable, modulo her job
John and I are somewhat more likely to have input into auxiliary
protocols (such as the DKIM-Delegate protocol that John mentioned)
which might make Yahoo!'s use of "p=reject" somewhat more palatable.
I have completed the `describe instance` feature for the list object. I
herewith attach the sample output of the command.
The describe feature is triggered when the `show` action is supplied a
object name of the corresponding domain.
./mmclient show list list1(a)domain.org
Further, the CLI can easily be extended to support an independent sub
command `describe` to perform the same
action, *if necessary*.
./mmclient describe list list1(a)domain.org
The describe feature is intended just for getting a snapshot of the
object, in one shot.
I will be completing the same for rest of the objects and pushing the
next revision by 17/06/2014,Tuesday, as I will be away
from computer this weekend.
Jim Popovitch writes:
> AND THEN, a (that very same senior admin?)
All are the same person I suppose, Elizabeth Zwicky.
> Yahoo! employee got involved in the DMARC spec and it became the
> bastardized DMARC spec.
Do you have specific complaints?
I like the DMARC spec as it stands. Yahoo! and AOL are abusing it, in
exactly the same way that spammers abuse specs like RFCs 5321 and
5322. And with the same rationale: "because you can't stop us".
But that doesn't make it useless, any more than spammers make the
fundamental standards for email useless. The informational parts of
the protocol are a minor privacy invasion, I guess, but produce very
useful data. Even the policy part is useful IMO. You just have to
interpret it properly. "p=quarantine" == "p=we-have-a-security-
"p=reject" == "p=we-have-a-very-serious-security-problem-so-
So tell your Yahoo! users that their mailbox provider has a very
serious security problem, and labelled their posts as "almost certain
Note that "security problem" here doesn't necessarily mean "security
breached". It can also mean "we are a prominent target", as banks and
other financial institutions are.
 I wouldn't be surprised if for those users whose contact lists
were stolen 99% of the mail sent under their mailbox is from the
> This is always possible
> subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list
I have built to features, subscribe and unsubscribe users, as described
*subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list
*unsubscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list
The command prints a success message on successful completion of action
else prints an error
message and continues execution. These feedback messages can be suppressed
by using a
subscribe users user1(a)foo.com user2(a)bar.com user3(a)bar.com --list
user1(a)foo.com subscribed to list(a)domain.org
user2(a)foo.com subscribed to list(a)domain.org
user3(a)foo.com subscribed to list(a)domain.org
The commands accept one or more user emails as arguments.
I'm looking for a new mailing list manager, and one of the
requirements is that it has a web interface, and that it can use SAML
Looking at MM3, I see that there are several options for running the
web interface, one of them is Apache & mod_proxy.
We already have had positive experiences with mod_mellon (which adds
SAML authentication), and another web application (Atlassian
Confluence), which sounds like a similar set-up, so I think this could
be made to work with MM3 as well.
The only issue I'm having is that our current IDM system is build
around the concept of identifying users by ID, in our case an integer.
My Python knowledge is pretty basic, but from
src/mailman/model/user.py it looks like MM3 users are also identified
by an id.
That would be great, because then Apache with mod_mellon could
authenticate a user and populate HTTP headers with the user id, and
then MM3 could pick that up.
Am I assuming the right things?
PS, I'm asking because I've looked at another mailing list manager as
well, but that seemed to using the e-mail address as the user
identifier, which rendered it useless for us...
System & Networking Engineer
Singel 468 D, 1017 AW Amsterdam
Murray S. Kucherawy writes:
> On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull <stephen(a)xemacs.org>
> > If I understand you correctly, we actually already have the mechanics
> > for this in place. Most sites like Yahoo! allow you to whitelist a
> > sender.
"You" here is the individual Yahoo! user. The whitelists are per-user.
> If that's the case, you still have the scaling problem of populating the
> whitelist. How would Yahoo! go about doing that, for example? They claim
> at least 30,000 such cases that ideally would land in that list
> automatically somehow.
It's not "the" whitelist, it's all the users' personal whitelists.
I don't know if Yahoo! offers such whitelist capability, or if they
simply use some heuristic based on the users' contact list, or what.