Kind of thinking out loud here - not sure anything can/should be done.
Recipient address verification means - to me - that the recipient address has been pre-qualified by our server. So when a user presses "send" on their client, and the message disappears into the mysterious ether - I'm reasonably confident their message went SOMEWHERE.
Without recipient address verification - when the user presses "Send" - my server takes the message and tries to send it. And until the user gets a delivery failed notice - they mistakenly believe the instant the message leaves their screen it has reached its destination.
Which leaves the sysop a choice - either have the users complain that their mail is broken (when the "recipient verification in progress" message appears - and it doesn't matter how many flipping times you tell them to READ the g*dd@mn thing - especially when you can see the spelling error right in front of them!) or have the users complain that their mail is broken because even though they pushed Send the recipient "never got the message".
I've opted for the first - but I'm wondering if the end-user experience can be improved at all - particularly for those who refuse to be educated, and unfortunately the world is full of those. What about a blend of the two operations? What if, on a non-verified address, and verify receives a defer error (which means we've actually reached a mail server - not necessarily the correct one, and the address can still be wrong, but our chances are pretty good now) to go ahead and accept the mail from the client - but immediately return a message that indicates verification is in progress. And then repeat those status messages until successful delivery or it gives up.
It increases the chance for having garbage in the queue - as it doesn't allow the user to read (what's that mean?!) the message and self-correct their typos - but it could increase user efficiency. Any thoughts? Am I underthinking this as usual?
-- Daniel
