Re: [dmarc-ietf] SPF doesn't accommodate third level .name domains?
It looks like VeriSign has hit on the same solution to the personal PKI problem that I have in the callsign registry and for the same reason: To get around the problem that a certificate for al...@example.com doesn't work to authenticate Alice unless she is the holder of example.com. Building out the registry co-extensive with the PKI removes the need to validate the certificate requests for holdership of the domain because this is established by definition. It also looks like they have hit the inevitable constraints from trying to engage with the legacy SMTP installed base to make it do something different. And I can't see that problem as having a good solution. SPF was not designed to support the case where al...@example.com was in a different domain of control to b...@example.com. The .name use case is not going to have nearly enough of a user base to cause deployment of a proposed change to SPF to solve the problem. The only approach I can see working is for .name to provide the inbound and outbound mail services. Which given how SMTP works for inbound they must surely do anyway. On Tue, May 31, 2022 at 11:14 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > David's goal for the name registration is different from what Verisign > intended. Here is what I have inferred: > > Verisign wants to sell personal identity PKI certificates to the masses, > for use with S/MIMIE. A personal PKI certificate requires a subject name > and an owner email address. "first.last.name" becomes the subject name, > and "fi...@last.name" becomes the email certificate. This is a much > better solution than requiring the consumer to get a different PKI > certificate every time that they change hosting services. It also gives > Verisign a name space under their own control, so that the certificate's > legitimacy is easier to protect. > > S/MIME signatures do not have to match the From address or Mail From > address of the email message that contains, they just have to be > recognizable and trusted by the person receiving the message. This allows > the "first.last.name" certificate to be used inside a message from " > someb...@hostingservice.com" > > So the fi...@last.name email address is just part of the control system > for the PKI certificate, and is not intended for general use. As John > observed, there is no way to provide outbound authentication for these > addresses, because authentication is based on domain name (and changing > that would take 100 years to deploy.) m...@smith.name and > jos...@smail.name are likely to be using different message sending > systems. So any SPF or DKIM mechanism used to authenticate Mary's mail > could be used as a weapon to attack Joseph's mail. Since the addresses > cannot be authenticated, they should not be used for outbound mail. A > recipient who understands this situation would be wise to block any > incoming messages coming from the .name TLD. > > Doug Foster > > > On Tue, May 31, 2022 at 3:51 PM David Bustos wrote: > >> On Tue, May 31, 2022, at 1:33 PM, John R Levine wrote: >> > On Tue, 31 May 2022, David Bustos wrote: >> >>> Forwarding is pretty broken these days. Even if you had perfect SPF, >> a lot of your incoming >> >>> mail would fail DMARC because a lot of DMARC policies depend on SPF >> and SPF can't deal with forwarded mail. >> >> >> >> I'm talking about outgoing mail, not incoming mail. >> > >> > Are you talking about mail you send, or mail sent to your bustos.name >> > address that's forwarded to a mailbox somewhere else? >> >> Mail that I send to other people, with da...@bustos.name as the from >> address. Yahoo and Gmail sometimes direct it to spam. I presume it is >> because bustos.name doesn't have an SPF record. >> >> >>> I'm not surprised. The registry contract with ICANN forbids it. >> >> >> >> Is the contract available for me to read? >> > >> > It's the standard registry contract on the ICANN web site. >> >> Does the contract forbid publication of MX records? Verisign does that. >> >> >> This special case was committed to by TLD regulators back in 2002 and >> it is a problem for everyone with a third level .name domain. That's >> probably not many people, but the current situation is inconsistent so I am >> trying to figure out if any increases in consistency are possible. >> >> >> >> Yes, if no changes are possible then I may need to abandon >> da...@bustos.name . >> > >> > Looks that way. >> >> Is your position that Verisign should publish SPF records for the .name >> domains? >> >> >> David >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda Denial Was: IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
Accusing other people of disagreeing with you because they fail to understand your position and that they would agree with you if only they did their research is a rather aggressive move. It is the constant refrain of the coinsplainer community. If your goal is to preserve the status quo without actually defending your position, telling people that it is incumbent on them to find the arguments against their proposal and agree with them does the trick. We do need a better way to track architectural arguments so that they do not get lost. There is another form of this particular pathology which hit us with the DNS CAA record which I proposed before the DigiNotar attack, became an RFC but nobody took any notice and then a few years later, a new issue came up and we ended up with a CABForum mandate to deploy. I never considered CAA perfect, it was a compromise between a set of rather ugly constraints imposed by DNS DNS-ing. By the time we got round to the BIS, I had forgotten the rationale for the compromises. So we changed them. And then spent three years in a set of stepwise refinements that brought us back to the starting point because DNS is still DNS-ing and even harder. On Sat, Dec 18, 2021 at 3:44 PM Scott Kitterman wrote: > Okay. I didn't mention the fence as an endorsement of his personality or > politics. Not sure why that's relevant. > > Generally, I think arguing that something is wrong and should be changed > without understanding why it's the way it is isn't a great way to go. > > Scott K > > On December 18, 2021 5:50:52 PM UTC, Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >Anyone raising 'Chesterton's Fence' sets my teeth on edge. > > > >There is a longstanding field of political engagement called Agenda Denial > >that deals with winning arguments they cannot possibly win by making sure > >the argument is never made. > > > >It is never the right time, and never will be. > > > >There will always be something that must be done first. > > > >The people raising the issue have raised it in the wrong way. > > > >The issue needs more study. > > > >G. K. Chesterton was a rather unpleasant chap. Like most of the English > >establishment of the time, his goal was to avoid sharing any of the wealth > >of Empire with the undeserving masses who created/looted it. > > > >I strongly caution against anyone attempting to raise his standard in a > >technical discussion. > > > > > >On Fri, Dec 17, 2021 at 7:01 PM Scott Kitterman > >wrote: > > > >> > >> > >> On December 17, 2021 11:26:38 PM UTC, Douglas Foster < > >> dougfoster.emailstanda...@gmail.com> wrote: > >> .. > >> >A year after raising my concerns, I am still trying to get a > collaborative > >> >discussion started about what the optimal test looks like. In a > >> >collaborative discussion, those who are happy with the status quo > convince > >> >the skeptics to come on board, listen to their concerns, acknowledge > them, > >> >and do what they can to accommodate those concerns so that consensus > can > >> be > >> >achieved.I am willing to be convinced, but I am skeptical and I am > >> >looking for some collaboration. > >> > > >> It may be that this is a cultural issue then. In the IETF, where there > is > >> an established consensus (rough or not), the burden is on those seeking > to > >> overturn the consensus to convince people. If you think about it, if a > >> working group were obligated to rehash things whenever new people show > up, > >> it would be difficult to accomplish anything in an open environment > where > >> new people can show up anytime. > >> > >> I suspect you might have more luck if you first consulted Chesterton's > >> Fence. I think you'd have more luck with questions about why things are > >> the way they are than immediate assertions that they are wrong. > >> > >> Scott K > >> > >> P.S. At least as I understand it. I'm relatively new too. > >> > >> ___ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > >> > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
My analysis is rather different but comes to a stronger statement of John's point. Mailing lists are not well supported by SMTP and never will be. Any discussion of how to make mailing lists work better has to begin with the acceptance that they will never work very well which is what most people have been arguing in this thread. That does not mean that we should not attempt to make changes but it does mean that any changes should be considered through two lenses, not just one. First 'will this make mailing lists a bit more tolerable', Second, 'will this help a successor technology work better'. Rather than seeing mailing lists as they work today as the pinnacle of evolution, we should see them for what they are, a rather disgusting hack that we never got round to fixing. Why is it assumed that the input to a mailing list is an SMTP email? That seems to me to be a rather narrow assumption. I am typing this into Gmail, why assume that my HTTP transaction must be mediated by an SMTP transaction to reach a mailing list user? Why should 'mailing list' necessarily involve SMTP at all? Once we recognize that the inputs and outputs from 'mailing lists' can be through other transports than SMTP, all arguments about preserving 'original' headers collapse. This is not an interaction between an SMTP sender and receiver, the mailing list itself is a principal. I am of course aware that you can read IETF lists via IMAP, NNTP etc. In the short term, those efforts are being hobbled by the lack of decent clients. If the Web 4.0 folk get somewhere with a new generation of user centric social media, that might change. On Sat, Dec 18, 2021 at 12:15 PM John Levine wrote: > It appears that Jeremy Harris said: > >On 18/12/2021 03:47, Douglas Foster wrote: > >> MX checks are a valid tool for assessing SMTP MailFrom addresses, since > the > >> sender is supposed to be ready to accept non-delivery reports and other > >> automated messages. Of course, this has applicability if (but only if) > >> the RFC5322.From domain is the same as the RFC5321.MailFrom domain. > > > >I disagree. It is well-established practice for a mailing list manager > >to accept and process NDRs accepted on the 5321.mailfrom (which differs > >from the 5322.from). > > Jeremy is right. Mailing lists always, and I mean always, put their > own 5321 bounce address on the messages so they can do bounce > management. If you look at the mail from this list, the bounce address > is dmarc-boun...@ietf.org. > > I have to say I am dismayed that we are spending time dealing with such > utterly basic misconceptions here. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Agenda Denial Was: IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
Anyone raising 'Chesterton's Fence' sets my teeth on edge. There is a longstanding field of political engagement called Agenda Denial that deals with winning arguments they cannot possibly win by making sure the argument is never made. It is never the right time, and never will be. There will always be something that must be done first. The people raising the issue have raised it in the wrong way. The issue needs more study. G. K. Chesterton was a rather unpleasant chap. Like most of the English establishment of the time, his goal was to avoid sharing any of the wealth of Empire with the undeserving masses who created/looted it. I strongly caution against anyone attempting to raise his standard in a technical discussion. On Fri, Dec 17, 2021 at 7:01 PM Scott Kitterman wrote: > > > On December 17, 2021 11:26:38 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > .. > >A year after raising my concerns, I am still trying to get a collaborative > >discussion started about what the optimal test looks like. In a > >collaborative discussion, those who are happy with the status quo convince > >the skeptics to come on board, listen to their concerns, acknowledge them, > >and do what they can to accommodate those concerns so that consensus can > be > >achieved.I am willing to be convinced, but I am skeptical and I am > >looking for some collaboration. > > > It may be that this is a cultural issue then. In the IETF, where there is > an established consensus (rough or not), the burden is on those seeking to > overturn the consensus to convince people. If you think about it, if a > working group were obligated to rehash things whenever new people show up, > it would be difficult to accomplish anything in an open environment where > new people can show up anytime. > > I suspect you might have more luck if you first consulted Chesterton's > Fence. I think you'd have more luck with questions about why things are > the way they are than immediate assertions that they are wrong. > > Scott K > > P.S. At least as I understand it. I'm relatively new too. > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman wrote: > Stephen J. Turnbull wrote: > >> Phillip Hallam-Baker writes: >> >> > My point is that mail is an old protocol and people who expect that >> > it can be kept going unaltered in its original form serving all the >> > purposes that it was never designed for but have emerged over time >> > are going to be upset no matter what. >> >> True, as far as it goes. However, there is need for a push protocol >> that allows you to receive contacts from authors you don't know yet, >> in other words, a medium that is designed to be flexible enough to >> accomodate new modes of communication. >> >> It's not obvious to me that this need can be satisfied while at the >> same time denying spam. If it is indeed impossible, I don't see why >> that purpose can't continue to be served by email, while most mail >> (which is correspondence among acquaintances) gets redirected into >> authenticated channels. >> >> Just a quick reminder here: Postal mail is still going strong, after > 100s of years. > > Only because we haven't got email security properly sorted. I can't remember the last time I received a real letter. All I get is junk mail and bills. And the bills arrive because we haven't got the standards for doing it electronically established yet. Within a decade postal mail and the telephone will have become as functionally obsolete as fax. It will take a lot longer for them to disappear, the telegram only stopped last year, about a hundred years after it was utterly obsolete. The postal service will continue of course until Bezos works out how to get his drones to work. Technology does change over time. There is a very clear demand for an open Dropbox like solution. There is a clear need for a protocol that allows email like subscriptions to blog comments without the mailbox clog that results. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > Hector Santos wrote: > >> > >> Let me ask, what if a fedex.com employee use this email domain for > >> subscribing to the IETF list? > > > > Any subsequent problems are irrelevant unless FedEx, the owner of > > fedex.com considers them to be relevant. > > > > That is what folk complaining don't get: you don't have the right to > > use your employers email or a public email provider's email any way > > you want. The domain name owner makes the rules. > > > > As Craster insists: My domain, my rules. > > Strange concept! > > Does your jurisdiction allow your landlord to interfere with > postal/snail mail that is delivered from or to your rented appartment? > Absent specific government action to protect the tenant, the landlord can abuse them in almost any way they choose. Which is why we have voluminous legislative protections for tenants. There is an entire field of law concerning that. The reason that is necessary is that the alternative to renting is very expensive and requires a large amount of capital. But if houses were $6 then it would be perfectly reasonable for society to tell tenants that they are on their own because they should become freeholders. > > In the medium term, lets kill the stupidity of mailing lists with a > > protocol that works. NNTP was originally designed to replace mailing > > lists. It actually works quite well at that. The only problem was the > > IT-Dictator mindset that underlies it: newsgroups have to be approved > > by the Commune! > > Set up your own mail2news gateway. > > /usr/lib/aliases http://www.tldp.org/LDP/nag/node213.html > main2news script http://www.sirlab.de/linux/descr_m2n.html My point is that mail is an old protocol and people who expect that it can be kept going unaltered in its original form serving all the purposes that it was never designed for but have emerged over time are going to be upset no matter what. Spam is an attack. The people who send spam are hardened criminals who have murdered at least two people in the past five years. It is futile to expect that the mail system can continue to operate without changes. The major ISPs can and will and SHOULD consider the interests of the majority of their customers as they move forward. If they don't, open email systems based on SMTP will go the same way as USENET and die because people don't want to put up with them any more. The possibility that SAP might force you to subscribe to IETF lists through a different address does not worry me in the slightest. That is not one of the uses of email that I consider any sort of priority. I am quite happy making you change your mail config. But looking further ahead, it is becoming clear that maintaining mailing list capabilities is going to become increasingly difficult in the face of escalating anti-spam controls. Which is why I suggest that rather than the IETF community reacting to DMARC by refusing to consider any change that inconveniences members of its club, IETF instead designs a protocol that addresses the actual needs. In the SMTP/IMAP model the message is pushed to the sender outbound MTA, pushed to the receiver outbound MTA and pulled by the client from the outbound MTA. The SMTP/IMAP model is thus PUSH/PUSH/PULL The model of NNTP and Dropbox and many of the blogging comments apps is PUSH/PULL/PULL. That is a message pattern that we can and should support in IETF protocols. Because when someone is sending 10Gb of data, the PUSH/PUSH model is not viable. Better to leave that data siting on the outbound server rather than have it clog up hundreds of inbound servers and sit unread. US6192407 has a priority date of Oct 24, 1996, now would be a good time to work on such a protocol. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
On Tue, Jun 10, 2014 at 2:28 PM, Vlatko Salaj wrote: > On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker > wrote: > > >> There is a traffic jam in Cambridge/Boston >> several times a day as the lifting bridge opens to let some plutocrat >> sail his yacht through at rush hour. Several thousand people have to >> wait half an hour to get to work for one person to enjoy their hobby. >> I think that is a rotten and selfish way to run things. > >> Chances are that the >> conclusion is going to be that NO DMARC WG is formed because the >> people using DMARC are not interested in the changes that are going to >> be proposed. > > i just love this, i had to comment. > > Phillip goes about a story of a bridge and rich, selfish ppl disallowing > thousands of workers, and then he mentions how rich [read selfish] > corporations > don't wanna change DMARC and thus go on affecting thousands of domains... > > and he doesn't realize the paralel. No it is you who don't see the parallel. Google and Yahoo's position here is analogous to that of the MBTA, they are one entity with a lot of money but they are acting for the benefit of thousands. Meanwhile we have a bunch of privileged Internet early adopters who think that the rest of the world should revolve around them. The number of people using Yahoo/Google is over a billion. The number of people being inconvenienced by DMARC more than they spend effort on complaining about it is likely to be zero. The issue here is not that the yacht owner is rich, it is that there is one person able to inconvenience thousands by citing a precedent. >> So given the fact that DMARC is causing problems for mailing lists we >> should not automatically assume that the solution is to change DMARC. > > DMARC is causing problems for many things, not just mailing lists. > otherwise we wouldn't be having 3rd party alignment support > proposals. yet we have 3 of them. > > and it's just beginning. Yes, its not just SMTP that is going to be extended with as policy layer. Every Internet protocol will be covered by one. Back in the day I was the only person saying that NAT was the deployment mechanism for IPv6, not something to be deliberately sabotaged because it does not meet some IETF dogma. I was right then and I am right on this one. DMARC is the right way to do email. It is over done, deployed. The only question that is left for the IETF now is whether to fix any damage it might have caused and if so, how. >> Though since 'shut >> DMARC down because we says to' is not going happen pretty much >> anything has a better chance of deployment. > > well, since we don't have an oracle to ask what will happen to > DMARC, i'll rather leave all options open. When was the last time I was wrong on something like this? It is possible that Google and Yahoo might retreat but I can't see why they would. > however, i'm sure not gonna subscribe to this bullying, rich > corporation tactic: "we will do what we want, and u can't stop us". You don't understand the Internet then. All that makes the Internet different is that everyone has that same exit option. The only sine qua non of the Internet is that networks communicated via IP. That is a strict rule but it is the only rule. Everything else is on the table and anyone who wants to do something different can. And there is nobody to go to to ask permission. The Internet is an empowerment technology. Or at least it is since the Web reworked it. The goal of the Web was to put publication capabilities in the hands of everyone so it wouldn't just be Rupert Murdoch who could decide what was news. We don't have rules, we have conventions and standards. But anyone who does not like those standards is always free to rip them up and do something else. This is not a decision making body. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
On Mon, Jun 9, 2014 at 12:06 AM, Hector Santos wrote: > On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: >> >> >> To express how strong I feel about this >> >> If there is a charter for a new DMARC WG work, you can bet I will >> request that any form of 5322.From-Corruption concept be >> considered OFF TOPIC and OUT OF SCOPE in the new WG charter except >> to be aware of intentional From-Corruption is to be considered a >> new security exploit and threat to be mitigated. And for the >> record, I will also appeal any IETF work that begins to suggest >> From-Corruption concepts as a means to bypass security protocols. >> I will appeal it. >> >> Setting aside for the moment how premature this threat is given that >> there's not even a skeleton charter under proposal right now, > > > Its better to get this bud nipped now. Yes, always best to act before thinking about the problem Always best to make sure that the group considers only the problem it is allowed to consider. How can the IETF be a consensus organization if people are allowed to block consideration of alternatives? My understanding of the remit of this group is to consider what to do about the DMARC situation. The reason I proposed looking at changing the mailing list scheme is that the DMARC 'discussion' consists of one group of folk saying 'we have to stop this' and another pointing out that it has already happened. Most Internet users do not care whether mailing lists work or not. So expecting them to accept tons of spam from criminals trying to cheat them to preserve the equivalent of vinyl records is not going to succeed. The Internet does not have a rule that the people who got here first make the rules. There is a traffic jam in Cambridge/Boston several times a day as the lifting bridge opens to let some plutocrat sail his yacht through at rush hour. Several thousand people have to wait half an hour to get to work for one person to enjoy their hobby. I think that is a rotten and selfish way to run things. So given the fact that DMARC is causing problems for mailing lists we should not automatically assume that the solution is to change DMARC. I think that this point is completely on topic for a pre-WG list that is discussing ways to address a problem. Chances are that the conclusion is going to be that NO DMARC WG is formed because the people using DMARC are not interested in the changes that are going to be proposed. Mailing lists are not an optimal solution. They have high administrative burdens, the mail they send is often caught in spam filters because a mailing list is a bulk sender. These problems were recognized when NNTP was designed. Though as Dave Crocker points out, flood filling is hardly an approach we should endorse for the modern Internet. But given that we have the attention of Google and Yahoo here we do have the critical mass that could make a major change in mailing list technology stick. And it is to their interest to do so. So I am not just proposing a better solution, I am proposing a solution that has more chance of being adopted. Though since 'shut DMARC down because we says to' is not going happen pretty much anything has a better chance of deployment. >> I >> suggest you read Section 6.5 of RFC2026 to figure out what the >> official basis would be for such an appeal. > > > Murray, > > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IETF/IESG wise ones will agree. I hope you agree too. > > You will need to add security information to your DMARC document as this > From-Corruption concept would be a security exploit that can potentially get > by RFC5322 validation checks that can hurt DMARC publishers and create bad > PR for the DMARC protocol itself. DMARC receivers will need to be warned. > > You will need to provide guidelines for mitigating it, not for allowing it > unless there is an explicit policy defining language authorizing it, and > even then, that can be cracking open a loophole. > > You may want to make it a boundary layer check thing. The exploit will need > to be described just like it was done for DKIM's Double From situation with > RFC5322 validation checks done at receivers. > > Consider it a "to-do" note for when the anticipated official DMARC WG > begins. > > Thanks > > -- > Hector Santos, CTO > http://www.santronics.com > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
On Sat, Jun 7, 2014 at 12:38 PM, Stephen J. Turnbull wrote: > I'm not sure what the long list of addressees was about, but I'm not > comfortable with them. Feel free to repost my message if you wish. > > Phillip Hallam-Baker writes: > > > In the medium term, lets kill the stupidity of mailing lists with a > > protocol that works. NNTP was originally designed to replace mailing > > lists. > > GNU Mailman is thinking about this for Mailman 3. Of course we've > long had a mostly functional mail-to-news bidrectional gateway, but > Mailman 3 is considering adding NNTP capability directly to the > bundled archiver, or perhaps a separate facility resembling an > archiver as far as Mailman core is concerned.[1] I don't think this > has gone anywhere yet, though. NNTP was designed 30 years ago. We should consider moving on. The modern protocol world is JSON/REST > > It actually works quite well at that. The only problem was the > > IT-Dictator mindset that underlies it: newsgroups have to be > > approved by the Commune! > > Nonsense. I don't know what the problem that prevented netnews from > obsoleting mailing lists is, but the alt hierarchy has always been > available, and GMane proves that you can run a whole alternative NNTP > network without trouble and with a reasonable amount of resources. So > it's not the Cabal's fault (by the way, there is no cabal, in case you > haven't heard). Well you don't get the difference between the Web and the Internet then. We built the web on a model where the individual was empowered. Having to get a proposal for a newsgroup approved by an amorphous collective isn't empowering. The lack of clear control does not mean that there isn't any. It just means that the control is exercised without accountability. NNTP was built to save bandwidth, hence the need to manage what data went where. But we could certainly drop the server-server copy functions and just declare the mailing lists as site local. The problem with that approach is that we then have to have accounts and the single log in problem grows unless we interface to one of the single log in schemes, all of which have problems. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Change the mailing list protocol, not DMARC.
On Sat, May 3, 2014 at 2:08 PM, Hector Santos wrote: > Let me ask, what if a fedex.com employee use this email domain for > subscribing to the IETF list? Any subsequent problems are irrelevant unless FedEx, the owner of fedex.com considers them to be relevant. That is what folk complaining don't get: you don't have the right to use your employers email or a public email provider's email any way you want. The domain name owner makes the rules. As Craster insists: My domain, my rules. If you want to make the rules then get your own domain. I think that is something most IETF participants know how to do. In the medium term, lets kill the stupidity of mailing lists with a protocol that works. NNTP was originally designed to replace mailing lists. It actually works quite well at that. The only problem was the IT-Dictator mindset that underlies it: newsgroups have to be approved by the Commune! The idea that newsgroups work by the mail client PULLING a list of unread messages and then PULLING those that are to be read is the best architecture for newsgroups. I am currently using 8Gb of my primary Gmail account space, 80% of that is my mailing list mail. Google and Yahoo could both save tens of millions of dollars worth of hard drives a year with a better protocol, thats incentive to invest. The only points that need to change are the mailing list programs need to offer a very simple network API and the clients need to accept it. The second is not so difficult to deploy for the 90% of webmail users. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
