Re: [Asrg] Re: draft-danisch-dns-rr-smtp-01.txt

[Scott Nelson <scott@spamwolf.com>]

At 01:53 PM 4/27/03 -0600, Vernon Schryver wrote:
>> From: Scott Nelson <scott@spamwolf.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@example.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@spamwolf.com>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg