At least one of the large providers has told me they plan to do OAUTH submission, presumably with long lived tokens, which would greatly mitigate the security issues.
I'm trying to track down what's actually going on here. It's SUBMIT either way, so everything in the code except the way that authorization is sent to the SUBMIT server is the same.
After digging through a festival of acronyms, I ended up at RFC 6616.
Mail submission (port 587) is defined in RFC 4409. It refers to RFC 2554, now replaced by RFC 4954, which defines the AUTH extension to SMTP. That in turn punts to SASL, defined in RFC 4422, which describes the authorization framework and the initial schemes. RFC 6616 adds OpenID as a SASL authorization scheme. It's fairly impenetrable, but I know the guy who wrote it, so I can probably get some help, and it's definitely a standards track document so we can expect everyone who implements it to do so in the same way. OpenID tokens can be very long lived -- I've been doing programmed posts to my Twitter account using the same token for several years.
There are certainly OpenID libraries, but I don't know to what extent anyone has written the code to splice them into SASL. It (SASL) is used for many mail applications including POP and IMAP. Considering how easily malware can scrape passwords out of software on PCs, I expect that the providers have considerable incentive to replace them with OpenID tokens in MUAs.
I would propose doing the submission hack, explicitly noting that SASL has a variety of different ways to authenticate with different usability and security trade offs.
R's, John