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

From: Scott Nelson <[email-masked]>
Date: Sun, 27 Apr 2003 09:39:44 -0700

At 07:40 AM 4/27/03 -0600, Vernon Schryver wrote:
>> From: Scott Nelson <[email-masked]>
>
>> >> ...
>> >> Recognize that the goal for the receiver isn't to find all the 
>> >> valid IP's for a domain, but rather just the one they are receiving
>> >> email from.  To answer the question "is IP a.b.c.d an authorized 
>> >> IP for example.com?", the receiver could check 
>> >> d.c.b.a.rmx.example.com.
>
>> >The problem with that is that Hotmail, Yahoo, and most of the rest of
>> >the owners of the domain names that appear in SMTP Mail_From senders
>> >in the majority of spam instruct their DNS servers to always answer
>> >"yes, a.b.c.d authorized" for any and all IP addresses.
>
>> Just to clarify, that's a problem with idea of authorized senders,
>> not the suggestion that IF you attempt to authorize IPs, then you
>> should do it on a single IP rather than the trying to get the whole range.
>
>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.

>> The way SMTP works currently, authorized sender lists are
>> only useful to identify email that is very likely to be from the
>> domain in question, and not useful in identifying email that is not.  
>> In other words, one should use it only to accept an email, 
>> not to reject it.  (Or make it more likely to be accepted).
>
>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.

>> I think the value of being able to whitelist an email is not as 
>> great as the problem of people who incorrectly chose to 
>> reject email for failure, but I'm neither sure nor certain.
>> Perhaps if it was limited to system messages, 
>> or certain privileged accounts like postmaster or mailer_daemon 
>> then it might have greater value.
>
>That would be an interesting idea, except that the address of that
>sort that is most commonly forged in spam lacks a domain to check or
>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.
That's one of the purposes of this group isn't? -
 To suggest changes to SMTP that would make it more resistant to spam?

Scott Nelson <[email-masked]>
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 27 Apr 2003 12:45:04 -0500

>  To suggest changes to SMTP that would make it more resistant to spam?

Go back and read the archives of the thread "ban the bounce" (or some
similiar title).

-wayne

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 27 Apr 2003 13:53:14 -0600 (MDT)

> 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.

> PTR RR for the SMTP client?

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%.

> 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 "<[email-masked]>".  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.

>  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.  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.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg