At 01:53 PM 4/27/03 -0600, Vernon Schryver wrote:
From: Scott Nelson <scott(_at_)spamwolf(_dot_)com>
...
I don't understand that.
The paper (draft-danisch-dns-rr-smtp-01.txt) advocates a method for
doing authentication of IP address as valid senders for domains.
My post suggested an improvement (IMO) to the method of
doing authentication of IP address as valid senders for domains.
I was simply trying to make it clear that your complaint applies to
/all/ methods of authentication of IP address as valid senders for
domains, and not just the particular method I suggested.
Oh. Yes, my point applies to all implementations of special notion
of what I you mean by validating senders. It does not apply to other
tactics. For example, simply white- or blacklisting by IP address or
domain name differs. The crux of the special notion is requiring a
relationship between the IP address of the SMTP client and the SMTP
envelope Mail_From value.
To identify mail that is very likely to be from the domain in question,
you do not need any new protocols, modifications to existing protocols,
or new conventions such as DNS RRs. You need only compare the PTR RR
for the SMTP client with the envelope sender domain. That comparision
won't be completely accurate, but it will be more accurate than any
new scheme.
PTR RR for the SMTP client?
Now I do not understand.
In most of the cases where this special notion makes sense or probably
ever will make sense, you can already compare the reverse DNS name of
the the IP address of the SMTP client (PTR RR) with the domain name
in the SMTP envelope Mail_From sender value. This special notion is
hopeless, wrong, and unwanted in the cases where it is most needed,
mail with free provider sender addresses. Comparing senders with PTR
RRs fails for some complicated or misconfigured installations other
than free providers, but works most of the time. It has long been in
use by people who can tolerate false positive rates above 1%.
Ok, you were talking about the PTR record for d.c.b.a.in-addr.arpa.
(A.K.A. rDNS)
Then, I disagree, they're not the same at all.
(Though I might consider both approaches equally worthless.)
In the rDNS case, one checks if d.c.b.a.in-addr.arpa. == mail_from domain.
In the other case, one checks if d.c.b.a.rmx.dns-query.example.com == yes/no.
The difference is, a.b.c.d decides what d.c.b.a.in-addr.arpa is,
where as example.com decides what d.c.b.a.rmx.dns-query.example.com is.
(My ISP is kind enough to let me set my own rDNS record even though
I only have a /28 but almost all ISPs allow it when you have a /24
or larger. I could trivially set the rDNS for 64.62.142.78 to aol.com
or anything else, and that's without any DNS spoofing.)
Also, lots of domains map to the same IP,
but there can be only one domain per rDNS.
(Well, actually there is a proposal for a way to have more than one,
but to the best of my knowledge there's little to no software support for it.)
But all these methods fail IMO, because any technique that connects an
IP to a domain has to make the assumption that email that originates
from a domain always arrives at a mail server from IPs associated with
that domain. This isn't even true now, (forwarding, mailing lists, etc.)
and I suspect that it's going to be even less true in the future.
Also as you pointed out, example.com has very little incentive
to restrict the IPs that it's allowed to send email from, and it's
likely that big ISPs would rather deal with spam forging their domain
name then disallow the practice of using somebody elses resources to
send email. Maybe not hotmail, but there's bound to be a lot of domains
that would do so.
Given that, one might say that my suggestion is like arguing for
a larger bailing bucket on the Titanic, but I'm really thinking
ahead to when we start boarding the life boats. If this thread
plays out the same way it has on the other discussion lists I read,
then that will be about 2-3 weeks from now.
compare (as well as a user name). Remember that bounces are supposed
to come from "<>". See section 6.1 of RFC 2821.
Maybe we should change that.
Why? What fraction of spam do you see comes from "<>"? I see very little.
It's not good to change protocols just to prove you can or because
one can't think of a reason why not.
Please consider reasons why "<>" might have been chosen instead of
something like "<mailer_daemon(_at_)example(_dot_)com>". One possibility that
occurs to me is that it a bounce must always have a valid address no
matter what the receiver thinks. If there is any room for the receiver
to think that the sender of a bounce is bogus, then there can be
double, triple, and infinite bounces. Given the need for a sender
address that is always valid (including should never be filtered), it
doesn't matter much whether it is "<>" or "<Mailer-daemon>" or anything
else, except that "<>" is shortest.
Hmm... right, changing "<>" accomplishes nothing.
Ok, that wasn't a good idea, sorry I mentioned it.
That's one of the purposes of this group isn't? -
To suggest changes to SMTP that would make it more resistant to spam?
I have the distinct impression that many contributors to this mailing
list see its purpose as making changes to SMTP desite nitpicking
considerations such as reducing spam.
Then say that. Don't get lazy and call me an ass for suggesting something
that's contrary to an RFC, call me an ass for being too lazy to explain
why my change would make things better (or even if it would).
If you feel you must mention an RFC, then say something like;
"RFC2821 suggests that for a reason, and you haven't supplied a better one."
I don't intend to attack you
or anyone else in particular. I'm weary of the continuing demands
(not just suggestions) that SMTP be changed or replaced based on
reasoning that is best described as "why not?" The many proposals to
authenticate or validate senders have this problem in spades. They
are advanced without any measurements of how much spam they might
prevent but only the intuition of their advocates that the changes
would surely be wonderful. Worse, the talk of validating senders,
challenging responses, and so forth seem to be instead of consideration
of the nominal work items of the mailing list.
The only nominal work items I'm aware of come from
http://www.irtf.org/charters/asrg.html -
Investigate what's needed to allow the communication of consent,
and what sort of architecture would allow that to be built as components.
Further down on the page though, it mentions
"ASRG will investigate the spam problem as a large-scale network problem.
The ASRG will begin its work by developing a taxonomy of the problem and
the proposed solutions. This taxonomy should involve casting the spam
problem into different perspectives, such as examining the similarities
between spam and denial-of-service; spam and intrusion detection/prevention;
and spam and authentication, authorization, and accounting."
Add emphasis here on the "proposed solutions" and "authentication," parts.
Seems to me what's really happening here is the same thing that
happens on most discussion lists;
People are asking the same questions, and making the same suggestions
as if they were something new that the group had never heard before.
There's a saying that I think is appropriate:
Frequently asked questions are asked frequently.
The real value of a FAQ isn't that people stop asking the dumb questions
(or making the same dumb suggestions) but that when they ask the
questions, you can quote the FAQ to them instead of wasting lots of the
group's time going over the same ground. Until the FAQ is ready,
I suggest working on some pat answers to those questions.
Scott Nelson <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg