It helps in strawman cases when users have the data, and the platform doesn't have social features. For instance, oh, an online photo editor used by the user in isolation, on either local files or easily downloadable files. User doesn't like that instance, so they find the AGPLed source code and run their own, bringing all their files.

(Why, in that situation, would the user be entitled to the custom modifications in that instance they are abandoning? If you don't like that instance for whatever reason, but like the features, tough luck. Code your own.)

Sorry that was a typo we should have said "do not have the program" (corrected).

But no the same is not true of the user of the AGPL. The GPL user having the source code and being able to program or hire somebody is utterly meaningful. That user controls the installation of the program. They would like the program to do something differently, or not to do something unwanted. With the buildable source code they can achieve that.

The visitor to the AGPL application have access to the source code has no meaning at all. They don't have the administrative access to replace the implementation (and even if they did, that was just create conflict with the other ivisitors).

The ability to set up your own clone instance its completely meaningless. For example suppose that's some government service website is using AGPL software. What do you gain by downloading the software and running your own instance? That's not where your data is; you can't use that cloned instance to communicate with the service agency.

It is the AGPL that's using outdated concepts in a new context where they don't make sense. (Licensing helped us win the open source war in the 1990s and 2000s, so it'll work this time too right?)

You also may be thinking of the software of being something like a photo editor or word processing application that is hosted, but in which the visitor works with only their own files in isolation from other visitors, and from the site operators. I don't think that's the main target for the AGPL. That may be called "strawman AGPL". I tend to agree that the AGPL may be effective in this limited situation. But effective is not the same as free. A "free for personal use" software license is also effective at achieving the aims of its purveyor but isn't free.

Really cool. I couldn't find it documented anywhere, but if you save the unique (guid) url generated, how long is that available for? "Forever"?

I don't want to burst bubbles, but postfix with few lines of config can redirect all email to DEVs.

You really want, whenever possible, to test everything using real tools. Doubly so, using tools you'll use it PROD. However, at least postfix is de-facto standard.

apt-get install postfix, postfix-pcre bsd-mailx, config and done.

Here's an example redirecting ALL outgoing emails, UNLESS they are to your OK domains. Redirects are sent to an alias in /etc/aliases, which you can point to anything. (Easier for DEVs to modify when required)...

  /etc/postfix/header_checks (adds a header with original TO) 

  /^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ PREPEND DEV-ENV-REDIRECT: ${1}@${2}

This MUST be the same as the above regex, so that the TO preservation + redirect are both done in tandem..

  /etc/postfix/recipient_canonical_map
  /^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ externalredirect@localhost

Then in main.cf

  # added
  recipient_canonical_classes = envelope_recipient
  recipient_canonical_maps = pcre:/etc/postfix/recipient_canonical_map
  local_header_rewrite_clients = permit_mynetworks
  #
  header_checks = pcre:/etc/postfix/header_checks

Then in /etc/aliases:

  #
  externalredirect: dev

  # dev's email.. (default unless set)
  dev: /dev/null

Preserving the original TO as another header ensures you can debug if required, whilst preserving 100% the original mail body.

Using a second redirect in aliases, allows you do something such as:

/etc/aliases:

  #
  externalredirect: dev, another_email_address_for_logs

  # dev's email.. (default unless set)
  dev: /dev/null

So it's super easy for a dev to just change:

  dev: /dev/null

to

  dev: dev@corp.com

Without the need to worry about overall redirect stuff.

NOTE that if you don't have a unique email for your company's DEVs to use, this won't work, HOWEVER... you can redirect with more refined controls above.

That is, instead of saying "if it's not to a company domain, then redirect this DEV TEST email!", you can "If not to this specific email address, then redirect to this specific email address".

The reason I have this setup to redirect of not corp domain, is that the env I have this deployed in is byte per byte 100% identical to PROD deployment, with only very, very, very, minor tweaks. About 20 bytes or so.

That way, all tests done in DEV are 100% identical to configs in PROD. You eliminate PROD deploy bugs more aptly this way. And so if local MTAs are postfix in PROD, then you can keep all of your PROD postfix configs, with these minor changes to lock down DEV. And, you can keep the all the config files, all the config, and just have empty header_checks, recipient_canonical_map files.

But this means that alert emails that might get send from PROD have genericized domains, so in such envs it's easier to NOT redirect corp dest emails carte blanche, and then send everything else to a redirect dest.

That way monitoring / emerg emails get through unvarnished.

Don't they all "allow receiving emails from your prod env"? They all speak SMTP. What am I missing?

That's the wrong status code

The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").

Unless the server believes you as an individual user were sending too many it should not have been a 429 If the server was unable to handle the volume of requests more generally it should have been a 503 which also supports Retry-After