Nothing, but it's also too slow, and pointless for them: It's easier for them to just send. Many of them clearly don't even care about checking response codes, or retry after greylisting, which is why these techniques works (greylisting cut our spam volume by about 90% off the bat).

But there's also no guarantee that the remote server will reject the address until after you've actually submitted a full e-mail, and send the final "." , exactly to make it even more expensive for spammers, in which case any attempt at checking short of actually sending an e-mail will fail.

Their suggestion may give you an indication, but if you try to rely on it you'll get a lot of pissed off users.

On a an unhardened SMTP server, nothing. But there's not a huge amount of value for them in sanitizing those lists either, as they already deal in such high volumes of mail a few retired accounts don't matter. There are anti-spam products from places like GFI that can apply heuristics to incoming requests and filter out anything suspect though.

The bigger risk is directory harvest attacks, where spammers dictionary generate RCPT TO requests and use any 250/251 replies to compile new mailing lists.

Tarpitting combats this to some degree and is considered best practice when allowing RCPT replies. The receiving server is configured to pause for a few seconds before replying to each RCPT TO. 5-10 seconds is fast enough to not impact mail flow while rendering dictionary based directory harvest attacks non-viable.