ietf-asrg
[Top] [All Lists]

Re: [Asrg] Email Postage (was Re: FeedBack loops)

2008-11-21 12:17:29
On Nov 20, 11:20pm, Gerald Klaas wrote:
}
} Yes, it is the recipient that decides to enforce a "stamp" framework
} and has to decide if it makes financial sense to re-engineer their
} mail system.  So how do you suggest that such a standard would
} require the minimal effort to implement?

I was suggesting that it's up to the more vociferous proponents of
the idea to come up with that answer ... but since you asked:

Simplest would probably be to model the base mechanism after the DSN
standard (RFC3461).  Client sends EHLO, server responds that it will
accept postage.  Client appends a parameter to the MAIL command with
the identity of its payment service(s).  Server accepts or declines,
attaching an extended status code for details.  Client then appends
to the RCPT command a parameter indicating how much the sender is
willing to pay for this message, and server accepts or declines,
again with an extended status indicating the charge the server wants
to deliver the message, regardless of whether it was declined.  If it
was declined for insufficient postage, the client can re-issue the
RCPT with the offered postage increased.  If the client deems the
charge too high even though it was within the original offer, it can
end the transaction without issuing DATA.

In all of this I assume that 2xy continues to mean "go ahead", 4xy
"try again", and 5xy "no further negotiation possible".  If the client
does not offer postage, the server can wait for the DATA command and
look for a postage token in the message header (see below).

Otherwise, on 350 response to DATA, server has taken responsibility
for making a best effort to deliver the message without charging the
original sender's payment service more than the agreed postage.  For
a relay, that may mean that it has to negotiate its own payment for
the next delivery hop, but it could also pass along the original
parameters, possibly with the offered postage decreased by a routing
fee.  This would need some tokens along the lines of the DSN ENVID
to validate the transactions back to the original sender to avoid
fradulent charging.

At final delivery, or in the event of relay to a hop that doesn't
support the postage standard, the MTA can insert a cryptographic
token computed in a DKIM-like way over some excerpt of the message
and headers, containing the original postage parameters and the
amount of postage deducted by the relay.  (It could even be a DKIM
parameter, I suppose.)  This can be checked by an MUA or used by
another relay to reconstruct the MAIL and RCPT parameters for the
next hop.  A separate trace, probably in the Received: header,
might be needed whenever such a transition from in-message to
in-protocol postage occurred.

An MUA could also slap on one of these headers to start off the
process in the event that the submission server doesn't support it.

} Goodmail CertifiedMail(TM) is not based on an open standard, requires
} a central authority, and requires a sender's ISP to implement it in
} their MTA.

Yes, and Goodmail is patented, which means that any open scheme that
has a similar effect would have to pass a patent challenge.  I have
no idea whether what I described above would infringe that, or
whether it might infringe on claims made by brandmailsolutions.com
(who already has a scheme for overloading DKIM with a cert token).

Note also that I haven't made any claims about the likelyhood of that
implementation being accepted (I haven't, for example, been following
how widely the DSN standard is implemented) and I'm quite sure I've
overlooked all sorts of security concerns.  But if you need a strawman
implementation to argue financial feasibility, there you go.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg