ietf-smtp
[Top] [All Lists]

Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)

2005-05-24 14:40:58

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
outlined.

OK, I stand corrected.

It doesn't fiddle with domains or senders ... it is a simple 
way for the admin of IP space to tell others whether s/he thinks that
a certain IP is associated with a mailserver that should send mail
accross the public Internet.

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.
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).
3. like other IP based schemes, it doesn't play well with DHCP and
   NAT.
4. While some parts of IP address space might be managed in a way
   which is amenable to the approach, other parts have many widely
   separated class C ranges under one administrative entity, which
   would seem to mean managing each of those ranges separately.
5. I'm not thrilled about the "unmarked" yes->no flag day concept.
6. authentication is fine where there is a prior arrangement,
   however one of the fundamental principles of email is that it
   permits communications with no prior arrangement.
7. Simply publishing information about which IP addresses might source
   messages may reveal information of potential use to an attacker
   (not mentioned in security considerations).


<Prev in Thread] Current Thread [Next in Thread>