search

NuGet / Home

Repo for NuGet Client issues
Other
1.49k stars 253 forks source link

[Feature] Package ID Prefix Reservation #5307

Closed diverdan92 closed 6 years ago

diverdan92 commented 7 years ago

Status: Implemented

The specification is available here: NuGet Package Identity Verification

Use this issue for discussion. Link other issues with similar asks to this one.

maartenba commented 7 years ago

While I see the value for this being exclusive to NuGet.org, I would like to see this expand. For example for a company with a private feed, they may want to mark their own packages as being verified, so their developers know they are using the packages approved and built by the company. This is especially handy when multiple feeds are used: how do I know where a package comes from if “all” sources are selected in VS? The verification icon may help users identify those packages that come from the in-house feed.

And there is also the story about proxying... Should my in-house proxy also reflect approved packages? Or not? What with dotnet.myget.org, are those approved packages? Or not? ... In other words should reservations bleed through proxies? What if a package is verified on one feed but not another? Or on two feeds? Which one should be displayed as verified? Both? None? Just versions from one feed?

nilsandrey commented 7 years ago

About proxying...the verification can be reflected as from the "verification source" or "verified on source ".

asbjornu commented 7 years ago

I would like to echo @maartenba's concerns and underscore this:

How do I know where a package comes from if “all” sources are selected in VS?

I find it very troubling that today a package can be hijacked and in effect overridden by a rogue one simply by being named the same and having a higher version number, even though it might be coming from a completely different feed than the one it was originally installed from.

Instead of reserving package prefixes on just NuGet.org, I think you need to view this more broadly and figure out verification algorithm that works regardless of the package source, proxy mechanisms, etc.

diverdan92 commented 7 years ago

I recognize and agree with the feedback presented so far. I think we can broaden this to be a publicly documented server protocol so additional feed administrators can opt in to this experience. That said, it may not come immediately, but it is certainly something we'll keep in mind as we develop so we don't end up in a situation where it is hard to do this.

Regarding proxying across feeds - that's a good question. We'll need to give that a little more thought.

That said, @asbjornu - solving the private feed scenario ubiquitously regarding package identity and safety feels like it goes against private feed scenarios. Private feeds can have whatever they want and can be managed however they want - consuming packages from a private feed implies inherent trust in the feed itself. It's up to the package consumer to make decisions regarding private package feeds, and what is in the feed.

asbjornu commented 7 years ago

@diverdan92:

It's up to the package consumer to make decisions regarding private package feeds, and what is in the feed.

My point exactly. Being able to cryptographically identify and verify the owner, author and perhaps even origin feed of a package is something that should be in the power of the NuGet client application. But it doesn't seem like you're interested in tackling this with cryptography (yet) at all.

diverdan92 commented 7 years ago

@asbjornu - I understand these comments. This is good feedback. You are correct in that we are not looking directly at package signing yet. We'll certainly keep this specific feedback in mind as we approach package singing in the longer term.

FransBouma commented 7 years ago

As I've expressed elsewhere before: everyone should be able to get a verified prefix. It's now still looking like a popularity contest, where popular packages get a 'verified' checkmark and us mortals can forget about that because our package is simply not that popular (as in: millions of users but still very much vital to our users!).

Being verified simply means 'it's from the author claiming to be the author'. that has nothing to do with how popular the package is. Yes I know it's perhaps a time consuming process, but frankly that's of no concern to your users nor package owners: if you want to make the nuget the single source of truth for .net assemblies, you have to invest in that. Like in other debates earlier on this topic, this can largely be automated or simplified, it's not as if nuget has this problem alone, there are many more services which have the same problem and have solved it already. :)

VictorBlomberg commented 7 years ago

I share concerns with @FransBouma, even those with few packages and few consumers should be able to reserve a prefix. As of now, developing software in the open before one is ready to push a package is a significant risk. While the language in the spec is quite ambiguous in this regard, it does indeed sound like it's focusing primarily "VIP" packages.

