DragonFly kernel List (threaded) for 2008-02
DragonFly BSD
DragonFly kernel List (threaded) for 2008-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Tue, 19 Feb 2008 23:59:41 +0000

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 ( 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:


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

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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]