> 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
Christopher X. Candreva writes on 12/3/2003 10:13 AM:
Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP
servers without reverse DNS came up here in this discussion, I just ran a
manual queue run to clean out a queue, and saw this come up:
They have had this policy since sever
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 w
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 s
Christopher X. Candreva writes on 12/3/2003 10:42 AM:
discussion on a different list -- I was sure in the whole Verizon "spam
measures hurting other servers" thread, the whole blocking w/o IN PTR
records had come up, with people saying they were on hosting where they
couldn't change PTR records,
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'
>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
On 3 Dec 2003, at 10:51, Suresh Ramasubramanian wrote:
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 und
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 ;)
http://homepages.tesc
[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 ac
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, serv
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 wrong
>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 high
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
lay
Jeffrey Paul writes on 12/3/2003 11:39 AM:
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?
A lot of spam these days comes from trojaned windows machines on dialup
/ broadband IPs.
Most ISPs in the USA and the wor
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 sho
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
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.htm
> ... 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.
S
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 label of the ns rr to delegate only 1.2.3.42
Do you mean ns.42.3.2.1.in-addr.arpa? I still
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 I'
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
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 re
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 DNS ?
>
>
>
> 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 requirement for MANY services
> for MANY ye
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 label of the ns r
[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
Suresh Ramasubramanian wrote:
They have had this policy since several months now but it is still a
"may" - and does give them a good excuse to take out large IP blocks
that don't have proper reverse DNS assigned and emit a lot of spam.
As I understand it, they blacklist if an IP with no rDNS g
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 discard
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?
> > >
>
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 authoritat
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, th
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 like
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 the
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 tech
Adam McKenna wrote:
>
> 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.
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
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.
> >
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
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 'gluel
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 leav
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 la
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 fanta
51 matches
Mail list logo