Especially point 4 and 6 under "Criteria for Prefix Reservation" seems non-ideal. I think broad use of the feature is important for this to work out, and broad use requires even minor contributors to be able to reserve prefixes.

While many packages I use as a developer and consumer of NuGet packages are popular and with many consumers, and would definitely qualify for prefix reservation as defined by the spec, a significant portion of the packages I use are not especially popular. I think it is important that developers of the latter too feel included in the criterias, otherwise I, as a NuGet package consumer, honestly wouldn't have much use of this feature.

diverdan92 commented 7 years ago

I recognize the concerns and appreciate you providing this feedback. Our intention is to not make this a popularity contest. @FransBouma - which part of the spec is most concerning to you regarding this specific point? I'm happy to discuss specific points in the document that may concern you.

@VictorBlomberg - not all criteria needs to be met for an accepted application. Some of the criteria (such as number 4), could be for someone who has no established reputation in the .NET Community but is a big player elsewhere. Say another large company starts to play a role in the .NET ecosystem - we may use a combination of criteria 1 and 4 to accept them. It's possible they have no previous packages (so criteria 2 and 6 are invalid), but it still may be important for them to be verified. If anything, I think 4 is more inclusive than if it weren't there.

Regarding number 6 - we don't want to reward package owners submitting content produced by other authors and publishing it as their own, or producing content that is harmful to the community. Those are the driving factors for such criteria. Can you think of a better way to phrase it?

FransBouma commented 7 years ago

@diverdan92 Especially point 4 and this:

When an application is being reviewed and we plan to accept it,

and

You will also need to provide a description of why you believe you should have rights to the prefix,

This is too vague. It sounds like it's up to a committee whether a prefix is registered or not and you have convince them (that number of individuals you don't know) that you are the owner of the prefix. I get that if you just let everyone register whatever the heck they want, you get a run to every possible prefix you can think of like we have had to domain names in the past, but there's a middle ground here. A popular package will convince the committee much easier than a package that doesn't have a lot of downloads.

What I like to avoid is an endless debate with some committee about whether or not I should be granted some prefix, and that I can only hope they'll give it to me. Your criteria look a lot like the ones from Twitter which said 'everyone can get verified!'. Well, if you try to get verified, you quickly learn that it's up to some person or group of people who decide whether or not you deserve to be verified. You have to convince them.

With nuget packages we shouldn't want that: the packages I upload are build by me and I'd like to let my users know that when they download the packages from nuget that they indeed get the packages I uploaded, not the packages with the same name or similar names uploaded by someone else. It shouldn't be up to a committee whether I am able to offer that service to my users or not. How it looks now, I can be denied that service and in theory the packages I upload are equally genuine looking as the ones someone else uploads which perhaps are the same or are tooling associated with our system but not released by us. This thus leads to user A and user B both have packages for system S on nuget. Who to trust? User A? User B? That's an absurd situation, sorry.

