ietf-asrg
[Top] [All Lists]

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

2003-04-27 06:46:17
From: Scott Nelson <scott(_at_)spamwolf(_dot_)com>

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

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.

 ..........................


} From: jm(_at_)jmason(_dot_)org (Justin Mason)

} Do you really think hotmail.com aren't sick of spammers pretending
} to send mail from their domain, and their domain thereby becoming
} equivalent in many people's minds to spam?

We're supposed to be doing engineering or research.  That should mean
that we rely on evidence, measurements, and logic instead of rumor,
wild guesses, and lies or illogical wishful thinking.

What evidence is there that much spam carries forged free provider
addresses?  It's likely that some does, but which of 0.01%, 0.1%, 1%,
10%, and 100% is the most accurate estimate?

If people (or their spam filters) assume that mail from free providers
is spam (as some do), then why are spammers forging free provider
domains?  It is just as difficult for a spam target to determine
whether user(_at_)hp(_dot_)com is valid as user(_at_)hotmail(_dot_)com, but the 
latter is
far more likely to be rejected by spam filters.

What evidence is there that free providers care?  When was the last time
that Hotmail launched lawyers at a spammer for forging Hotmail addresses?

When was the last time that a free provider said anything about forgery
of its domain name without lying?  All of the statements on the subject
I've seen from Hotmail have been obviously intentionally misleading.

My first wild guess is that more than 0.1% but less than 10% of the
spam carrying free provider return addresses can honestly be called
"forged." That guess is based in part on how much mail I see with
other addresses that are clearly forged.  My second wild guess is that
Hotmail and other free providers care about those forgeries, but no
more than to lie and try to cause people to think that true value is
close to 100%.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg