What are the different types of spam that the Lightning Network is subject to and what are the possible strategies for dealing with such spam?
There are three types of spam problem in the Lightning Network. Let's call them "local","fast" and "slow".
Local spam is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.
Fast spam is sending many failed payments. You can't tell what will succeed and you can't blame the sending peer (they may not be the source). This attack is free since we only pay on success. The answer is to require an up-front payment but it has to be small (making sure your incentive is to succeed) and it should not leak information on where you are in the path. I've been unable to find a scheme I'm happy with though, see my latest attempt here.
Slow spam is sending a long-lived payment. This consumes capacity > 1000x expected for a normal payment and is similarly free (if you fail). The only solution I like here is to penalize slow payments by requiring proof-of-channel closure but you can't always tell if the payment was really in the channel and what if the close transaction pays super-low fees / conflicts? You need a Merkle tree of claimed HTLCs, plus onion unwrapping, agreement on valid closes, handling of fake Merkle trees... all possible but real work.
Summary: We can mitigate some attacks but real fixes need spec improvements and implementation. More attention from Smarter People Than Me (hi!) will help us here.
This question was answered by Rusty Russell on Twitter.