It also shows, IMHO, you picked the wrong element to define identity on packages: the solution proposed is noble but the wrong solution for the actual problem. Being able to verify the source of the package is key, not whether the package has a registered name fragment. You seem to have chosen to use a prefix fragment as the identifying factor first and owner second (it's scheduled later). But I think you should turn that around: owner is key in this: packages from a verified owner can be trusted.

It's the same way in e.g. the app store and the play store: you search for an app using a keyword. Several apps pop up, they all look like they're the one you're looking for, names even (partly) matching the keyword you specified. One is from Google or Apple. If you were looking for the one from Google or Apple, you know you have the right one.

This gives more freedom over name fragments and also more clarity of identity (IMHO), as the identity of a package is rooted in its source, not in its name.

mgravell commented 7 years ago

To compound what @FransBouma says; prefix based identification may have severe issues when a library is commonly extended by 3rd parties. For example, if I search "dapper", 289 packages come up - many of which start with "dapper". Only 2 or 3 of those are "owned" by the dapper folks. Yes, I realize that "dapper" wouldn't necessarily be a good prefix - in your head substitute that for "Some.Library". My point is that as a library author, I don't necessarily want to have to police literally hundreds of other libraries that might use my library in the name - often at the start. So does that mean I shouldn't register the prefix "Some.Library"? (read: dapper). If anything, the very fact that there's so many - and that names have not historically been rigidly enforced - means that indeed: it is the source that is key, not necessarily the name.

I get that in the case of "Microsoft." and "DotNet." or whatever, a prefix also makes total sense. I just think it may be more nuanced than that.

diverdan92 commented 7 years ago

Thank you @FransBouma and @mgravell. I really appreciate your investment in making sure we make the right choices here. I love this feedback and hope you keep it coming.

In an ideal world, the entire identity of the package has some consistency. The author, owner, name, and ID should all have coherent properties that make sense together. This would give package consumers confidence that they are getting exactly what they expect. Unfortunately, we don't currently live in a world where all packages have a coherent identity across all identifying properties. Some examples are:

As you've correctly pointed out, there are multiple ways we can verify package identity to start. There are several substantial reasons why we think starting with package ID prefix is the more valuable initial investment:

With reserved package ID prefixes, we can associate a package ID prefix to an owner with more confidence that the identity is clear for all packages meeting that prefix. Then, if that owner does contribute to other packages where the identity may not be as clear, they are not penalized. They can continue to work on side projects/co-contribute/whatever because only the packages under their reserved package ID prefix will have the verified identity indicator in Visual Studio and nuget.org. To this end, we are also evaluating what to do with package author metadata for packages under a reserved package ID prefix - ideally this property would be consistent as well for all packages under a specific ID prefix. With all this in place, we effectively have a guaranteed coherent package identity for all packages submitted under a reserved prefix.

@mgravell - this is another great comment. We are trying to address the commonly extended library scenario in our design. In the design, we have specified that:

The package owner who reserved a package ID prefix will be able to arbitrate subsets of the glob pattern to other account owners, or to all package owners.

  • Example 1: for an open source project, the root glob pattern could be reserved (MyOpenSourceLib.) by a community backed NuGet account, but the community could open a subset of the prefix (MyOpenSourceLib.Extension.) to all package owners.

Do you think this addresses the scenario of concern, or is there more to it that you would like to describe?

FransBouma commented 7 years ago

@diverdan92

As you've correctly pointed out, there are multiple ways we can verify package identity to start. There are several substantial reasons why we think starting with package ID prefix is the more valuable initial investment:

  • You don't see the owner property in the Visual Studio Package Manager UI as the NuGet tooling in Visual Studio is feed agnostic - owner is only applicable to nuget.org. In other words, we can't show verified owner identities in Visual Studio - only verified package identities.

But a registered prefix is also only for nuget.org. You can't enforce registration of a prefix across everyone who has a nuget feed up. E.g. myget.org can serve a package with a package id prefix which is registered on nuget, but not on myget.

Identity starts with a single source of truth. It looks like you haven't established that, so everything else you do falls apart. After all, if you had established that, you can use that single source of truth also for owner verification.

Additionally, if the vs nuget tooling has limitations, you fix these, as it's your code.

With reserved package ID prefixes, we can associate a package ID prefix to an owner with more confidence that the identity is clear for all packages meeting that prefix.

But reserved where? How is that verified? even if I pull a package from a random feed in vs, it is verified on nuget.org?

Could you also please address my concerns regarding the committee judging the registration and what happens if someone gets denied for registering a prefix because said committee for some unknown reason doesn't give the prefix to the register?

Be aware you are creating a domain name like registration system which will likely backfire as it's a 'first-come-first-serve' system, while IMHO users are just interested in whether they can trust the source of the package. The latter will not fall into the trap the domain name system has fallen into. The former does. Frankly I don't see why you want to do it this way as it is only complicating things down the road, e.g. for people who also want to release something on nuget org but all prefixes are already taken except lame ones. That's what first-come-first-serve like the domain name system has learned us. You're planning to make the same mistakes.

diverdan92 commented 7 years ago

@FransBouma

[Edit - hit the wrong button, heh]

Just as registered prefixes are feed specific, so are registered owners. That problem persists regardless of how we choose to tackle this. In the longer term when we evaluate package signatures, we can consider additional measures for multi-feed security.

The VS tooling has additional challenges as it needs to work for more than just nuget.org. Yes, we want to tackle these as well, but we are dealing with limited resources so we need to use a phased approach.

I'm not sure how to further address your concern regarding a committee judging the registration. We are transparent with our criteria and will be transparent with our decision making. If an application is rejected, we will say exactly why it was rejected (which criteria is not being met).

We are not trying to create a first-come-first-serve system by any means. The most important criteria in my opinion are:

Does the package ID prefix properly and clearly identify the package owner?

Is the package ID prefix something common that should not belong to any individual owner or organization?

The combination of these two should make it so that no two owners attempt to apply for the same prefix that could legitimately represent them. Sure, a million people may try to apply for Microsoft.*, but only the Microsoft account would qualify for that prefix based on the above criteria.

We are also going to be rolling out slowly to make sure we don't get into a state where "all the good prefixes are taken". We will learn as we go, but we have to start somewhere.

maartenba commented 7 years ago

Ok so then what happens if I have two feeds registered, with both System. packages on them. How does the UI distinguish? Is all coming from dotnet.myget.org verified or not? ...?

If the idea is to just ensure someone else can't register a Microsoft.* package on NuGet, then cool feature, but if the idea is to display verifiedness of a package in the client, then see all above comments :-)

diverdan92 commented 7 years ago

@maartenba - we may scope this to when the nuget.org feed is selected in the UI. We are still looking at multi-feed scenarios. We will keep the server protocol feed agnostic, but we still have decisions to make regarding the nuget.org client UI.

One could make an argument that by adding third party feeds as NuGet sources, the user is putting inherent trust in those feeds and shouldn't need additional identity information to know the source of the packages. It should be their curated set of packages (or their company's).

