[ On Sat, August 9, 1997 at 10:52:58 (-0700), John Bolding wrote: ]
> Subject: how can i fight __this__ Spam?
>
> this spam used MAILER-DAEMON which evaluated to MAILER-DAEMON@???.
> the real From: line had a company name and phone number in it.
> I can block this spam via message body content, but then there is
> no place to bounce email back to.
>
> the other recourse is to use sender_net_reject, but we do have
> valid email contacts inside this domain, and this total IP block
> would be a last resort.
While it may be a last resort, it is probably also your only resort.
Not so long ago some big-mouths (and I won't name names as I might end
up on the list! ;-) lamented that one day soon there'd come a day when
spammers learned to use "MAIL FROM:<>" in their smtp connections to
prevent sender verification and filter hassles as well as the inevitable
bounce-backs.
I say that it's a "only & last" resort because many fine postmasters
have already given up pleading with the Earthlink.net to close down
third-party remote relay ability on their mailers (esp. those that live
in the *.it.earthlink.net domain -- I think they've managed to upgrade
at least some of their servers in the USA with protective measures).
(I personally don't know why Earthlink doesn't treat this as a criminal
trespass matter, though I agree that the jurisdictional problems are
indeed immense.)
Note that especially in this case, though generally in dealing with all
un-wanted e-mail, it is most important to block the mail *before* the
SMTP "DATA" command is issued. Even if there is a sender address, and
even if you go so far as to ascertain that the sender address target
domain has a valid MX RR that points to a valid A RR, this address may
still not be that of the true sender. Even if you went to the absurd
extent of connecting to the sender target mailer and requiring a good
response to a VRFY of the sender address you'd still not be sure it
represented the true sender. SMTP isn't called the "Simple Mail
Transport Protocol" for nothing! ;-)
I.e. what I'm trying to say is that if you're going to accept the
message then all you can hope to do is to do your best to deliver it as
requested. Your only other option is to not accept the message in the
first place. In fact this is exactly how I interpret the true meaning
of the RFC 1123 Robustness Principle esp. in the context of policy
enforcement.
The only other solution might be to write some AI software that can
decifer the zillions of possible "Received:" header formats and figure
out whether there's one that indicates a HELO/EHLO verification failed
upstream, and if so to then block the mail locally, though of course
this implies that you've accepted the DATA command and are proceding to
receive the message. You then have to wait until the end of the message
to issue a failure code, and of course at this point you've done most of
what the spammer wants you to do in the first place.
Of course I personally believe that RFC-1123's Robustness Principle must
be violated in the specifict case that HELO/EHLO verification failures
must result in an immeadiate rejection. Unfortunately not many
important mailers (i.e. important because of their resources,
particularly connectivity) deployed now in the real world have even the
capability of rejecting connections that begin with broken HELO/EHLO
parameters, let alone having it turned on.... [just as not enough yet
have the ability to reject third-party remote relay attempts]
This is indeed a very clever spam. I urge each and every one of you to
contact all postmasters you know, regardless of which mailer they might
run, and implore them with the greatest degree of urgency you can muster
that they implement protection against third-party remote relay in *all*
of the mailers they control and that they do it *NOW*. I for one have
seriously considered writing a module that opens a connection back to
the remote mailer and tests to see if it would permit me to relay mail
to a third remote site, and if so to reject the incoming connection
immediately.
> >From MAILER-DAEMON Fri Aug 08 09:32:18 1997
> >Return-path: <>
> >Received: from germany.it.earthlink.net [204.250.46.123]
> > by shibumi.firstbase.com with esmtp (Exim 1.62 #9)
> > id 0wwry3-0007AB-00; Fri, 8 Aug 1997 09:32:47 -0700
> >Received: from .- (1Cust73.max10.san-diego.ca.ms.uu.net [153.34.216.73])
> > by germany.it.earthlink.net (8.8.5/8.8.5) with SMTP id JAA15015
> > for <john@???>; Fri, 8 Aug 1997 09:34:31 -0700 (PDT)
> >Message-Id: <199708081634.JAA15015@???>
> >Date: Fri, 08 Aug 1997 09:30:35 -0700
> >From: (Contact XXXXXXXXXXXXXXXXXXXXXXXXXXX)
> >Sender: (Contact XXXXXXXXXXXXXXXXXXXXXXXXXXX)
> >Subject: Boost your traffic to firstbase.com...
> >To: john@???
> >X-Mailer: <Mailcast, version 1.0>
> >MIME-Version: 1.0
> >Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC4F39.FACCFEC0"
> >Content-Transfer-Encoding: 7bit
> >Status: RO
> >Content-Length: 944
--
Greg A. Woods
+1 416 443-1734 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
