[dmarc-discuss] How does *this* mailing list interact with dmarc?
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).
More information about the dmarc-discuss