Recently, Somebody Somewhere wrote these words
> On Tue, Nov 15, 2005 at 08:06:45AM +0000, Declan Moriarty wrote:
> > This is informational, as a lot of you seem to be using poorly
> > configured mail servers without knowing it.
> >
> > There are 2 main errors:
> >
> > 1. Allowing IP addresses reserved for private networks onto the net,
> > e.g.
> >
> > Received: from [192.168.1.45]
> > (pool-71-103-104-29.lsanca.dsl-w.verizon.net [71.103.104.29]) by
> > hops.lfs-matrix.net
> >
> > 192.168.xxx.xxx doesn't resolve to anything. For those with spam
> > filters, this triggers various rules, usually UNPARSEABLE_RELAY, an
> > excellent spam indicator.
>
> Whoa. Take a step back and read the RFC's. This is totally valid as
> far as private/public IP's is concerned. The private IP in the example
> above is not intended to be resolvable, per se. It is the HELO, which
> can be just about anything. It is only the receiving smtpd's job to
> decide if it wants to accept that HELO, not any of the following
> smtpd's it may be passed on to. Any sane mail server that cannot
> restrict based on what segment of the network the client is on relies
> on other means of authenticating. The above server I happen to know
> uses SMTP AUTH which supercedes HELO checks. Note, these HELO checks
> would be performed by an outsider who is mailing someone local to the
> above server and one could/should allow for restricting based on that,
> but that is for the SMTP server, not a spam filter. So back to the
> example above; the part in parentheses is what the mail server
> determines on it's own via reverse DNS lookup, so now the IP and the
> hostname are known valid (assuming the reverse DNS was setup correctly
> by the ISP or whoever). So now you have your resolvable address.
The numbers are 1. Internal IP 2.Modem's hostname 3. Reverse lookup,
as I understand it, and that one is lifted from a legitimate mail.
2 & 3 'bell out', but 1 doesn't. There's such a variety on the
bracketing that it's nearly impossible for regexes to clarify what's
going on.
>
> And for postfix users who want to put a stranglehold on spam at the
> smtp level, and avoid SA and it's huge penalty, look at the postfix
> man pages for the following (note, this is very restrictive, and order
> is important):
Fine if your mail is not relayed to you. With a half decent isp in the
way, any rejections at smtp level bounce anyhow for the end user.
> > Received: from p54A52B17.dip0.t-ipconnect.de (EHLO Trollhammer)
> > [84.165. 43.23]
>
> > Received: from fiancee (unknown [81.106.244.9]) by smtp14 (Coremail)
> > with SMTP id GQBiG7f6dENq1UsC.1
>
> So ahead and fight the good fight, but until everyone in the world
> stops using Outlook and Outlook express (and others, I'm sure) then
> netBIOS names will continue to be sent as HELO/EHLO names. :/
>
Archaic, you're out there on linuxfromscratch.org which can bounce mail
and send mail directly. I'm on a bb modem like most folks and have to
relay through my isp, and only get through because I'm in their network
range. I _do_not_receive_ at smtp level. It's pop3. SA is therefore a
must for the likes of me, who doesn't want to look at spam.
My point was simply that if you are on the isp's network allocation, and
send mail from mysillydomain.com, SA down the line gets suspicious, and
rightly so IMHO. I wasn't particularly complaining about outlook - I'm
not that much OT!
It appears that some of the spam lying around has been sent by
telenetting or SSHing into some weak server, and then simply directing
it to the weak server's mail port, which suddenly finds itself holding a
mail 'from itself'. So the received lines look good from a certain
point, and the only clue is the earlier sections.
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
