MESSAGE
| DATE | 2008-12-19 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] [Fwd: Re: admin question]
|
From lest-hangout-at-mrbrklyn.com Fri Dec 19 00:26:41 2008
Received: from www2.mrbrklyn.com (localhost [127.0.0.1])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id mBJ5Qdd8031681
for ; Fri, 19 Dec 2008 00:26:41 -0500
Received: (from majordomo-at-localhost)
by www2.mrbrklyn.com (8.13.1/8.13.1/Submit) id mBJ5QdaH031680
for hangout-outgoings; Fri, 19 Dec 2008 00:26:39 -0500
X-Authentication-Warning: www2.mrbrklyn.com: majordomo set sender to lest-hangout-at-nylxs.com using -f
Received: from [68.167.17.98] (www2.mrbrklyn.com [68.167.17.98])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id mBJ5Qaap031677
for ; Fri, 19 Dec 2008 00:26:38 -0500
Message-ID: <494B308B.403-at-mrbrklyn.com>
Date: Fri, 19 Dec 2008 00:26:35 -0500
From: Ruben Safir
User-Agent: Thunderbird 2.0.0.18 (X11/20081105)
MIME-Version: 1.0
To: hangout-at-mrbrklyn.com
Subject: [NYLXS - HANGOUT] [Fwd: Re: admin question]
Content-Type: multipart/mixed;
boundary="------------080401010407080508080804"
Sender: lest-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com
This is a multi-part message in MIME format.
--------------080401010407080508080804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
--------------080401010407080508080804
Content-Type: message/rfc822;
name="Re: admin question.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Re: admin question.eml"
X-Account-Key: account2
X-Mozilla-Keys:
Received: from linuxmafia.com (linuxmafia.com [198.144.195.186])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id mBIMdr2v027496
for ; Thu, 18 Dec 2008 17:39:55 -0500
Received: from rick by linuxmafia.com with local (Exim 4.61 #1 (EximConfig 2.0))
id 1LDRWx-0000qH-El by authid
for ; Thu, 18 Dec 2008 14:39:43 -0800
Date: Thu, 18 Dec 2008 14:39:42 -0800
From: Rick Moen
To: Ruben Safir
Subject: Re: admin question
Message-ID: <20081218223942.GA8960-at-linuxmafia.com>
References: <20081217213343.GT8960-at-linuxmafia.com> <20081218125805.GA19481-at-www2.mrbrklyn.com> <20081218195002.GY8960-at-linuxmafia.com> <494AC3FD.3030707-at-mrbrklyn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <494AC3FD.3030707-at-mrbrklyn.com>
X-Mas: Bah humbug.
User-Agent: Mutt/1.5.11+cvs20060403
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: rick-at-linuxmafia.com
Quoting Ruben Safir (ruben-at-mrbrklyn.com):
> Rick Moen wrote:
> > Quoting Ruben Safir (ruben-at-mrbrklyn.com):
> >
> >> Rick
> >>
> >> Do you know of a way of limiting the sendmail to recieving mail
> >> from my local ip addresses to my local network only?
> >>
> >> Or maiybe you know someone who might know? I have some spammer
> >> sending my mailing list mail spoofing my email address. They are
> >> evidently smart enough to confirm my name as existing from the SMTP
> >> connection.
> >
> > Here's something else you're not going to want to hear: The above
> > comments suggest you've almost certainly carried forward a sendmail
> > configuration from many years ago that is now woefully obsolete, and
> > is as a result shooting you in the foot. This happens.
> >
> > The reason I say that is you've described a problem that hasn't been
> > present for many year in default configurations of any common *ix
> > MTA. Logically, that means it's an artifact of your local config.
> >
> > Generally speaking, your best bet, then, is to start over with a
> > modern MTA's modern default config.
> >
> > If you _happen_ to be in the mood for considering an MTA switch, the
> > current best-practices choice is Postfix. (I do not use Postfix,
> > but rather Exim4. Were I to choose a new MTA, it would be Postfix,
> > but it doesn't have sufficiently compelling advantages to justify the
> > pain of switching.)
> >
>
> It's just an issue of inertial. A new MTA means learning a bunch of new
> things.
> In this case though, the problem is that the mail is actually addressed
> to the
> mailing list but my name is being spoofed on the from line.
Are you implementing SPF (publishing an SPF RR in your domain's DNS, and
then checking that RR in your MTA when it receives mail)? (It's
possible that I might have slightly misunderstood your question, the
first time. Unfortunately, I'm short on sleep at the moment.)
The purpose of SPF is to ensure that nobody can, ever again, conduct a
believable "Joe Job"[0] of a reputable domain. However, it works only if
you bother to publish a record that people can check -- and your MTA can
take advantage of it only if you have code to do so, there.
Making for a moment the assumption that you're talking about mailing
lists on domain mrbrklyn.com:
:r! dig -t txt mrbrklyn.com +short
[Returns null.]
Nope, it appears that you have not _even_ bothered to create an SPF RR.
To review, an SPF RR (tucked away into the catch-all "TXT" record type,
for lack of a dedicated RR from the IETF process) declares
(paraphrasing) that "This roster of IPs, and these alone, should be
regarded as authorised MXes for the cited domain. If you receive mail
from any IP not identified here, please assume the mail is forged."
linuxmafia.com's SPF RR:
:r! dig -t txt linuxmafia.com +short
"v=spf1 a mx -all"
Unpacking that syntax:
"v=spf1" => This record implements v. 1 of the SPF spec
"a" => Use the domain's "a" record for verification.
"mx" => Alternatively, use the "mx" record for verification.
"-all" => Hardfail check, if the IP doesn't match either of the foregoing.
Further details at: http://www.zytrax.com/books/dns/ch9/spf.html
So, basically, my DNS is informing the world that, if mail doesn't
arrive from IP 198.144.195.186 or from my published MX host (which is
currently mapped to the same thing, resolving via the MX-referenced A
record to IP 198.144.195.186), then it should be regarded as
conclusively forged.
Publishing a syntactically correct SPF RR is the easy part, and is
greatly in the interest of any domain owner to do, completely without
regard to whether one does anything else -- in part because it's
dead-simple and a one-time task. (You _should_ also have an explicit MX
record, Ruben! I've told you this before.) The more-difficult part is
integrating SPF-_checking_ into an MTA.
I have no relevant experience whatsoever in doing that with sendmail
(because sendmail's been gone from my life for a decade), but
Web-searching quickly finds at least one way to do it. There may be
more:
http://www.brandonhutchinson.com/Installing_Milter-SPF_with_Sendmail.html
[0] See the "Joe-job" entries on http://linuxmafia.com/kb/Mail/ for the
context and history of this term. People tend not to use the term "Yuri
Rutman" in their anecdotes about the invention of that particular form
of Internet abuse, because Rutman threatens and harrasses people who
talk about it. (You'll notice that Rutman apparently even harrassed
Google into expunging some of the evidence from Google Groups, nee
DejaNews.)
[1] I just read in a Feb. 2007 mailing list posting that IETF did
eventually approve a new RR for SPF, and BIND 9.4.0 and later supports
it. http://www.gossamer-threads.com/lists/spf/deployment/30942
--------------080401010407080508080804--
|
|
