RE: DMARC and yahoo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Stephen Farrell
> Sent: Wednesday, April 16, 2014 6:13 AM
> To: Michael Richardson; Theodore Ts'o
> Cc: ietf@xxxxxxxx
> Subject: Re: DMARC and yahoo
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On 04/16/2014 03:23 AM, Michael Richardson wrote:
> 
> >
> > So, as a WG chair, a person known to me just tried to post to the list
> > From a brand new yahoo.com mail account.  They aren't subscribed with
> > that address.  I would normally just approve, and add them...
> >
> > It seems to me that I must now actually reject, because it would
> > affect other subscribers.
> >
> > I'm now thinking that we need to remove all the @yahoo.com addresses
> > from posting to ietf mailing lists.
> >
> 
> This is probably obvious, but had gmail.com done what yahoo.com has done,
> that could I guess have a pretty significant impact on the IETF getting stuff
> done for a while since a lot of folks in the last few years seem to have
> migrated their IETF mail to gmail.com as a reasonable way to get around
> corporate this-and-that issues.
> 

Instead of "But had gmail.com..." substitute "When gmail.com does..." Add a little loop to go down the list of various mailbox providers/ISPS/cable providers/telcos/etc and add the same statement. Be sure to add a counter that stops the loop after the top <pick your number>. Add an if else statement along the lines of "if too painful stop else keep on going". Susan Powter could be the spokesperson shouting "Stop the insanity". 

> Maybe people who've done that might want to consider whether its such a
> good plan for so many IETF participants to be dependent on just one service
> now that we have a demonstration that s/none/reject/ in one TXT RR can
> have such an impact.
> 

Consider the scenario presented above. My impression is that the agreed upon solution within this group is to remove individuals with mail accounts at domains publishing p=reject and tell them to go somewhere else. There appears to have been a rough consensus so that is what the group should do. Nowhere to hide. This makes me think of the SIG at the bottom of Miles Fidelman posts. 

I think a "guaranteed not to publish p=reject" logo should be offered up by IETF as a branding mechanism. In fact, I like this idea so much I am going to have a designer friend of mine create it. IETF prominently in the middle with "guaranteed not to publish p=reject" around the perimeter of the circular logo. Participating mailbox providers could display it prominently on their websites and in their marketing materials. Just to be clear for anyone wanting to jump in claiming trademark infringement, this falls under the heading of parody - unless of course Y'all want to take the proposal seriously in which case you can have the logo.

This approach will allow any potential list participants in the world the opportunity to know that they won't run into the p=reject problem with the providers displaying the logo. IETF could maintain a webpage listing such providers to help market the concept. This approach will also provide miscreants identification of which mailbox provider domains to abuse - kind of like homes that post gun free zone signs. And of course, it will provide other mailbox providers a heads up on which domains are potentially subject to increased abuse. Hmm... what would that scoring look like in SpamAssassin? MLMs that don't want to change will be protected and life will go on for some definition of go on.

Anther solution would be for IETF to provide IETF participants with accounts at ietf.org (or a subdomain or something) and webmail, POP/IMAP access, etc. Eating your own dog food, what? This is sounding more and more like walled gardens from days of yore. Hey Hector, does WildCat! BBS still support dialup? Would you donate a license to IETF to solve this problem? Back to the future. This would ensure that although IETF participants would be dependent on just one service, there would only be one throat to choke so to speak.

Who would have thunk that the IETF standards process could be so exhilarating.  En garde.

Mike






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]