Re: sendmail 8.14 has a serious memory corruption bug in it

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Claus Assmann wrote:
> On Tue, Feb 19, 2008, Constantine A. Murenin wrote:
> > On 19/02/2008, Claus Assmann <dragonfly-kernel@esmtp.org> wrote:
>
> > > No, they don't. I asked twice. (I could explain to you why they
>
> > I'm quite curious what the reason is -- do you mind sharing it?
>
> I have only a single static IP (it's an old contract). PacBell/AT&T 
> only delegates reverse DNS to you if you have at least 6 (8?) static 
> IP addresses. Changing to that doubles the amount of money I would 
> have to pay. I've considered changing ISPs instead (BTW: why are 
> static IP so expensive in the US? It's more than twice the amount of
> dynamic IPs...)

One may have a dsl router that holds onto the same dynamic IP for the
best part of a year, but over time, and 'on average' a dynamic IP can be
used to serve a great deal more than twice as many customers as a
dedicated IP.

Sometimes several hundred times (think dynamic PPPoE) - with near-zero 
admin cost vs the fixed-IP, and with carrier retention of control over 
yet-another toolset to block 'revenue loss' to, for example, VoIP, which 
they offer in competiton to public/free(ish) services.

> > On a side note, if I were you, I'd probably complain to the ISP for
> >  not specifying in their rDNS that your IP-address is static.
>
> How should they do that? I don't know of any "policy" at AT&T to do
> so... (or any "official" standard).

From what you (Claus) have said, (and 39+ years of dealing with 
dominant-carrier telcos) one guess is that you are 'grandfathered' on a 
service package they no longer offer at all.

Hence they *want* those still on it to cancel and upgrade.  Denying a 
proper RR becomes a tool in that progression, will probably be justified 
on the 'obsolete package, no-such feature, end of story', grounds.

> BTW: the IP address (63.195.85.27) is not in any "DNS based
> blocklist" that I know of. It's not even "classified" as dynamic IP
> in any of those. Moreover, there is a PTR record for it (as those who
> claim to know something about RFCs could have easily checked.)

ACK - but that is part of the burden you need to get out from under.

Within a dynamic block or not, (SORBS don't list it as such...) that RR 
is precisely the sort of RR that *specifies* a dynamic IP not assigned 
to any one organization:

adsl-63-195-85-27.dsl.snfc21.pacbell.net

rDNS quite aside, we would catch it in three different acl's on the 
'dsl' string match on my servers.

Dunno how Matt is doing it, but suspect a similar tool.


> > It would be nice if it was possible to configure sendmail to not
> > block any STARTTLS secure mail regardless of the ip or rDNS of the
> > sender,
>
> That's not a good idea. Spammers can easily set up TLS.

Not a good idea 'naked' - but while RFC provides wiggle-room w/r whether 
one uses TLS, an SSL tunnel, VPN, matching certs, or whatever - RFC and 
BCP are quite specific that the relay-submission function (as used by 
customer's MUA's) - require valid authentication.

Just for comparison, Exim's flag is tested with simply:

   authenticated = *

where the right side *could* be a complex test or a lookup.

But we've already matched to a specific port AND the non-standard 
protocol our user community must utilize as well as their UID:GID and 
pwd match when we set that flag.

I'm sure sendmail's rule syntax is different, but trust that the same 
functionality already exists.

;-)

> > as you web-page suggests; but to my knowledge, such configuration
> > of sendmail is quite non-trivial, so most people don't use it. If
> > you could provide some examples on the web-page where you make this
> >  suggestion, or, better yet, include such examples in the default 
> > configuration file, it would, IMHO, be the best approach to this 
> > problem.
>
> I'll take a look, thanks for the suggestion.

Bill