DragonFly kernel List (threaded) for 2008-02
Re: sendmail 8.14 has a serious memory corruption bug in it
Claus Assmann wrote:
On Tue, Feb 19, 2008, Constantine A. Murenin wrote:
On 19/02/2008, Claus Assmann <firstname.lastname@example.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
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.
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
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 (184.108.40.206) 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
I'll take a look, thanks for the suggestion.