Subject: [Asrg] spf

From: [email-masked]
Date: Sat, 27 Mar 2004 09:09:52 -0300

this is a tentative option to spf, but does not
seem to break forwarding:

http://nucleo.freeservers.com/mba/

have fun. gone, ricardo.

---

From: "Radu Hociung" <[email-masked]>
Date: Sun, 28 Mar 2004 12:58:03 -0500

Unfortunately,
 
A spammer can just as well set this up. This system does not discriminate
based on the intention or identity of the sender.
 
Also, I think a good test to any anti-spam proposal is this: Would this be
a sustainable model if it became mainstream?
 
Your approach relies on a lot of wasted resources at the DNS cache level;
imagine what would happen to Hotmail's caching DNS servers if they would
cache two entries for every 2.5B spam messages they receive every day?
 
I didn't like the pop-ups.
I appreciate the effort, though; you may have something, but it needs more
work.
Radu.
--
Radu Hociung                                                 [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, March 27, 2004 7:10 AM
To: [email-masked]
Subject: [Asrg] spf

have fun. gone, ricardo.

---

From: "Ricardo Dirani" <[email-masked]>
Date: Sun, 28 Mar 2004 17:51:17 -0300

MBA doesn't fit in MXCOMP. "A mechanism to identify authorized senders for a
domain". Both LMAP and SPF do that. MBA doesn't. MBA identifies if a message
was actually sent by a domain. If MBA works as intended, spammers won't use
it, because by using it, their domains would be promptly recognized and
easily blocked by most mail hosting providers. Assuming MBA is widely
adopted, a picky receiving MTA could choose to only accept mba-authenticated
mails.

Ricardo

----- Original Message -----
From: Yakov Shafranovich <[email-masked]>
To: Radu Hociung <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, March 28, 2004 4:35 PM
Subject: Re: [Asrg] spf

> LMAP-related discussions for SPF and other proposals have moved to the
> MXCOMP list (http://www.imc.org/ietf-mxcomp/).
>
> Yakov
>
> Radu Hociung wrote:
> >
> > Unfortunately,
> >
> > A spammer can just as well set this up. This system does not
> > discriminate based on the intention or identity of the sender.
> >
> > Also, I think a good test to any anti-spam proposal is this: Would this
> > be a sustainable model if it became mainstream?
> >
> > Your approach relies on a lot of wasted resources at the DNS cache
> > level; imagine what would happen to Hotmail's caching DNS servers if
> > they would cache two entries for every 2.5B spam messages they receive
> > every day?
> >
> > I appreciate the effort, though; you may have something, but it needs
> > more work.
> > Radu.
> > --
> > Radu Hociung
[email-masked]
> >
> >
> >     *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> >     Of [email-masked]
> >     *Sent:* Saturday, March 27, 2004 7:10 AM
> >     *To:* [email-masked]
> >     *Subject:* [Asrg] spf
> >

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 28 Mar 2004 14:35:04 -0500

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 28 Mar 2004 16:02:32 -0500

Why is this better than DomainKeys which authenticates the message body 
against a public key in DNS? In this scheme, a separate MD5 would have 
to be stored in DNS for every message, with DomainKeys it is enough to 
store the public key.

Yakov

Ricardo Dirani wrote:
>>>Radu Hociung

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 28 Mar 2004 14:36:43 -0800 (PST)

> >     http://nucleo.freeservers.com/mba/

This is actually not LMAP, what is proposed there is simplistic type of 
message tracking. But the way its describes has 0 chance of being workable 
in the real life when millions of emails are exchanged. DNS is simply not 
capable of being used for such purposes.

Where as tracking has number of positive implications and provides for 
pretty good way to verify that some particular message did indeed come 
through such and such mail server, it does have its drawbacks in necessity
for servers to maintain this information (which all of the MTAs already do 
in the logs in reality) and provide public access to it in real-time on 
the net (which itself does break existing mail system since its peer-peer 
and there is no guarantee that recepient mail server is on the same 
network as sender and that they could contact each other in real-time) 
and such system could also be exploited for possible DoS attacks (although
that is true about standard email or dns or many other protocols and is 
something that can be dealt with with carefull engineering of protocol 
and implementation programs). But in any case message tracking would need 
to be its own protocol or built in as part of MTA callback verification 
and not in any way done with dns which is not scalable for such system.

Another way to do message tracking that does not require separate running 
service to confirm the message data is to do use cryptography. Several 
possibilities exist there from signing original message from the sender
end (PGP, S/MIME) to adding some type of cryptographically verifiable 
tracking information by MTAs, such as signing received header data or 
having MTAs compute some has for the message and sign that (this is 
what Yahoo has proposed with DomainKeys - I'd love to see the details as 
this really looks like a good proposal which does not break existing 
infrastructure).

---

From: "Radu Hociung" <[email-masked]>
Date: Sun, 28 Mar 2004 19:15:37 -0500

Perhaps I didn't understand something.

What I meant is that spammers can use a through-away domain or a temporary
subdomain (say "Mar282004.spamnet.net"), run a DNS server with enough
capacity to authenticate the day's spam-run. To block emails verified by
such a system, one would need to use some blacklisting technology against
Mar282004.spamnet.net or spamnet.net. But if you need a blacklist to enable
this message-body-authenticator technology, where's the value of the 'mba'
technology?

There are many other real-world problems with this - roaming senders,
centralized DNS database vs. decentralized outgoing MTA's, etc.

A system that relies to any extent on the DNS system should take into
account that authoritative slave name-servers cannot perform periodic, but
not necessarily frequent zone-transfers. Thus, there are propagation delays
between the DNS servers of any domain. The DNS system was not designed for
publishing real-time-like information.

Radu.

> If MBA works as intended, 
>spammers won't use

---

From: "Ricardo Dirani" <[email-masked]>
Date: Mon, 29 Mar 2004 15:59:50 -0300

Everton Marques tends to avoid cryptografy in his work due to the CPU cost.
MBA moves that cost towards RAM. But after reading your mail he became a
sudden enthusiast of DomainKeys and apparently dropped MBA. His only lasting
concern about DomainKeys is wether it is patent encumbered.

Ricardo

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 31 Mar 2004 00:34:28 -0500 (EST)

Matthew Elvey <[email-masked]> wrote:
> On 3/27/2004 4:09 AM, [email-masked] sent forth electrons to 
> convey:
>

> Interesting idea with probably fatal flaws.
> Maintaining a dynamic database is much harder than a static one, but 
> that's a minor issue.
> SPF allows mail to be authorized from servers that the domain in 
> question doesn't trust to do anything more than not spam.
> This proposal would require they be able to alter the database on the 
> DNS server!  Tricky.

That could be avoided via indirection; that is, if bobsite.tld is set
to trust panix.com, it could set an indirect record that says in
effect "Also look for _mba.bobsite.tld._indirectmba.panix.com".

However, that does break forwarding: the typical forwarding case is
one unpriveleged user at ISP1 has a mail account at ISP2 that he sets
to forward.  It is clearly not the case that everybody who sends mail
to him at ISP2 is willing to trust ISP2.  Nor is it necessarily the
case that even ISP1 is willing to trust ISP2, except for that one
user.

I don't see any way to handle that case with _mba.

Seth

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 30 Mar 2004 20:30:47 -0800

Interesting idea with probably fatal flaws.
Maintaining a dynamic database is much harder than a static one, but 
that's a minor issue.
SPF allows mail to be authorized from servers that the domain in 
question doesn't trust to do anything more than not spam.
This proposal would require they be able to alter the database on the 
DNS server!  Tricky.
E.g. I could set my SPF record to allow mail.panix.com to send email as 
elvey.com.  But then panix.com has to be willing and able to alter the 
elvey.com dns servers, and they have to be willing and able to allow 
it.  And I don't control either set of servers enough to make 'em do that.
Seems to me more effort than SRS/VERP, with approximately the same result.
All a domain's DNS servers have to be constantly syncing.  How would 
that happen?