On Tue, 14 Sep 2004, Meng Weng Wong wrote:
The unhappiness there seems to be with SPF Classic, and is
remedied by Unified. I would like to take this opportunity
to expand on some ideas for the working group's consideration.
Instead of commenting directly on particular parts of Meng's post, I'm
going to forward my post to MARID list way back from March 2004.
My position has not changed - if we deploy one type of SMTP identity
verification, we should probably deploy another one along with it and
they both work better filing each other weeknesses. And still think that
just one identity being is not enough to override negative from another, I
believe that at least two identties must give postitive authentication
results to override a negative (if I were to assign values to spf
modifiers,it would be "-" = -2, "~" = -1, "?" = 0 and "+" = 1) and I do
not believe that setting up PTR is such a problem as some believe (AOL
requires all mail servers that connect to theirs have it for example).
Now here goes my old post which is still quite relevent today:
--------------------------------------------------------------
Date: Sun, 28 Mar 2004 20:33:17 -0800 (PST)
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
To: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Cc: IETF MXCOMP <ietf-mxcomp(_at_)imc(_dot_)org>
Subject: Re: Different identities for different problems?
On Sun, 28 Mar 2004, Yakov Shafranovich wrote:
The goal of attacking hijacked machines is stated in the introduction of
the DRIP proposal.
Bad idea - there is nothing that stops spammer from using domain with no
dns record and it really does not help situation with zombies. All DRIP
does is possibly help a little with forgeries seen in the end usually in
the received header which help with tracking and that is all (but usually
tracking is done by ip anyway).
What does help is the record in reverse DNS (as in MTAMARK) indicating
that no emails should be sent from this dial or dsl or corporate net
and this MUST be done by ISP and not anybody else - they are the ones who
control the ip block and know what is supposed to be there or not, however
it needs to be more complex then MTAMARK as handle redirection and
inclusion of user data properly (i.e. SPF or similar). There are also some
issues with RFC2317 (which is in my opinion just a bad RFC that instead
of proposing to do futher reverse subdelegation with NS, tried to get by
with CNAMEs - bad, that means it will only work for PTR records and not
anything else that might be in in-addr).
But DRIP and/or RMX can be combined together with MTAMARK helping each
other out. If ISP is not willing to (or what is more likely that its slow
to act and) properly whitelist the IP of client machine then DRIP or RMX
can come in and user can setup his email server to specifically whitelist
this one ip (and only one or two but singular ips not ip range as not to
give a hole for spammers to setup domains that whitelist entire world).
Same true going back to RMX where airport kiosks annd forwarding server
and similar (these are the biggest problems with RMX as far as who will
suffer), their reverse ip can possily be whitelisted and then this will
indicate that the mail server at that ip will send emails with RMX not
matching 821 Mail-From (or 822 Mail-From if people on this list think that
is better).
My thinking is that all of these DRIP, RMX, MTA-MARK should be done
together if people are willing to do even just one of them. Each one can
serve its own purpose and at the same time when records are whitelisted
by two of these and blacklisted by the last one, then the policy should
be to let email through allowing to deal with either possible errors in
setup or delibebetly when its appropriate in the situation. If people
think it opens the hole for spammers, I can explain that in reality the
hole is minor one and when using these holes spammers will expose themselve
quite a bit (for example spammer that wants to whitelist his zombie proxy
will have to setup domain with RMX and DRIP records for each proxy; this
will allow to track proxy to specific spammer and also provides record of
intent for law enforcement).
If people are interested I'll write details on this, but I dont want to
bother if there is not some initial support for it and if everyone just
continues to argue and push their favorite proposal focusing on one single
element (except SPF which at least tries to do things in more combined
way focusing how to best accomodate different client implementations).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net