Re: e-postage stamps, was Welcome to the new(ish) ASRG list
Brendan Hide <[email protected]>
| Newsgroups | gmane.ietf.asrg |
|---|---|
| Message-ID | <[email protected]> |
On 17/03/13 13:06, Franck Martin wrote: > You mean like DMARC? DMARC certainly looks interesting - but no, it is not like my idea. Unless you're referring to the point of "cooperation" - there it looks like they are achieving good momentum through simple cooperation. My idea is certainly not fully fleshed out - there are aspects of it which may seem unnecessary and there are aspects which are probably useless or wrong. Heavily summarised, see below: Configuration: When first configuring the MUA, a password for the account can be used to retrieve a key. This is the only time the account password should be needed. Sending: MUA generates an authentication token for itself from it's key. The authentication token is intended to be "one-shot". MUA attempts to send email directly to MX records using the authentication token. If the MX server doesn't support the authentication method then the MUA must fail over to using its own MTA with the "old-school" method. The MX server verifies the authentication token with the MTA and records the verification information in the headers. If this verification fails then an error is given to the sending MUA and the session is ended by the MX server. Additional information can be given by the MTA in the error or success messages to the MX server to ensure accurate and responsible delivery or rejection messages. Assuming success, the MUA completes sending the mail to the MX server which accepts the message. The mail is delivered to the end-recipient. From the above you may deduce that this obsoletes Sender Callout Verification. Reporting: In the situation where the mail is determined to be spam (This could be any function within the recipient domain, from the user simply moving the mail to a "Junk" folder, to the MX server noting that it has a very high spam score): The MX server (or end-recipient MUA) contacts the sender's MTA with the authentication token and verification information that is already in the mail's headers and reports that the mail is Spam. The MTA can then make an automated decision of whether or not to suspend the sender. It could suspend the MUA or the account entirely. The MTA can take a lot of data into account on when an account or MUA access should be suspended, however the primary means will probably be the number of reported spam messages. RBLs: RBLs would NOT be obsoleted by this. In fact it will make new RBLs very important. An ISP implementing measures such as this but, for whatever reason not enforcing the suspension measures, would end up being listed in these new RBLs. Effectively an incompetent or irresponsible ISP's customers would not be able to authenticate emails using this method and they would lose any advantage gained by using it. -- __________ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97