On Sat, Dec 06, 2003 at 09:53:15PM -0500, Adam Kujawski wrote:
If the customer has a dozen name servers they want you to allocate reverse DNS
for, it could become unwieldy, but technically, is there anything wrong with
this setup?
I believe that this setup could be susceptible to the
just me wrote:
Can you explain to the less hyperbolic among us, why I should be
obligated to exchange packets with a provider who hosts abusive
customers.
You, and nobody else is not. The difference is if you carpet-bomb the
provider
or launch a smart device to it´s intended target.
I´ll
On Mon, 8 Dec 2003, Petri Helenius wrote:
just me wrote:
Can you explain to the less hyperbolic among us, why I should be
obligated to exchange packets with a provider who hosts abusive
customers.
You, and nobody else is not. The difference is if you carpet-bomb
the provider or
Quoting Adam McKenna [EMAIL PROTECTED]:
On Thu, Dec 04, 2003 at 04:59:59PM -0800, Crist Clark wrote:
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15 $ NS a.ns.$
$GENERATE 0-15 a.ns.$ A 204.50.168.2
Is any harder than,
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15
On Sat, 6 Dec 2003, Adam Kujawski wrote:
Why bother with CNAMES or A records? Is there anything wrong with simply using
NS records for each adress? i.e.:
$ORIGIN 109.246.64.in-addr.arpa.
1NS ns1.customerA.com.
1NS ns2.customerA.com.
This will work. For
[EMAIL PROTECTED] wrote:
...
It's not the reverse DNS itself that is meaningful. It is the
fact that the SMTP server operator with proper IN PTR records
probably has the cooperation of their ISP.
This is a broken model. People that are buying high level services should
expect those to be
On Thu, 4 Dec 2003, Tony Hain wrote:
This is a broken model. People that are buying high level services should
expect those to be delivered correctly, but those who are buying bit
transport should not be required to obtain additional services to become
fully functional. It is nice to
Chris Lewis writes on 12/4/2003 2:24 PM:
As I understand it, they blacklist if an IP with no rDNS generates some
threshold of complaints. Not just no rDNS by itself.
That is a good way to go.
A simple no rDNS rule causes too much trouble with our overseas
customers. I'm sure AOL discarded
Adam McKenna wrote:
On Wed, Dec 03, 2003 at 09:53:37AM -0800, Adam McKenna wrote:
On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
How can delegating in-addr.arpa on a per-ip basis be any different or worse
than delegating it using an rfc2317 scheme?
consider the
On Thu, Dec 04, 2003 at 02:04:54PM -0800, Crist Clark wrote:
$ dig 3.2.1.in-addr.arpa soa
$ dig 42.3.2.1.in-addr.arpa soa
This email contains approximately the same information as Randy's did. Yes,
the SOA's will be different. That is what is intended. The nameserver that
is
Suresh Ramasubramanian wrote:
A simple no rDNS rule causes too much trouble with our overseas
customers. I'm sure AOL discarded that idea for the same reason.
Yup. The model can be extended to if no rDNS, and if spamtrap hits or
other spammish behavior noted from more than X IPs per /24, then
Petri Helenius writes on 12/4/2003 5:36 PM:
Yup. The model can be extended to if no rDNS, and if spamtrap hits or
other spammish behavior noted from more than X IPs per /24, then block
the /24.
And why would blocking the /24 be appropriate instead of matching the
registry?
I would refer you
Suresh Ramasubramanian wrote:
Petri Helenius writes on 12/4/2003 5:36 PM:
And why would blocking the /24 be appropriate instead of matching the
registry?
I would refer you to the huge number of netblocks out there that stay
at /16 or larger size, with the upstream not SWIP'ing or otherwise
On Fri, 5 Dec 2003, Petri Helenius wrote:
And I refer you to the blocks which are properly registered down
to the /29 level and you are saying that if you are a good citizen
collateral damage is recommended regardless because antispammers
are either lazy or technically incompetent or
Petri Helenius writes on 12/4/2003 5:46 PM:
And I refer you to the blocks which are properly registered down to the
/29 level and
you are saying that if you are a good citizen collateral damage is
recommended
regardless because antispammers are either lazy or technically incompetent
or like
just me wrote:
On Fri, 5 Dec 2003, Petri Helenius wrote:
And I refer you to the blocks which are properly registered down
to the /29 level and you are saying that if you are a good citizen
collateral damage is recommended regardless because antispammers
are either lazy or
On Thu, Dec 04, 2003 at 04:59:59PM -0800, Crist Clark wrote:
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15 $ NS a.ns.$
$GENERATE 0-15 a.ns.$ A 204.50.168.2
Is any harder than,
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15 CNAME $.0/28
0/28NS
On Thu, 4 Dec 2003, Tony Hain wrote:
Can you explain to the less hyperbolic among us, why I should be
obligated to exchange packets with a provider who hosts abusive
customers.
Disclaimer: I am not a lawyer.
That said, IMHO you are free to do what you want as an individual, but
I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.
you're right. it will be. people will have to clean up their
in-addr.arpa. or am i missing some reason they
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their
in-addr.arpa. or am i missing some reason they can't, other
than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking of a
discussion on a different list -- I was
Randy Bush writes on 12/3/2003 10:18 AM:
you're right. it will be. people will have to clean up their
in-addr.arpa. or am i missing some reason they can't, other
than laziness?
Well - unless you have a /24, in-addr.arpa is typically under the
control of your upstream provider.
And at least
At 10:42 AM 12/3/2003, Christopher X. Candreva wrote:
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their
in-addr.arpa. or am i missing some reason they can't, other
than laziness?
See, this is the war I didn't want to start again. Unless I'm
the whole blocking w/o IN PTR
records had come up,
Interestingly, there was a time when access to FTP servers
was considered important and many FTP servers blocked access
if the IN PTR records did not match the IN A records.
with people saying they were on hosting where they
couldn't change
Joe Abley writes on 12/3/2003 11:11 AM:
RFC2317.
that'd still involve the ISP inserting stuff in their nameservers.
when isp admins are substituted by drones working out of templates /
web forms ...
ps - there's of course the rather umm... interesting content below ;)
[EMAIL PROTECTED] wrote:
Proper configuration of in-addr.arpa is a good idea TM.
However, it isn't the right way for large mail server operators
to go. Instead, they should start exchanging their SMTP sessions
on a port other than 25, i.e. NIMTP (New Improved MTP). The NIMTP
servers would not
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;)
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
Which is totally, completely wrong and causes, in both cases, servers
Perhaps I'm being naïve, but this seems like a very good way to cause spammers to
suddenly start having valid PTR RRs. Thoughts?
-j
--
Jeffrey Paul - [EMAIL PROTECTED] - (877) 748-3467
Senior Network Administrator, Diamond Financial Products
Pete Ehlke writes on 12/3/2003 11:38 AM:
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;)
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
Which is totally, completely
The system exactly like you describe already exists. It´s based on the
standard
X.400 protocol and is available across the world.
Wrong.
X.400 is immensely more complex than a federation of ISPs using
SMTP on another port number.
Or in some parts, used to
be. If that approach would be highly
On Wed, 3 Dec 2003 [EMAIL PROTECTED] wrote:
[snip]
Peering relationships work for BGP (lots of rules) and they worked
for USENET (not many rules). Why can't the same principles be applied
to email or IM services?
Where is NickC when you need him... this sounds like something out of his
Greg Maxwell writes on 12/3/2003 11:39 AM:
Seriously, do we really need SMTP peering agreements? I don't know of too
many places that are UUCPing their email... SMTP traffic already crosses
(BGP) peering agreement controlled links. If putting contractional
obligations there fails to work why
Jeffrey Paul wrote:
Perhaps I'm being naïve, but this seems like a very good way to cause
spammers to suddenly start having valid PTR RRs. Thoughts?
or limiting attacks for relay/proxy/trojan purposes targets that have valid
PTR records which of course ideally should be all of them.
Daniel Senie [EMAIL PROTECTED] writes:
Many will turn on a flag to specify some PTR must exist if AOL or
some other large provider does it and is able to stick with it.
Yes, there'll be some work for DNS-clued consultants if that happens.
The impact on the 'net will not be all that
On Wed, Dec 03, 2003 at 08:38:10AM -0800, Pete Ehlke wrote:
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;)
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
... and it will be a zero-sum game once the spammers (or their
complicit ISPs) fix their in-addrs too.
'cept the in-addr.arps space from which they are coming has to be
populated. i.e., no more connects from black holes.
randy
How can delegating in-addr.arpa on a per-ip basis be any different or worse
than delegating it using an rfc2317 scheme?
consider the label of the ns rr to delegate only 1.2.3.42
What about speaking plain old smtp, but with transport / mailertable
rules routing all mail for domain X (say AOL or MSN) to special
access servers that have firewall ACLs allowing only connections from a
restricted set of IPs?
If it's behind a firewall, then it's not on the Internet.
Since
On Dec 3, 2003, at 10:42 AM, Christopher X. Candreva wrote:
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their
in-addr.arpa. or am i missing some reason they can't, other
than laziness?
See, this is the war I didn't want to start again. Unless
In message [EMAIL PROTECTED], Matthew Crocker
AOL says the PTR record needs to be assigned. It doesn't specify it
has to match the @domain.com in the MAIL FROM: header. Wouldn't it be
enough to make sure every IP address you announce has a PTR and
matching A record? Hasn't this been a
On Wed, 3 Dec 2003, Robert E. Seastrom wrote:
... and it will be a zero-sum game once the spammers (or their
complicit ISPs) fix their in-addrs too.
I disagree. I don't think the spammers, by and large, 'own' their IP
addresses. They are using (as someone said) hijacked space, or compromised
You mean like Level3?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Steven M. Bellovin
Sent: Wednesday, December 03, 2003 2:27 PM
To: Matthew Crocker
Cc: Christopher X. Candreva; [EMAIL PROTECTED]
Subject: Re: AOL rejecting mail from IP's w/o reverse
, December 03, 2003 2:27 PM
To: Matthew Crocker
Cc: Christopher X. Candreva; [EMAIL PROTECTED]
Subject: Re: AOL rejecting mail from IP's w/o reverse DNS ?
In message [EMAIL PROTECTED], Matthew
Crocker
AOL says the PTR record needs to be assigned. It doesn't specify it
has to match
AOL says the PTR record needs to be assigned. It doesn't specify it
has to match the @domain.com in the MAIL FROM: header. Wouldn't it be
enough to make sure every IP address you announce has a PTR and
matching A record? Hasn't this been a requirement for MANY services
for MANY years?
43 matches
Mail list logo