maartenba commented 7 years ago

Also thought of another one. How will other clients display this info? Thinking VS, VS Code, Xamarin/VS for Mac, Paket, Rider, ...

The more you look into all cases where this touches if treated as a trust mechanism, the more complex things get. Perhaps it should just be a reservation + error message on NuGet.org when pushing into a namespace that is not owned. A verified icon doesn't verify a thing.

FransBouma commented 7 years ago

@diverdan92

Just as registered prefixes are feed specific, so are registered owners. That problem persists regardless of how we choose to tackle this. In the longer term when we evaluate package signatures, we can consider additional measures for multi-feed security.

So it has, in short, no value, sorry. If I pull packages from nuget to host locally and set up a feed there so developers can pull packages from that curated local feed, no verification is taking place, no value is added by this system.

The VS tooling has additional challenges as it needs to work for more than just nuget.org. Yes, we want to tackle these as well, but we are dealing with limited resources so we need to use a phased approach.

No offense, but nuget.org is the backbone of the .net core initiative. 'limited resources' is an internal Microsoft problem, not a problem for the users of nuget, but for Microsoft to solve internally. If things fall apart because nuget.org has limited resources, then how is Microsoft planning to move ahead with .net core at full speed as it depends on it?

I'm not sure how to further address your concern regarding a committee judging the registration. We are transparent with our criteria and will be transparent with our decision making. If an application is rejected, we will say exactly why it was rejected (which criteria is not being met).

The point is that there is a decision making process behind closed doors by people who can decide over this which can be very important for publishers. So much so that they might even lose market share because they can't get their packages to be 'verified' while their competition can. You shouldn't want this. This rule:

