Re: SPF is harmful. Adopt it.

JCB> But if my SMTP server waited until *after* the DATA phase to
JCB> temporarily reject a message, [...]

Then there would be two copies of the message, one local and one remote, the
entire message would have had to have been transferred across the network, and
the remote end would be scheduled to send it _again_ at a later time.

Contrast this with Charles' scenario, where there's still only one copy of the
message, the entire message has _not_ been transported across the network, and
there's nothing that's waiting around intending to try to send the entire
message across the network at some point in the future.

JCB> (And, again, this can't be done at all in IM2000-land if 
JCB> the remote message store is unavailable.  I know a message 
JCB> is waiting for me; I just can't see it.  I think that'd be 
JCB> very frustrating.)

Double standards yet again.  If network connectivity is unavailable, then the
message couldn't have been sent via SMTP in the manner that you describe.

CC> If this happens more than once, I'll likely instruct my
CC> notification agent to ignore notifications about messages on
CC> foobar.example.com, /regardless of where the notification 
CC> comes from/.

JCB> Similarly, I'd likely instruct my SMTP server to permanently
JCB> reject incoming messages from foobar.example.com, regardless 
JCB> of relays through which such messages passed.  (Parsing
JCB> "Received:" headers is a PITA, but it can be, and is, done.)

This is where your attempt to make SMTP-based Internet mail do the same task
stretches SMTP beyond its breaking point.  Trace headers can, have been, and
are, forged.

Whereas with IM2000 Internet mail there simply _is no_ relaying.