"Matthew Elvey" <matthew(_at_)elvey(_dot_)com> wrote:
On 9/14/2004 4:53 PM, Douglas Otis sent forth electrons to convey:
On Tue, 2004-09-14 at 14:14, Matthew Elvey wrote:
=-=-=-=-=
On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:
<Matthew Elvey said:>
Phrased differently:
....<why HELO>
This is a VERY interesting approach. [...]
This sounds really cool. But I am an engineer and must always ask, what
is wrong with this and why has it not been thought of before?
It has been considered and there is language within CSV that
accommodates this approach. : )
Right, it's not new. It just doesn't have Marketing Might behind it.
Of course now it has an encouraging nod from AOL...unofficially, of
course :)
Lets see, forwarding cases....might work here with some PRA/Submitter
type changes. Not a huge problem.
With the marid-mpr draft, there is no need to assert the list as
comprehensive (closed) as it is not used to identify the MTA in any
manner. As such, the typical implementation could treat this list as
nominal to "color" the mail at the MUA and not force rejection of possible
spoofing. There would be no forwarding issues in that case.
<snip>
I don't care whether a mail server is who he says he is, I care
whether he's authorized to send the message he's trying to send.
May I add that the marid-mpr draft can safely answer this question
within a single DNS query and not require the potentially hundreds
needed by Sender-ID or SPF.
Cool, though to be fair: what's the upper limit on the number of DNS
queries marid-mpr might require, assuming a malicious sender attempting
a DoS?
Unlike the 20 limit recursion in SPF or the 10 script records in Sender-ID
that may then require hundreds of DNS queries to assemble these record
sets, MPR would require one or two queries for a PTR list of EHLO domain
names using the label _mp.smtp.mailbox.dom and a single A record query
using the same _mp.smtp.mailbox.dom label. (None of this is using reverse
DNS.) When the MAIL FROM and the From are the same, just a single list
would be needed. With CSV done first, MPR queries are optional and will
not negatively effect someone's reputation as a result of these MPR check
not being made. Reputation would always be done using CSV and mail
"coloring" could be done with MPR.
<snip>
Andrew Newton wrote:
On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote:
A HELO scope would be useful.
That is already being covered by the CSV proposals.
No, not even close. -protocol with CSV, and -protocol with a HELO scope
would be EXTREMELY different, can't believe you don't see this, Andy!
Please consider the need for two steps in this process. One,
authenticate and validate the authorization of the MTA EHLO name. Two,
obtain a list of authorized EHLO names referenced by the mailbox domain
being examined. This list can be either nominal or comprehensive
without the nominal case inviting spoofing. In which case, CSV remains
"as-is". MPR records are much simpler and easier to maintain and obtain
than scripts for SPF or Sender-ID.
Confusing paragraph, that.
Currently both Sender-ID and SPF attempt to combine identifying the MTA
and authorizing the sending of the mailbox domain message. An exploit
these collapsed functions (bogus) authentication with mailbox-domain
authorization create is when the authorization list is "open" (nominal
authorized MTAs, as with ... ?all), this allows others to usurp the
reputation of the mailbox domain by obtaining the bogus authentication.
Closed records could be called "comprehensive" as they encompass the
entire set. In the case of SPF or Sender-ID, closed records are an effort
to "idiot proof" the mail but then creates problems with forwarding. With
MPR, these functions are separate and do not allow the exploit. By
"coloring" the message when outside the nominal mail channel and making
the authenticated EHLO visible, there should be little need to close the
list except for those domains that are typical targets of spoofing. I
should note that marid-mpr allows for better "idiot proofing."
I would suggest avoiding sequential TXT scripts needed with either SPF
or Sender-ID as being unworkable. CSV used in combination with MPR and
BATV provides all the features claimed by either SPF, SRS or Sender-ID
without disrupting email to the same extent.
There is another issue with either SPF or Sender-ID records. CSV and
MPR are named based solutions that work within the natural scale of DNS
and only require single non-sequential lookups. SPF or Sender-ID
require either extensive iterative references to record names to obtain
addresses, or the repeating of IP addresses in a script form. The
maintenance of such a list will be high, or the relative overhead to use
such a list will be high or both.
Very efficient.
...
In addition to/as part of the security review of SenderID:
I think it's necessary that a number of MAYs and SHOULD [NOT]s turn
into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling -
MUST [NOTs] MUST be used whereever there isn't a compelling reason not
to. IETF standards demand it.
With respect to SPF or Sender-ID, there are optional modes that everyone
seems to think are foolish to use, but are still in the draft such as
+all.
Folks agree/disagree with that? (Applies only to SPF and SenderID.)
Also, the way that Accredidation and Reputation services are to be used
is essential. It belongs in a BCP, which should specify BFP (Best
Future Practice) for how various tests should be interpreted and acted
upon. SPF claims to address the spam problem (according to text that
was on the spf.pobox.com home page) so the Accredidation and Reputation
services that are a necessary component to this solution must be
specified. An incomplete spec that lacks these things has no business
aspiring to be an Internet Standard. How can a spec that is grossly
incomplete be properly reviewed by us or the IESG? It can't!
Folks agree/disagree that MARID specs should cover how they will work
with A&R services?
(IMO blacklists and whitelists ARE A&R services.) The result codes
from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more
than a binary result - some BLs provide bitmapped result codes.
Doug: What do you think?
I think there is more to this than describing how things may work, but
also must consider how these services will be effective at correcting
problems. To move to a name based reputation or blacklisting, the name
must be authenticated first-hand and not make assumptions about the mail
channel integrity. In my view, this rules out MAIL FROM and any RFC2822
headers to be used for reputation purposes.
I think much more needs to be provided in the reputation results with a
minimum of time in existence and a complaint count that zeros when the
domain administrator acknowledges the events. There can be flags that
indicate opt-in only policy agreements, black-listed, unusual traffic
change, size of domain, etc. I think there needs to be a move away from
relative rating schemes.
You will find that the marid-mpr draft does allow the protection of the
From and the MAIL FROM and is a good alternative to the PRA approach.
Indeed. I have. It's hell slogging through the acronyms though - MCAL,
MCNL, etc. I'll have to read it again in order to be clear on what goes
where - A vs PTR vs APL...
It is a bit curt, but was intended just to illustrate how it could be
done. I had more text, but I trimmed some of the narrative. I think
feedback will help point out areas that need clarification.
Just read BATV - glad to see it! Perhaps it could pursue a standards
track - the 'Public Tagging' component means interoperability is
important so it should pursue standardization.
Yes, I agree. Much better than the SRS concept in my view.
-Doug