[dmarc-discuss] How does *this* mailing list interact with dmarc?

Jim Popovitch jimpop at gmail.com
Fri Jun 22 16:54:42 PDT 2012

On Fri, Jun 22, 2012 at 6:54 PM, Michael Adkins <madkins at fb.com> wrote:
>>It harkens back to an earlier era, my server, my rules.  I was only
>>extending an olive branch by saying I would like your opinion on how I
>>implement my rules.
> What opinion, other than "please don't do the obvious wrong thing" do you
> expect people to want to express?  Also, if a mailbox provider is
> confident that it is the wrong thing, why would they follow advise that
> tells them to make a mistake?  It seems like everyone should be of the
> same opinion on what should be done in these cases, so I'm not sure what
> the value of adding it to the spec would be.

I'm referring to what a delivery system (receiver, reflector) should
do with an email... programatically.   Take bankofamerica.com...I run
a mailinglist with several BoA employee subscribers.  Suppose some a
bofa.com employee adds a p=reject.  Soon another BoA employee sends an
email to one of my lists.  I have a confirmed opt-in that he/she wants
to be a participant on that list, so I accept their email (my
server... my rules, whitelisted!!).  Since this is a mailinglist, my
systems reflect the email to thousands of others ... including
GMail/Hotmail/Yahoo/Yeah/163/etc.   But wait,
GMail/Hotmail/Yahoo/Yeah/163/etc see the emails from:@bofa.com and
detect the p=reject.... suddenly my weekend becomes a headache.  Note:
this sounds a lot like John Levine's least favorite DMARC talking
point, but I believe it is different than the mailinglist issue, it's
a reputation issue.   My mailinglists have been, and will be, doing
the same thing.  But bofa.com's new DMARC record suddenly makes me
look like a spammer/phisher to GMail/Yahoo/Hotmail/Yeah/163/etc.   As
a result, my weekend is shot, and someone in bofa.com has thousands of
forensic reports to dig through.  After a few rounds of this, sadly
p=none becomes the norm.   Alternatively, if bofa.com could tell the
world that receivers can provide overrides for mailinglists or
forwards, then GMail/Yahoo/Hotmail/Yeah/163/etc get to make the same
logical decisions they make now. The exact same.

My o=mailinglist,forwads suggestion would not be a DMARC mandate
(nothing in DMARC is mandatory). If anything, o=undefined could become
a validation of what is already normal usage.  o=none could reinforce
p=none.  o=forward would augment p=reject.  Alternatively, extend p=
to support multiple options like p=reject,forward,mailinglists so that
"whitelisted", aka "known", senders (Universities, Mailinglists, etc)
don't get into trouble with GMail/Yahoo/Hotmail/Yeah/163/etc.

Now, I know your first thought is "But that's the way it works
today!!!!", and I agree with that.  What I am saying is: put it in
writing, make it allowable so that it can be adopted and supported
tomorrow (when today's people have moved on).

-Jim P.

More information about the dmarc-discuss mailing list