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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.