Re: Scope, and a preliminary list of issues

Richard Rognlie <[email protected]> Thu, 2 Oct 2003 20:31:01 -0400
Newsgroups gmane.ietf.asrg.rmx
Message-ID <[email protected]>
Here's the DRIP response to the list of questions...

On Thu, Oct 02, 2003 at 10:57:40AM -0400, Alan DeKok wrote:
> 
>   I've narrowed down the issues we should address to a sub-set of
> those in the documents I referenced yesterday, in order to simplify
> the discussion a little.  I believe that we have the following
> preliminary sub-issues:
> 
> 	I.1. Proposed design for addressing issues related to EHLO

Yes.  HELO/EHLO specific.  In fact, it REQUIRES that a server 
get a HELO/EHLO before proceeding.

> 	I.2. Proposed design for addressing issues related to MAIL FROM

n/a

> 	II.1. Do (or should) the designs require DNS protocol changes

None.   Just additional DNS A/AAAA records.

> 	II.2. What entities in the network have to implement these proposals

each server that wishes to relay mail out needs to have DRIP 
records created for the name/IP it offers on the outbound HELO/EHLO.

> 	II.3. Do we have existing implementations of proposals
> 	      (MTA, MUA, etc)

Yes.   There is a DRIP milter that plugs into sendmail.

> 	III.1. What is the cost of deploying the proposals
> 	       (time, effort, $$)

1-2 DRIP DNS records per IP/EHLO name.  The biggest cost will be
for large sites having to tweak their DNS provisioning systems for
when they add a new MTA to their mix.

> 	III.2. What is the impact of the proposals on mailing lists
> 	       i.e. Does the behaviour of sender or receiver change?

No impact.

> 	III.3. What is the impact of the proposals on roaming users
> 	       i.e. Does the behaviour of sender or receiver change?

No impact.  DRIP will not reject a connection that is SMTP AUTHed.
so even if you're roaming at a site/IP that violates DRIP, you're ok.

> 	IV.1. What part of the spam problem do these proposals address

It attempts to address the spread of malware that hijacks an IP
and start spewing mail outbound to random MX hosts. 

> 	IV.2. How can spammers work around these proposals

They would have to define a well known hostname in their virus spreading
"MTA", and then in DNS add the DRIP record for each IP their infest.
Wildcard DNS records will NOT work with DRIP.  It requires specific
A records.

Alternatively, they could attempt to determine the local outbound MTA
for their target.  And one might expect the local IP blocks to be 
exempt from DRIP checking.

> 	IV.3. What is the cost to spammers of working around these
> 	      proposals

LOTS of DNS records.

> 	IV.4. How much of an impact do these proposals have on spam

Not so much on spam.  More on malware.  However, added features of the
DRIP milter (which need to be made *options* vs. hard coded) are:
    force FQDN on the EHLO/HELO (per RFC 2821)... this catches many
    of the spamming MTAs.   

    force an offered IP to match the connecting IP (technically, a
    violation of RFC2821)... many spammers offer "HELO 66.92.144.25" when
    connecting to my personal MTA (ip 66.92.144.25).  They have no "right"
    to use that IP.  so I block them.  Further, I contend that if you do
    not know the IP by which you will be connecting outbound, you should
    NOT be connecting to non-LOCAL MTAs.  I'd expect you to use your
    LOCAL/ISP's MTA.

> 	IV.5. Does the cost the implementing the proposals justify
> 	      the effort?

Even with only a handful (count 'em 4... maybe 5) of domains implementing
DRIP records, I've seen my spam volume go down since implementing the
DRIP milter.

Since 9/13, I've received 62033 connections.   it's blocked 1704 msgs. 
Imagine if some of the bigger ISPs were to implement DRIP records


>   I will put these issues on a web page, and update them as we go
> along, with what we have decided.  That text can then be used as a
> basis for an Internet-Draft.
> 
>   For now, I would like to have the author of each proposal to post a
> 1-2 sentence response to each of these issues.  We can then construct
> a "meta-proposal", which contains the overlap of the proposals.  We
> can address any overlap or duplication by comparing the benefits and
> drawbacks of each proposal.
> 
>   I expect to do much of the work of collating and editing the
> documents, but I also expect that the proposal authors will do much of
> the work of writing the base text which is used to flesh out the final
> I-D.
> 
>   Alan DeKok.
> _______________________________________________
> asrg-rmx mailing list
> [email protected]
> http://mailman.ntp.org/mailman/listinfo/asrg-rmx

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email protected]>
 /  \__/ | It is dangerous to be right, when the government is wrong.
 \__/    |                                              -- Voltaire