On Tue, 24 May 2005, Bruce Lilly wrote:
On Tue May 24 2005 16:43, Markus Stumpf wrote:
On Tue, May 24, 2005 at 10:09:12AM -0400, Bruce Lilly wrote:
On Mon May 23 2005 14:39, Frank Ellermann wrote:
The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
do very different things, SPF covers some older ideas.
They all suffer from similar problems involving the issues
*ALL* is wrong as MTAMARK does neither of the 3 points you have
OK, I stand corrected.
The same is true for CSV.
I've proposed an extension to CSV which specifies how to place CSA records
in the reverse DNS. With this extension it becomes a superset of the
MTAMARK functionality. The implementation of CSA in Exim includes this
As I understand it from a quick skim, there are however some issues:
1. it speaks of MTAs and mail severs, however an MUA or MSA may also
send mail, and there is at present no way for an SMTP receiver to
determine whether the connected sending client is an MUA, an MSA,
or an MTA.
This is usually done operationally, by providing different service
addresses for MTAs (your MX hosts) and MUAs (your MSA hosts). An MUA
connecting to an MX isn't going to have an easy time.
The MSA concept is rather weak in Internet email. It only really makes
sense as an SMTP receiver. Its sending side operates as an MTA. It isn't
necessary to talk explicitly about MSAs when writing about MTA-MTA
2. it speaks of "unauthorized message transmission", but SMTP has
no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
used for sending (pushing) mail).
Authorization in SMTP is determined administratively, either based on SMTP
AUTH or other out-of-protocol criteria such as DNS blacklists. MTAMARK and
CSA are new ways for one site to communicate authorization policies to
another site. Since it's an out-of-protocol extension, the limitations of
basic SMTP are irrelevant: the purpose of an extension is to overcome a
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR