Subject: [Asrg] Per domain blacklists

From: David Walker <[email-masked]>
Date: Mon, 17 Mar 2003 17:53:59 -0600

My scheme for improving smtp and reducing abusive spams that contain fake 
headers basically amounts to a per domain blacklist implemented in DNS.

The mail server receiving the message will contact the DNS server of the "MAIL 
FROM" domain with a lookup of (reversed IP address).example.com
The DNS server will respond with OK or DENIED or nothing based on it's 
configuration.  Specific entries allow an IP or set of IPs and a wildcard 
entry disallows the rest of the internet.

OK means "Yes, send the message"
DENIED means "No, that IP address is not authorized to send mail from my 
domain"
nothing means "timeout or admin has not configured their dns to support this 
so send the message"

This method is completely backwards compatible,
useful when as little as 2 admins configure support,
capable of stopping klez type messages.

I have a further writeup at 
http://www.vorteon.com/papers/spam_reduction_through_dns.html
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 17 Mar 2003 23:25:31 -0600

> headers basically amounts to a per domain blacklist implemented in DNS.

Variations of these two solutions have been discussed extensively on
this mailing list.

See:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00001.html
RMX records
(Yes, this was the very first message to this mailing list)

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00048.html
domain specific DNS blacklists (or whitelists)

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00686.html
pros and cons of RMX (Re: [Asrg] Declaration to the world)

Summary:

1) DNS currently has certain security flaws that allow people to spoof
   it and therefore let spammers get around these systems.

   IMHO, this is more of a theoretical concern that a practical one.
   Spammers haven't used these security flaws to spoof other DNSBLs,
   and that would be a much bigger payoff for them.

2) Many people, especially those that travel a lot, like to be able to
   "forge" email headers and such so that they can send email from
   anywhere and make it look like it is coming from their home system.

   IMHO, there are better solutions to this kind of problem, such as
   SMTP AUTH or SMTP TLS, but there are a lot of people out there that
   are "forging" email for legitimate reasons.

3) Checking the SMTP HELO and MAIL FROM domain information is only
   mildly useful.  End users generally don't see this envelope
   information, and spammers can simply switch to RFC "MUST" deliver
   domains such as the local host or <>.

4) Checking the mail from: header would break a lot of things like
   mailing lists.

I think that per domain blacklists can be very easily implemented, as
I demonstrated in the third post I mentioned above.  I am not,
however, convince that it would hinder spammers more than it would
hinder legitimate email users.

-wayne

---

From: David Walker <[email-masked]>
Date: Tue, 18 Mar 2003 01:08:30 -0600

Thanks for catching me up.  I am new to the list.  Hopefully I don't retread 
too much.  Parts of this are re-hash.  The ideas I think are "new" are in 
points 3 and 4.

1.  As you mentioned, more of a theoretical concern.  This isn't a security 
system per se.

2.  DNS blacklists only prevent forging from domains that have it configured, 
so those that "legitimately" forge email headers may continue to do so as 
long as their domain's administrator allows it either by not configuring DNS 
or by whitelisting *.  At its worst, whitelisting the entire internet is the 
same as what we have today.  At its best, whitelisting only those servers 
that send mail from your domain, it is a significant improvement.

Travelers should use other solutions such as reply-to headers, VPN 
connections, SMTP after POP or SMTP authentication with their home servers.

Although I do feel that allowing just anyone to forge headers because it is 
convenient is very bad form.  

3.  Mail users should be seeing this information.  Some already do see it via 
the "on behalf of" message and "SENDER" or "X-SENDER" headers.  In my mail 
server I have exposed the envelope from and envelope to addresses and found 
it quite useful in rulemaking and the like.

In my mail server I add special warnings to messages sent with "must deliver" 
rules.  It wouldn't stop the message from being delivered but it would make 
it more difficult to use SMTP frailties to impersonate users or the various 
kinds of fraud as seen in spam messages.

4.  The check on the "from" header should be optional and/or non-fatal and and 
a "from" header that differs from the "mail from" envelope sender should be 
noted and visible to the user.

I believe that with my additions that no user would see reduced functionality 
except for those that want to send messages with a return address of a domain 
they are not in charge of.  

My biggest concerns are with the rampant fraudulent headers that are out 
there.  If a company is mailing from their own domain name at least they are 
taking a minimum amount of responsibility and if you don't like it you can 
block mail from their domain.

On Monday 17 March 2003 11:25 pm, wayne wrote:
> https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00001.htm
>l RMX records
> https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00048.htm
>l domain specific DNS blacklists (or whitelists)
>
> https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00686.htm
>l pros and cons of RMX (Re: [Asrg] Declaration to the world)
>
>
> Summary:
>

---

From: [email-masked]
Date: Tue, 18 Mar 2003 02:41:55 -0500

> noted and visible to the user.

Note well - this "check" will trip for *EVERY SINGLE* posting from a properly
configured mailing list (as the From: will be either the list or the person
who posted to the list, but 'mail from' will point at the bounce-collection
address like it's supposed to)

For that matter, this message left my laptop with mismatched From:
and MAIL FROM.

---

From: wayne <[email-masked]>
Date: 18 Mar 2003 06:58:37 -0600

In <[email-masked]> [email-masked] writes:

> > 4.  The check on the "from" header should be optional and/or non-fatal and
> 
> configured mailing list

Right.  my point 4) was about the problems with mailing lists.  As
David said, this checking should be optional and/or non-fatal.  If you
are going to use this kind of system, it is very important to identify
mailing lists and deal with them correctly.

-wayne

---

From: David Walker <[email-masked]>
Date: Tue, 18 Mar 2003 09:39:48 -0600

In my way of thinking we shouldn't be checking the from header using the 
blacklist records.  We should be checking the envelop from and making sure 
that the client displays "'envelope from' on behalf of 'from'" to their 
users. (I think this is already the behavior of Outlook.)

That makes it hard to exploit the system for silent forging but easy to use 
with mailing lists. 

On Tuesday 18 March 2003 01:41 am, [email-masked] wrote:
> > 4.  The check on the "from" header should be optional and/or non-fatal
> > and an
>
> d
>
> > a "from" header that differs from the "mail from" envelope sender should
> > be noted and visible to the user.
>
> Note well - this "check" will trip for *EVERY SINGLE* posting from a
> properly configured mailing list (as the From: will be either the list or
> the person who posted to the list, but 'mail from' will point at the
> bounce-collection address like it's supposed to)
>