And what protocol would you use to verify this?

The envelope on an SMTP message is very similar to an envelope on a postal message. How do you know that Joe is actually the person who put his return address on the envelope and dropped it into the postbox. Jane could have just as easily addressed the envelope and posted it, and you could not tell the difference.

I can send a message that looks very much like it came from Joe, even if I am Jane. You cannot believe any header on an SMTP message unless you verify it with trusted logs. The only headers I believe in messages I receive are my own networks, and possibly moving back from there, depending on the level of trust I have.

This becomes even easier if the message is able to be injected along the same path that a legitimate message would take.

One last point - if Joe "automatically" generated 50K responses on my network, he would be severely LARTed.

How about putting an extra header in the mail headers. Lets call it "X-check". It would contain some sort of cryptographic hash, and when the 50000 people who Jane mass mails, will check to see if it matches Jane's id in their database. It it dosn't, Jane gets emailed for a confirmation. If she forged the return address, she will never generate a confirmation, and the 50000 recipients will dump her mails to /dev/null; and Joe will never receive a thing.

Look I'm don't want to argue the fine points of this. Maillists seem to be able to function with this sort of checking without spammers getting in. So I would say that the mail headers are the key to this. If the "return-path" dosn't match the "sender", or if something is amiss in the "X-check" header, then drop the message.

The whole thing could probably be done with the current pgp keysservers. Just put in the X-check header, something that Joe can check with public keys.

You will never be able to stop mail bombs, or DOS attacks.

My original point was this type of software is starting to popup. Some are as crude as to put and encrypted string in the subject line, which both the sender and receiver can decode. Joe can just drop anything without the encrypted string in the subject line; and he can also decrypt the line, and see if he gets the email address of the "alleged sender". He can drop anything he wants.

If you don't like the idea, thats fine. But i would rather be in control of it as a user, rather than have some ISP's filter deciding things.

As far as LARTing joe for 50,000 responses, what do you do about "innocent joe" receiving a 50000 count mail bomb? of the claimed sender.

This problem is the sort of issue that RMX and DSL are trying to 'fix'. They're trying to make it harder to fake who a message is coming from. Admittedly, they only work on verifying the domain (actually the 'ISP' in many cases), but it's better than nothing. To verify the actual person, you're getting into digital signature territory, which many people have privacy issues with.