Currently if a new incoming transaction will cause -limitfreerelay to be exceeded then it will still be accepted into the memory pool and the byte counter updated only after the fact.
What I've been seeing during this attack is that dFreeCount will often get up to 140 to 149KB then the next spam transaction of 15KB will still slip through to bring the total up past the 150KB limit ( limitfreerelay default set at 15), whereas I think it shouldn't be accepted if it's going to exceed the limit. This only allows the attacker to slip through large transactions past the limit, which could be any size up to the transaction size maximum.