Does the package ID prefix properly and clearly identify the package owner?

It's too vague, how are you going to judge that? Or better: why do you think you are entitled to judge over that?

We are not trying to create a first-come-first-serve system by any means.

Yes you do, no 2 people can register SomePrefix. This might not be a big deal now*, but within a couple of years a lot of prefixes have been registered and what to do then, if your new product matches some prefix already taken and registers years ago? Same as the domain name system!

The combination of these two should make it so that no two owners attempt to apply for the same prefix that could legitimately represent them. Sure, a million people may try to apply for Microsoft.*, but only the Microsoft account would qualify for that prefix based on the above criteria.

That's not the point. Someone will register CoolStuff.* and is just a hobby dev and releases 1 package, which is utter garbage, but hey, it's a free world. Now some company called CoolStuff comes along and their product CoolStuff.Tools should be on nuget. They can't use CoolStuff, because the hobby dev had registered that already some years ago. Isn't that absurd? Not only is there now confusion that the crap the lame hobbydev produces under the 'CoolStuff' prefix is associated with the company 'CoolStuff', but the company CoolStuff can't register their prefix.

We will learn as we go, but we have to start somewhere.

You have no room for error, sorry. So there's no learning on the job for this. But it's also unnecessary: you are not the only package manager archive on the planet, there are many. They all have the same problems. What do others do in this case? What have they already implemented and which failed or succeeded?

terrajobst commented 7 years ago

So it has, in short, no value, sorry. If I pull packages from nuget to host locally and set up a feed there so developers can pull packages from that curated local feed, no verification is taking place, no value is added by this system.

That line of thinking seems odd to me. Let me give you another example. The URL https://github.com/torvalds/linux denotes Linus' version of the Kernel. People expect that this repo is only updated by Linus. Of course, Linus updates his repo by pulling code from other people, but people trust Linus' judgment. Since Git is distributed anybody can have any content in a clone of Linus' repo, but people wouldn't necessarily expect the contents to be vetted in any shape or form. Naturally, Linus' repo isn't special here -- people would have similar expectations for the official repos hosted by, say, RedHat or Canonical. But it's about trust for the party providing the particular instance of the repo.

By the same token, nuget.org is the canonical home for most NuGet packages. If you create your own feed, you can put in whatever you want. Developers using your feed will not have the same expectations as using nuget.org.

In other words, it's about house rules. Different houses have different rules. And that's not a bad thing: that's the benefit of distributed systems: it enables developers to unblock themselves and it allows bootstrapping ideas. Ultimately, it's the checks & balances that are part of the OSS culture. If system X is broken, it's forked and done differently.

VictorBlomberg commented 7 years ago

@diverdan92

@VictorBlomberg - not all criteria needs to be met for an accepted application. Some of the criteria (such as number 4), could be for someone who has no established reputation in the .NET Community but is a big player elsewhere. Say another large company starts to play a role in the .NET ecosystem - we may use a combination of criteria 1 and 4 to accept them. It's possible they have no previous packages (so criteria 2 and 6 are invalid), but it still may be important for them to be verified. If anything, I think 4 is more inclusive than if it weren't there.

If "not all criteria needs to be met for an accepted application", that should be clearly stated! If it's not all but any criteria that has to be met, that would indeed make my objections moot. But as of the current proposal, that is not stated anywhere. And if it's not "all" or "any", but "a few", that's too vague.

FransBouma commented 7 years ago

@terrajobst I understand your point, and I think I made mine poorly. What I was trying to say is that identity checking needs to be transferable to a local source, so that an organization can setup a local feed for their developers, store the packages there from whatever source, and dependencies taken on those packages are as if they're on nuget, or myget or what have you. Perhaps that's close to signing a package with a certificate.

In the end, I think the question that needs answering is: who made this package and should I trust them? If nuget gives out certificates to verified accounts, and these certificates can be used to sign the packages to become 'verified packages', anyone can always verify whether the packages are from source X and that they can trust them as nuget.org has verified them.

