Double Irony! (was Re: [linux-elitists] ruben's stupid filter)

Dan Wilder dan@ssc.com
Sun Mar 24 22:30:40 PST 2002


On Sun, Mar 24, 2002 at 10:19:08PM -0800, Karsten M. Self wrote:
> on Sun, Mar 24, 2002, Dan Wilder (dan@ssc.com) wrote:
> > On Sun, Mar 24, 2002 at 05:34:08PM -0800, Karsten M. Self wrote:
> > > on Sun, Mar 24, 2002, Dan Wilder (dan@ssc.com) wrote:
> > > 
> > > <...>
> > > 
> > > > Unfortunately the RFCs appear to prohibit validating the actual
> > > > sending host against DNS and then declining mail based on that
> > > > validation.  That'd catch a large part of the spam that comes in.
> > > > Aside from RFC considerations, this is not feasible on pragmatic
> > > > grounds: way too many legitimate hosts with broken DNS.
> > > 
> > > OTOH, if broken DNS started resulting in, e.g.:  mass email failures,
> > > sites would clean up right fast.
> > > 
> > > A long time ago, on a list far, far away, someone asked how they could
> > > prevent all the "WARNING: ..." messages showing up in his program logs.
> > > My reply:  fix your coding errors.
> > > 
> > > Bouncing ill-formed mail is *not* a bad thing.  Standards without
> > > consequences are not standards.
> > 
> > Unfortunately the standard in question explicitly specifies
> > that there be no consequences. 
> 
> Standard being what RFC?

Ah, dang.  I knew you'd ask me that.  Lemmeesee ... mumble mumble ...
ahh, here it is.  RFC1123.

      5.2.5  HELO Command: RFC-821 Section 3.5

         The sender-SMTP MUST ensure that the <domain> parameter in a
         HELO command is a valid principal host domain name for the
         client host.  As a result, the receiver-SMTP will not have to
         perform MX resolution on this name in order to validate the
         HELO parameter.

         The HELO receiver MAY verify that the HELO parameter really
         corresponds to the IP address of the sender.  However, the
         receiver MUST NOT refuse to accept a message, even if the
         sender's HELO command fails verification.


No doubt there's good reason.   It likes me not.  That guy MUST
do this, but you MUST NOT insist on it.   A standard without
a consequence.

-- 
-----------------------------------------------------------------
 Dan Wilder <dan@ssc.com>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549    URL http://embedded.linuxjournal.com/
-----------------------------------------------------------------




More information about the linux-elitists mailing list