Guerrilla Mail can lose their domain due to attack on disposable emails | Hacker News Reader

Guerrilla Mail can lose their domain due to attack on disposable emails

twitter.com

50 pointsdmantis8 comments

Here are some of their earlier tweets which explains a bit more what's going on:

> URGENT HELP! @PIRegistry is about to delete our guerrillamail(.)org domain. This is due to a false-positive SURBL listing. The domain does not send any email and is not used in any marketing, ever! It simply receives email and redirects web traffic to our main domain.

https://twitter.com/GuerrillaMail/status/1476564690595889155...

> This is not the first time. We have been going through this a few times this year. We get a threat from @Namecheap's legal department for deletion, we submit a SURBL request to remove.

> However, this time SURBL doesn't even look at our ticket.

https://twitter.com/GuerrillaMail/status/1476564692714004486...

> We really do not want to lose this domain. It's been with us since 2006.

> (We really do not have anything against @namecheap since they are only following procedure. Perhaps somebody with a more direct line with @PIRegistry or somebody at SURBL could look in to this matter?)

https://twitter.com/GuerrillaMail/status/1476564906690646016...

What's the context here?

The context is literally the previous tweet.

Which is literally not what is linked to.

https://twitter.com/GuerrillaMail/status/1476564690595889155

"URGENT HELP! @PIRegistry is about to delete our guerrillamail(.)org domain. This is due to a false-positive SURBL listing. The domain does not send any email and is not used in any marketing, ever! It simply receives email and redirects web traffic to our main domain."

how is this happening without a human in the loop?

I don't know the answer but I do see some things missing that could have helped assuming automation checks this though it may not

They say the domain isn't use for sending mail but it does have an MX record which means it receives emails. No problem, maybe automation receives emails. Some systems will use this to say that this domain is used for email even if just for receiving.

  dig +noall +answer -t mx guerrillamail.org
  guerrillamail.org.      3600    IN      MX      1 mail.guerrillamail.org.

To tell automation that this domain does not even receive mail, one could optionally set:

  guerrillamail.org.  14400   IN      MX      0 .

However...

  dig +noall +answer -t txt guerrillamail.org
  dig +noall +answer -t txt _dmarc.guerrillamail.org

The above two have no answer. They are missing SPF records and DMARC policy that could explicitly state the domain does not send email. It should instead look something like this:

  dig +noall +answer -t txt guerrillamail.org
  guerrillamail.org.          14400   IN      TXT     "v=spf1 -all"

  dig +noall +answer -t txt _dmarc.guerrillamail.org
  _dmarc.guerrillamail.org.   14400   IN      TXT     "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s;"

But those records do not exist. This is assuming some automation is in play here and very much assuming that automation checks such things. I have no idea if that is the case.

Email headers can be spoofed so I would expect multiple reports to come in from multiple noteworthy organizations before dropping a domain by a human. If their registrar are understaffed then it is entirely possible they are relying on automation for this.

The part I do not understand is why they are dealing with the legal department unless the reports are coming in from multiple organizations. Could their systems be compromised, sending spam and they don't realize it? Could the legal department just be going through the process but just want to get rid of a domain that is causing them to receive baseless legal threats? Anyway at this point if I were them I would unlock the domain, get the transfer code and move it to another registrar. If they refuse to give the transfer code then get a lawyer to make it clear to the registrar they won't give up.

I forgot to add that if one is to set SPF/DMARC records to show the domain is not used for email then there should be the same TXT records set on a wildcard DNS entry to match spoofed non-apex records.

  *               4h      in      txt     "v=spf1 -all"
  *               4h      in      mx      0 .
  *._domainkey    4h      in      txt     "v=DKIM1; p="

Reply on news.ycombinator.com