John Leslie wrote:
Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
IMHO, I think that we should focus on RFC2821 HELO and in-addr.arpa
first since they seem to break the least amount of things.
That's a funny reason -- sounds a lot like the drunk searching for
his keys next to the street-light because "the light's so much better
here!".
We should be working to fix the most things. One can always break
the least things -- by doing nothing.
I agree that we should break things to fix them BUT the benefit should
be worth the cost. That's all.
What would greatly help which is what I think the chairs asked for is a
list of specific things that might break. I list some below.
Also, if HELO arguments are domains then it is possible to apply
reputation and accreditation services based on domain names.
I'd be delighted to talk about those -- but I really believe it
will be ruled out-of-scope.
(OTOH, perhaps the chairs won't actually rule anything out of scope
until the IESG acts on our charter. If you want to chance it, I'm game.)
I just went over the charter, this is way out of scope and is probably
something better for the ASRG to handle. So I will be mum on this.
Simply reducing bounces from joe jobs does not seem a good enough
reason for me to break the store and forward functionality of email
and forbid many legit uses.
At some point, we need to outline and discuss all these "legit
uses" which will supposedly break. The majority of us (IMHO) don't
believe there are very many of them which aren't _already_ broken.
I think that would be highly useful. For HELO checking I can't think of
a case where the HELO argument shouldn't be a FQDN unless the MTA does
not have a FQDN (which probably makes it a violation of some RFC
somewhere for an IP not to have it?). For MAIL FROM checking, off the
top of my hand I can think of forwarders, mailing lists, greeting card
sites, newspaper sites (send article to "friend"), etc. For in-addr.arpa
there are users who might be knowledgable enough to securely run their
own MTA but then again we will get into arguments over the types of ISP
services that are provided (a recent draft comes to mind). For RFC2822
checking, there are the same cases as above, plus a wide variety of
other cases such as myself where I relay my business email through
whatever MTA is accessible to me (using SMTP AUTH).
The main problem here is how to tell whether an MTA should be
trusted.
"Authorized" is an entirely different concept from "trusted".
(Among other things, they're at different ends of the transaction.)
Because something is "authorized" by the "sending" domain doesn't
mean the "receiving" domain will trust it. (That's where reputation
services come in.)
And "trusted" does no good if errors can't be reported to
someone capable of fixing problems.
I realized my mistake already after re-reading the charter :) We want to
know whether an MTA ia authorized to relay email. While that might imply
that you should trust it more than a non-MARID MTA, that question is for
the receiver to decide which would make the trust question out of scope.
HELO or in-addr.arpa checking combined with reputation/accreditation
systems should be sufficient for that.
In case you missed it, the majority of spam now comes with forged
RFC2822 From headers. Many perfectly "trustworthy" MTAs copy this
into the RFC2821 MAIL-From. The ones _I_ consider "trustworthy"
would do something about the problem if they learned a machine
they trust (yes, they legitimately "trust" machines which may later
be compromised) is spamming. But misdirected error messages greatly
reduce the chances they'll learn about the problem promptly.
The greatest benefit MAIL FROM verification can bring is the assurance
that the MAIL FROM argument is really valid which encourage people to
send DSNs instead of eating email silently. So I agree with you on this
one. The entire trust issue is more for the ASRG than here.
I don't want to minimize the difficulty of solving very much of
the spam problem with DNS information about RFC2822 From headers.
But it can have excellent results for a large class of users that
are happy to send everything through the same (few) MTAs; and that
includes many of the most serious problems. (It might even stop
the continual storm of "latest Microsoft update" viruses!)
We would have to tread carefully with transition.
Yakov