I agree fully when you say that some pull servers will be attractiv to hack.
In a pull system the best way to avoid blacklists is to hack pull servers.
With SMTP you do not have to do it, it is a complete waste of time. That is
why I suggested encryption. If the mails are encrypted and the key trown
away there will be no point in hacking the pull server. After "decryption"
the mails will be unreadable. :-)
It is sufficiently difficult to properly implement cryptographic
message signing, much less message encryption. Moreover, the
existing systems implement this sort of thing where the spare CPU is
most available -- on the client. You would be increasing by untold
orders of magnitude the amount of message encryption that would be
required (above what is happening today), and you would be doing it
centrally -- the one place in the architecture that has the biggest
CPU crunch already.