In your description, you never can, only when you pull the package directly from nuget.org and if someone reuploads that package to myget.org, no-one knows who made it or where it's from.

maartenba commented 7 years ago

Which brings back my original point: reserving a prefix can perfectly be a NuGet.org thing, but if it's proof-of-identity then this needs work :)

terrajobst commented 7 years ago

@FransBouma

What I was trying to say is that identity checking needs to be transferable to a local source, so that an organization can setup a local feed for their developers, store the packages there from whatever source, and dependencies taken on those packages are as if they're on nuget, or myget or what have you. Perhaps that's close to signing a package with a certificate.

Ah, I see what you're saying now. What about this:

Does that make sense?

diverdan92 commented 7 years ago

@VictorBlomberg Great feedback. I've updated the section in the spec outlining acceptance criteria. Will you take a look and let me know if there is additional ambiguity that you would like addressed?

@FransBouma / @maartenba stay tuned, I'm working on a proposal for other feeds to be able to opt into this experience. It will still be a feed specific scenario though. Each feed administrator will be the authority on what is verified and what isn't within their own feed(s). Do you have concerns with this?

As @terrajobst called out, we can start tackling the discrete package identity problem (across multiple feeds) when we consider package signing.

diverdan92 commented 7 years ago

First, I want to thank everyone for investing their time in providing such amazing feedback regarding this feature.

Next, I want to take some time to discuss some of the most common feedback we have received regarding this feature, and how we plan to address it.

Some of the top recurring feedback we have heard is:

I want to address each of these points individually.

How we will avoid a "two-tier" NuGet community

We want any package owner to be able to reserve a package ID prefix that uniquely relates to them, but we also want to avoid package ID prefix squatting. As a result, we came up with questions to ask about each application before accepting a verified prefix reservation. These questions are designed to help us achieve our goals of making sure anyone can reserve a prefix, but nobody can squat on a prefix they don't deserve.

Based on feedback, we will remove the 6th question from how we evaluate applications. This feature is about reserving a package ID prefix and not on evaluating package quality. The 6th question also did not contribute to our goals. It's repeated below for convenience:

  1. Does the package owner submit original content under the package ID prefix that provides a tangible benefit to the package consumers?

In addition, we added some clarifying text regarding how we will evaluate the criteria. Not all criteria needs to be met for a package ID prefix reservation. Take a look at the updated spec for additional clarity.

Any package owner should be able to reserve a prefix that uniquely identifies them. The more unique and qualified the prefix glob pattern, the more likely the application is to get accepted. For example, if I wanted to reserve diverdan92.PersonalPackages.*, and all of my packages have an author of "diverdan92" (or Daniel Jacobson), I would likely get accepted. All packages submitted to that prefix glob pattern will then have the reserved prefix verification checkmark. However, if I wanted to reserve CoolStuff.*, I would get rejected as that is something that does not relate to me as the owner whatsoever.

In addition, we will heavily weight time in queue to prioritize applications. We will try to get a response to all applicants within a reasonable amount of time, and for any denied applications we will provide a reason as to why the application was denied.

Supporting any NuGet feed

We will publish the server protocol we use for marking packages as having a reserved package ID prefix. Any feed administrator will be able to apply this property to packages coming from their own feed. In the Visual Studio package manager UI (and other clients), we will only have a visual indicator that designates a reserved package ID prefix when a single feed is selected as the package source. If the package source is set to "All", this feature will be turned off as it may create additional ambiguity since it will be difficult to determine which feed is validating a reserved prefix. For example, it's possible to have multiple versions of the same package ID coming from different feeds - saying the prefix is reserved for that package may only be true for a subset of the package versions.

Making it easy for other NuGet clients

As a new experience for NuGet, we expect other clients to adopt the feature over time as well. To accelerate this process, we will provide guidance and a "spec" on what the expected behavior should be for other clients to implement. This will include all the necessary information for other NuGet clients to implement a similar experience suited for their own product.

