Unverified.email

> safe, meaning that applying it to a resource does not result in a state change of the resource (read-only semantics)

It should never be used to -create- anything, only to retrieve existing resources (and not change their state). For creating we have POST requests. Obviously no one is going to care or do anything about it if you use GET, but if we're going to be pedantic le t's not mischaracterise GET requests.

   Request methods are considered "safe" if their
   defined semantics are essentially read-only; i.e.,
   the client does not request, and does not expect,
   any state change on the origin server as a result
   of applying a safe method to a target resource.
   Likewise, reasonable use of a safe method is not
   expected to cause any harm, loss of property, or
   unusual burden on the origin server.
  
   This definition of safe methods does not prevent
   an implementation from including behavior that is
   potentially harmful, that is not entirely read-only,
   or that causes side effects while invoking a safe
   method.  What is important, however, is that the
   client did not request that additional behavior and
   cannot be held accountable for it.  For example, most
   servers append request information to access log files
   at the completion of every response, regardless of the
   method, and that is considered safe even though the
   log storage might become full and crash the server.
   Likewise, a safe request initiated by selecting an
   advertisement on the Web will often have the side
   effect of charging an advertising account.
  
   Of the request methods defined by this specification,
   the GET, HEAD, OPTIONS, and TRACE methods are defined
   to be safe.

A subsequent GET may return different data because another POST/PUT modified the data but a GET should never modify the data itself (e.g. i won‘t be able to safe this comment by GET but by POST).

That it doesn't actually relay mail doesn't hinder its spam potential.

The few times I've hosted something like this (previously running open source https://gitlab.com/markbeeson/maildrop), it just never ends well.

What typically happens is abuse reports start rolling in for mass forum spam, mass registration, comment spam, domains get blacklisted and added to global blacklists like URIBL.

Over time as bad actors found it, I eventually was doing more than 50-80 Mbps of _purely text traffic_ of bots flooding registrations, inbound SMTP traffic of nothing but spam, bots effectively sending DoS-level requests looking for activation links. It was frustrating to want to run something fun and inevitably end up spending half your day responding to "this is a development/testing INBOUND ONLY mail service, we did not originate the spam, we are not signing up 5000 times to your forum", adding a domain blacklist to never show messages from certain websites, etc.

But I'm curious about your statement:

> if you're intent on not letting users sign up with disposable email addresses (and you shouldn't be)

Why not? It seems like some people are eager to not be on any mailing lists, and the worst downside seems to be that they won't able to reset their password.

Yahoo.com et al. are still available to create one-off emails to allow someone to get past a (say) 14-day free trial every 14 days, so how does blocking these guys help?

587/TCP is the "submission" port and is exactly what people should be using instead of 25/TCP (it usually -- but not always -- requires authentication and is pretty much never blocked). Indeed, that's the intended purpose!