This is a belated-due-to-to-travel follow-up to replies to this post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html
(Summary: Sender ID fails to be a solution that only requires sysadmin
action; it mandates end-user reconfiguration on a massive scale, because
it doesn't say that HELO checking should/must be done... The Microsoft
IPR are too encumbered...)
The issues I raised in my last post were appropriate during a last
call: They were raised earlier, and there were strong indications that
they would be addressed (e.g. the Unified SPF discussion and
documents). Yet they were in fact not addressed by the specs that were
in last call.
"=-=-=-=" <-- topic separator
I think John Leslie said that under SenderID, a domain's reputation
would be looked up by looking up the IPs its SPF2 record lists in an IP
blacklist.
I think John is confused - that's not what I am expecting. I'm
expecting the domain itself to be looked up in a RHSBL. That's Right
Hand Side Block List. (John's idea could prove useful, but I'd be
surprised if it, e.g., scored well if coded as a SpamAssassin rule and
evaluated)
=-=-=-=-=
On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:
<Matthew Elvey said:>
Phrased differently:
Sender ID fails to be a solution that only requires sysadmin action; it
mandates end-user reconfiguration on a massive scale, because, IIRC, it
doesn't say that HELO checking should/must be done. Hence I (of
elvey.com) would have to get all my domain's end users to use MSAs that
I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email
provider, who hosts mail for thousands of domains, they would have to
support this for each user of each domain!) If HELO checking is
mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm
has a good reputation.
This is a VERY interesting approach. I think you are saying, scratch using
DNS for "listing Domains allowed to be sent by an IP address", and instead
have the system admin "program" those domains into the MTAs (e.g. a config
in sendmail). The MTA would HELO the domain they are about to send for, IF
THE MTA is told they are allowed to send for that domain in the first
place
- otherwise the mail is rejected (and likely much closer to the submission
MTA/MSA).
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?
Lets see, forwarding cases....might work here with some PRA/Submitter type
changes. Not a huge problem.
Forwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The
MTA would HELO the domain they are about to send for.' This domain
wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would
simply need to be a domain that had an appropriate reputation for the
content. E.g. if we assume AOL is responsible about ensuring very
little spam is sent using the servers it authorizes to do HELO aol.com,
and sends all email through these servers, then there is no forwarding
to worry about. Helo aol.dom would trigger a reputation check on aol.dom
as used in HELO, the repuation would be excellent, and no further checks
would be necessary - the From: domain or PRA could be elvey.dom or
DomainWithNoSPFrecord.dom.
Here's a sophisticated possible scenario that provides more flexibility:
AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one,
and the customer hasn't recently sent a ton of email. It might use HELO
aolSuspectCustomer.dom where appropriate, before cutting the customer
off completely. AOL wouldn't have to pay to give
goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL
wouldn't have to cut off customers as often - it could limit use in a
less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom
would make sense, provided AOL provided and used dedicated IPs for such
mail and created the appropriate DNS records.
Just to clarify: the above is a sophisticated, enhanced solution that
HELO-based reputations make *possible*. It will be perfectly OK for an
MTA (or all of a domain's MTAs) to have one domain that goes in all
HELO/EHLO commands sent, and this is likely to be the usual case, and
will work well.
OK so what is wrong with this?
Well, no criticism so far, other than from Jim, which I've addressed
thoroughly.
-Carl
On 8/26/2004 11:12 AM, Jim Lyon accurately summarized and conveyed:
Matthew Elvey raises two points that I summarize as follows:
1. If you don't know what a domain's outward-facing MTAs are,
it's really hard to build a SenderID record. (And he estimates
that half of his customers are in this boat.)
True.
2. If instead of SenderID, we'd merely authenticated the HELO name,
and built up reputation systems that say whether particular
HELO names behave reasonably, these people's lives would be easier.
It's true, but it's a whole lot weaker form of authentication.
Please, I've already explained why it is stronger. If you're going to
say it's weaker after it's been explained WHY it's stronger, please
respond to the provided arguments. You need to do this or you drag the
conversation to the <Yes it is. No it isn't. Yes it IS...> level.
[edit: it looks like you've had the argument with Doug in this thread.]
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.
Can we please graduate to more advanced banter than this? The charter
says what we care about. (It's adequate, even if the main goal is to
address spam, including joe-jobs, phishing, etc.)
The first half of the sentence states that you don't care about the
server's Identity, and I know that you in fact do; SenderID relies on
Identity. I fail to find a logical argument for ignoring HELO. You
imply you care about the body of the message, but SenderID doesn't look
at the body. (Why are you calling a mail server a 'he'? It's confusing.)
Jim Lyon later also said:
Authorization: The SenderID test determines whether the sending MTA is
authorized to send mail that claims to come from a particular domain.
This is a too-short definition (which you later improved upon); it's
actually not accurate. A mail message can claim to be from several
domains.
Jim later clarified things:
The identity being authorized is the
sending MTA's IP address. The action being authorized is to send a
message on behalf of the PRA. The organization doing the authorization
is the domain of the PRA.
PRA, if adopted, will be manipulated by spammers by the insertion of
forged headers. (I'm working on an example.)
=-=-=-=-=-=-=
I understand that the last call was considered by the Chairs to be a
failure only because of the IPR issues.
There are other issues, I believe.
Some other points that inform whether SenderID was ready for RFC status:
I indicated that certain changes that appeared to be imminent would make
SenderID gain my support, but
it turned out that those changes were not made.
E.g. In June, I posted here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02404.html :
"I'm not trying to deep 6 SPF. I'm trying to make it stronger and
better by attacking its weaknesses virtually, while they are readily
fixable. Note, I recently expressed my support Unified SPF (which
incorporates a CSV-like check). BTW, I was surprised that the -01
SenderID drafts that came out didn't have any Unified SPF stuff in
'em. I interpreted something Meng said to mean that I should expect
to see it in a draft soon, so I'm still expecting that."
The cynic in me wonders if this was an effort to derail my plan to
create an I-D that remedied the weaknesses I saw. That was its effect.
-=-=-=-
I have a $50+ spf t-shirt. I'm trying to make MARID's work
successful. OTOH: A principal of my mail provider (fastmail.fm's
Jeremy H) is so unhappy with SPF that he's suggesting configurations
that appear designed to *sabotage* its effectivenness; an IESG
member's criticism is provided as justification:
http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf
A comment on the power of reputation: Remember, Unified SPF and its
cousins rely on reputation services. Such services already exist :
[DNS|RHS][W|B]LS, etc.
If an EHLO domain gets an initial pass, the reputation check could be a
lookup of that domain speficially with respect to its use in EHLO, such
as a DNS lookup of nonspammers.dom.ehlo.mail-abuse.org. However, I
suspect this may not be necessary, and a DNS lookup such as
nonspammers.dom.SPF.mail-abuse.org would suffice, and a reputation
service would only need maintain a single reputation per domain with
respect to is use with Unified SPF and cousins.
What do folks think? A reputation service would need maintain how many
reputations per domain with respect to is use with Unified SPF and
cousins?
An add'l reputation that may be useful would be at, say
nonspammers.dom.bounce.SPF.mail-abuse.org. This reputation might
reflect whether nonspammers.dom's mailservers were properly configured
to refuse mail at smtp time whenever possible, and thus not likely
sources of bogus bounces such as joe-jobs.
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!
It's certainly been explained many times, on-list, by many people. I
see strong confirmation that HELO scope would be useful, and an
appropriate change to make. I see little reasoned opposition to a A
HELO scope. Let's add it or hear some reasoned opposition.
-protocol with a HELO scope would have giant advantages over plain
-protocol or -protocol with CSV, which have been detailed on-list, e.g.
by me as reasons to make a HELO check mandatory, and as reasoning for
Unified SPF. Certainly it has some disadvantages as well, which have
also been detailed on-list. The only one that made sense to me was that
it would make it more likely for a domain not to specify a list to be
used for PRA or MAIL FROM verification. The disadvantage of that is
that such a domain would receive more joe-job bounces, though there's an
argument that there would be fewer as well: MARID requiring HELO is
easier to deploy effectively, therefore likely to be deployed faster.
Also this disadvantage applies to SenderID as well- it allows
joe-job-type bounces to joe-job victims. Only SPF+SRS doesn't have this
disadvantage, and only where the unwanted bounces would be coming from a
server that had implemented SPF.
Some reasons the market may go with the HELO scope instead of the others
(assuming this leave-it-to-the-market proposal flies) are that it has
the advantages of not using restricted IPR, doesn't break
forwarding/mail-list/backup mx operations, and doesn't require end-user
action to implement.
Also, Accuspam implicitly asked an interesting question - why specify
what the list of servers may be used for? Here's an answer: It's
generally much easier to specify a list of servers that will
legitimately use a domain (e.g. elvey.com) in HELO than it is to specify
a list of servers that will use that domain in PRA or 2821.MAIL FROM!
Hence some folks will only want to specify the former. Some folks may
want to specify a smaller set of servers for one versus another.
Accuspam said : "Publishing the approved mail servers is something
everybody can agree to do I think?" but this is more complicated than it
seems at first glance, because the set of approved servers for a given
domain is different depending on what its approved for.
As Meng said, if HELO and SUBMITTER (modified to not use the encumbered
IPR) always override MAIL-FROM, then there is no need for SRS.
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.
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!
E.g. John Leslie is quite confused about how A&R might work, or I am, as
mentioned above.
Regarding IPR:
I am certain that the Microsoft staff working in this area are smart
enough to be aware of how their license is defective and how it needs to
be fixed. They can all read. As time passes and they continue to fail to
fix it, blame for failure of the IETF to address the spam problem falls
gradually more squarely on Microsoft and its staff's shoulders. (They
got involved in the process, worked patent pending ideas they have
claims on into drafts amid promises of licensing that wouldn't be
problematic, Microsoft threw its weight around, and now the licensing is
not satisfactory.) As they've had ample time to do so and haven't done
so, we need to move on without PRA.
=-=-=-=-=
Subj:Re: problems with patents: the IDN example from RFC3669
wayne wrote:
>... the people running this working group.
>
As I understand it: The members of the working group run the working
group. The chairs have limited authority. They mostly express their
opinion as to what the rules are, and what consensus has been reached,
and help provide needed infrastructure. Their opinions are not binding,
AFAIK.
For example, they've expressed an (IMO chilling, incorrect and
inappropriate) opinion that certain comments regarding Microsoft and its
interests were inappropriate. I explained in my last post why some
(not necessarily all, of course) of such comments ARE appropriate in
this forum, with reference to IETF policy describing what is and is not
appropriate.
They don't get to decide. (They get to invoke BCP 83 mechanisms, and
the IESG can express binding opinions.)
WRT to the importance of the highly divisive IPR issues, their opinion
doesn't hold much more weight than anyone else's, IMO.
I believe they shoot themselves in the foot by making consensus claims
that aren't accurate, e.g claiming rough consensus has been reached on
something when in fact it hasn't. I sympathize however; they are trying
to meet deadlines and keep the peace. It's a tough job.
I'm sorry if the above is felt inflammatory. I talked to a couple folks
who felt it needed to be said, and is as toned down as I could make it.
=-=-=-=-
Clarification:
On 8/25/2004 1:55 AM, Stephane Bortzmeyer sent forth electrons to convey:
On Tue, Aug 24, 2004 at 08:05:52PM -0700,
Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote
a message of 80 lines which said:
1)A good fraction (I'd estimate 1/2) of my end users have their MTAs
configured to send through several SMTP servers, using different
From:'s
> You mean "their MUAs", not "their MTAs"? Because, although I know MUA
with source routing (Thunderbird), I do not know how to do it
properly with typical Unix MTAs.
Yes.
=-=-=-=-=
Sorry these comments weren't more timely.
So, who's for a new draft with two scopes: HELO and MAIL-FROM?
(Wait, how about a third scope: From:? This would be something
phishedbank.dom might want to use to indicate that it would rather break
forwarding than allow its domain to be used in From: without its
authorization. Do folks think phishedbanks would actually use such a
scope? (I'm reopening a closed can of worms; perhaps given the failed
last call, it's time to do so.))