Supporting library extensibility

Another scenario that came up was for package owners that want to open up part of the ID prefix to the community for extensibility. We will allow owners to have subsets of their ID prefix to be "public", meaning any owner can submit to that ID prefix. For example, I can have "MyOpenSourceLib.*" reserved to my account, but "MyOpenSourceLib.Extensions.*" public to any package owner. Any public prefix subset will not have the reserved identity visual indicator, but it will allow any owner to submit or update packages under that prefix.

VictorBlomberg commented 7 years ago

@diverdan92

@VictorBlomberg Great feedback. I've updated the section in the spec outlining acceptance criteria. Will you take a look and let me know if there is additional ambiguity that you would like addressed?

Sorry for my slow response. That looks great, my concerns are addressed!

Thank you for taking your time. :)

maartenba commented 7 years ago

Given all the activity and announcements being made, I was wondering about this one here:

We will publish the server protocol we use for marking packages as having a reserved package ID prefix.

Having looked into previous commits, it seems only part of the V3 feed protocol, and involves a boolean "verified": true in search results. Are there any other server-side things that need implementing?

clairernovotny commented 7 years ago

This should not be a protocol level feature. That could lead to conflicts across different feed sources. That would also then not work off-line, if a user wanted to see if it was a verified prefix from a particular feed source.

maartenba commented 7 years ago

[edited] will await reply from NuGet folks as I really just want a server-side spec.

clairernovotny commented 7 years ago

I'm saying it should be part of the package signing feature, metadata per feed source tucked in the package. Can discuss offline.

maartenba commented 7 years ago

Not that discussion again :-D

diverdan92 commented 6 years ago

Thanks everyone for your input on this feature. The feature is now available and announced on the announcements repo. You can check out the documentation as well.

zvirja commented 6 years ago

@diverdan92 @onovotny I've just tried to send the application for the AutoFixture organization as described here:

Send a mail to account@nuget.org

However, I've got denial request from your firewall:

[http://products.office.com/en-us/CMSImages/Office365Logo_Orange.png?versio= n=3Db8d100a9-0a8b-8e6a-88e1-ef488fee0470]

Your message to nugetpm@microsoft.com couldn't be delivered.

The group nugetpm only accepts messages from people in its organization or = on its allowed senders list, and your email address isn't on the list.

autofixture1 Office 365 nugetpm Sender Action Required

Sender not allowed

I've tried different email addresses (e.g. autofixture1@protonmail.com and my personal one on gmail), but neither one worked.

Is there any other channel where I can post the reservation application? It a bit strange to put contact address and forbid all mails from outside.. 😕

FransBouma commented 6 years ago

@zvirja I sent an email yesterday to the account@ email address which went through (no bounces at least) normally. Something must have changed after that it seems.

zvirja commented 6 years ago

@FransBouma Yep, it seems, as I used two different mail addresses. Hope Microsoft haven't banned me 😄

diverdan92 commented 6 years ago

@zvirja - don't worry, we got your mail! I'm looking into why that bounced. We'll try to resolve this as quickly as possible. Rest assured, I do see the mail in our queue. You should expect to hear back from us by middle of next week or sooner.

@FransBouma - you should hear from us by end of the week 😊.

diverdan92 commented 6 years ago

With the release of this feature and documentation, I'm closing this issue.

tjpalmer commented 7 months ago

Should we still figure messages like "only accepts messages from people in its organization" are no big deal?

nightroman commented 7 months ago

Sorry for the not quite right place but I am not sure yet it's worth a new issue or where to create it.

My ID prefix reservation request email to account@nuget.org keeps bouncing. The problem was mentioned in this thread. Is it something temporary and I should just wait or keep sending, hoping it gets resolved?

UPDATE: It looks like they still got my emails, so it's not an issue. I keep the comment though as the fact that bouncing happens at times.