I've run all my mailers with aggressive PTR checks for about a year, and
while some of my guests aren't getting all the e-mail that's sent to them,
it's had no impact on me other than that periodically I have to tell some
remote postmaster that their PTR's are missing or that they don't match
the HELO hostname. Invariably they fix it.
... What do you suggest otherwise-responsible operators like me do,
when after begging SBC for two years, my reverse DNS still isn't
delegated correctly?
buy a 1U, put it in a colo center (should cost you about $50/month) and
proxy all your outbound mail from there. stop thinking of broadband as
anything other than a lastmile protocol between your house and your own
piece of the internet core.
or send SBC a copy of RFC 2317 every hour via a crontab. might not be
very effective but it would sure get you talked about. since you're a
customer they can't accuse you of spamming them...
A Google search turned up http://www.unixwiz.net/techtips/pacbell-rdns.html
But wouldn't this defeat the very behavior you are depending on to
block mail? If every network administrator had reverse DNS for every
IP address, your check for systems lacking rDNS wouldn't work.
Or do we actually want a Fortune 1000 network. Direct communications
are prohibited between most users. If you are not a Fortune 1000 network,
you must forward your email through an approved provider which will check
the mail for unauthorized content.
Suppose AOL, MNN, Yahoo, etc agree to accept mail from each other and not
from other people. This is pretty much how the world worked from
1980-1990. CompuServe, MCIMail, The Source, Delphi, etc.
sean@donelan.com (Sean Donelan) writes:
A Google search turned up Setting up inverse DNS for SBC/Pacific*Bell Internet
But wouldn't this defeat the very behavior you are depending on to
block mail? If every network administrator had reverse DNS for every
IP address, your check for systems lacking rDNS wouldn't work.
that's one check of many. the PTR has to match the HELO, which means all
of the worms and spammers who forge @yahoo.com addresses and use YAHOO.COM
as their HELO will continue to get hammered.
Or do we actually want a Fortune 1000 network. Direct communications
are prohibited between most users. If you are not a Fortune 1000 network,
you must forward your email through an approved provider which will check
the mail for unauthorized content.
yes, actually, that's what we're headed for.
Suppose AOL, MNN, Yahoo, etc agree to accept mail from each other and not
from other people. This is pretty much how the world worked from
1980-1990. CompuServe, MCIMail, The Source, Delphi, etc.
fine by me. the people i want to exchange mail with aren't AOL users anyway.
that's one check of many. the PTR has to match the HELO, which
> means all of the worms and spammers who forge @yahoo.com
> addresses and use YAHOO.COM as their HELO will continue to get
> hammered.
If you're going to get picky about HELO names, then it's better to
require that the HELO has an A record pointing to the connecting IP,
rather than look at PTR.
the package in question (and maybe others do as well) has the option to
perform the reverse you describe. we tried the milder version first which
only verifies the ip sending the packets has a ptr - no domain xref. our
upstream provider is our alternate mx (with a higher pref, of course). any
mail they accept and forward to us would fail under the more restrictive
version of reverse (for example, say we were down for maint.). at least
that is my understanding after speaking with the software vendors
development team.
thanks.
Once upon a time, Andrew - Supernews <andrew@supernews.net> said:
If you're going to get picky about HELO names, then it's better to
require that the HELO has an A record pointing to the connecting IP,
rather than look at PTR.
That isn't necessarily a good test; for example, we've got a couple of
servers in a cluster. One IP pointed at the cluster is mail.hiwaay.net,
and that is what is used in HELO/EHLO when making outbound connections,
but the connections don't come from that IP. They come from the cluster
member's IP so that when we get a complaint with sending IP, we don't
have to look through the logs for the whole cluster to find the
offender.
Once upon a time, Andrew - Supernews <andrew@supernews.net> said:
>> If you're going to get picky about HELO names, then it's better to
>> require that the HELO has an A record pointing to the connecting IP,
>> rather than look at PTR.
> That isn't necessarily a good test;
There _is_ no good test, which is one reason why the RFC says
unequivocally "don't do that".
> for example, we've got a couple of servers in a cluster. One
> IP pointed at the cluster is mail.hiwaay.net, and that is what
> is used in HELO/EHLO when making outbound connections, but the
> connections don't come from that IP. They come from the
> cluster member's IP so that when we get a complaint with
> sending IP, we don't have to look through the logs for the
> whole cluster to find the offender.
In that case you'll fail _any_ sort of verification on the HELO, so
it doesn't really matter whether the recipient uses the PTR or the A
record.
sean@donelan.com (Sean Donelan) writes:
> A Google search turned up Setting up inverse DNS for SBC/Pacific*Bell Internet
>
> Or do we actually want a Fortune 1000 network. Direct communications
> are prohibited between most users. If you are not a Fortune 1000 network,
> you must forward your email through an approved provider which will check
> the mail for unauthorized content.
yes, actually, that's what we're headed for.
The side effect of this are truly chilling - no more peer-to-peer, and private
conversations are now the property of others.
Phil Zimmerman has a solution for the second part there.
The loss of peer-to-peer is however a bit harder to work around.