Re: Anyone from AT DNS?

[Matt Peterman]

I can now confirm that Christopher is right about everything (not that I had 
any doubts! Just wanted to confirm all is working!!) 

ATT is now following the RFC (apparently has changed since November 2016 and 
June 2017 allocations and DNS changes) and that Route53 WebUI displays things 
strangely, however technically works fine on the backend. rDNS is now working 
properly. Thank you Christopher very much! I learned a lot in the last hour I 
can sure say that! 

Matt



> On Oct 4, 2017, at 11:20 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman  > wrote:
> Got it! You’re the winner here. I just setup both of my zones the name way 
> and obviously AT changed the way they did RDNS entries from when I got a 
> /25 last November and this second /25 in June. Oh well!
> 
> Now I am running into the challenge of Route53 does seem to support creating 
> an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It changes it to 
> "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one 
> thing its something else. 
> 
> 
> I've not messed with route53 but fortunately you are treading on well trodden 
> ground:
>   https://forums.aws.amazon.com/thread.jspa?messageID=674778 
> 
> 
> have a happy evening! (and I hope that the above works.. again I haven't and 
> can't actually try it)

Re: Anyone from AT DNS?

[Christopher Morrow]

On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman  wrote:

> Got it! You’re the winner here. I just setup both of my zones the name way
> and obviously AT changed the way they did RDNS entries from when I got a
> /25 last November and this second /25 in June. Oh well!
>
> Now I am running into the challenge of Route53 does seem to support
> creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It
> changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If
> it isn't one thing its something else.
>
>
I've not messed with route53 but fortunately you are treading on well
trodden ground:
  https://forums.aws.amazon.com/thread.jspa?messageID=674778

have a happy evening! (and I hope that the above works.. again I haven't
and can't actually try it)

Re: Anyone from AT DNS?

[Matt Peterman]

Got it! You’re the winner here. I just setup both of my zones the name way and 
obviously AT changed the way they did RDNS entries from when I got a /25 last 
November and this second /25 in June. Oh well!

Now I am running into the challenge of Route53 does seem to support creating an 
authoritative zone for "128/25.168.207.107.in-addr.arpa.” It changes it to 
"128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing 
its something else. 



> On Oct 4, 2017, at 11:11 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman  > wrote:
> You are correct through that that link does show having the CIDR prefix 
> length in the CNAME which is weird because AT did not do this on my other 
> /25 block. Interesting… Guess I need to do more digging. 
> 
> 
> if I had to guess I'd say that 'sometime long ago' they did one way, then 
> decided to just follow the RFC ... which probably also makes their 
> provisioning automation much simpler.
> 
> as I said, there are more than 1 way to skin the cat :( sadly you (and I, at 
> least) were used to the 'old fashioned method' welcome to 1998 (apparently!) 
> :)
>  
> Matt
> 
> 
> 
>> On Oct 4, 2017, at 10:53 PM, Christopher Morrow > > wrote:
>> 
>> 
>> 
>> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > > wrote:
>> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They 
>> are returning as
>> $ dig +short CNAME 128.168.207.107.in-addr.arpa
>> 128.128/25.168.207.107.in-addr.arpa.
>> 
>> Which is obviously a completely invalid DNS entry. I have opened a ticket 
>> through the web portal for “prov-dns” but Haven’t gotten a response for 7 
>> days.
>> 
>> If anyone from AT DNS or knows anyone from AT DNS that can help it would 
>> be appreciated!
>> 
>> 
>> isn't this one of the proper forms of reverse delegation in CIDR land? 
>> 
>> like:
>> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx 
>> 
>> 
>> describes, or in a (perhaps more wordy fashion) in RFC2317?
>>   http://tools.ietf.org/html/rfc2317 
>> 
>> I think it may be the case that the NS hosts are not prepared for such a 
>> domain/record mapping though... the nameservers that would need to to be 
>> authoritative for a zone like:
>> 
>> 
>> 128/25.168.207.107.in-addr.arpa.
>> 
>> and have a bunch of PTR records like:
>> 
>> 128 IN PTR foo.you.com .
>> 129 IN PTR bar.you.com .
>> 
>> etc...
>> 
>> 
> 
> 

Re: Anyone from AT DNS?

[Christopher Morrow]

On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman  wrote:

> You are correct through that that link does show having the CIDR prefix
> length in the CNAME which is weird because AT did not do this on my other
> /25 block. Interesting… Guess I need to do more digging.
>
>
if I had to guess I'd say that 'sometime long ago' they did one way, then
decided to just follow the RFC ... which probably also makes their
provisioning automation much simpler.

as I said, there are more than 1 way to skin the cat :( sadly you (and I,
at least) were used to the 'old fashioned method' welcome to 1998
(apparently!) :)


> Matt
>
>
>
> On Oct 4, 2017, at 10:53 PM, Christopher Morrow 
> wrote:
>
>
>
> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman 
> wrote:
>
>> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They
>> are returning as
>> $ dig +short CNAME 128.168.207.107.in-addr.arpa
>> 128.128/25.168.207.107.in-addr.arpa.
>>
>> Which is obviously a completely invalid DNS entry. I have opened a ticket
>> through the web portal for “prov-dns” but Haven’t gotten a response for 7
>> days.
>>
>> If anyone from AT DNS or knows anyone from AT DNS that can help it
>> would be appreciated!
>>
>>
> isn't this one of the proper forms of reverse delegation in CIDR land?
>
> like:
> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-
> reverse-zone.aspx
>
> describes, or in a (perhaps more wordy fashion) in RFC2317?
>   http://tools.ietf.org/html/rfc2317
>
> I think it may be the case that the NS hosts are not prepared for such a
> domain/record mapping though... the nameservers that would need to to be
> authoritative for a zone like:
>
>
> 128/25.168.207.107.in-addr.arpa.
>
> and have a bunch of PTR records like:
>
> 128 IN PTR foo.you.com.
> 129 IN PTR bar.you.com.
>
> etc...
>
>
>
>

Re: Anyone from AT DNS?

[Christopher Morrow]

On Wed, Oct 4, 2017 at 11:03 PM, Matt Peterman  wrote:

> The correct format is as shown below (this is from another /25 I have from
> AT that has DNS setup correctly)
>
> $ dig +short CNAME 1.120.232.108.in-addr.arpa
> 1.0.120.232.108.in-addr.arpa.
>
>
there are more than 1 way to skin the cat, sadly.
This tripped me up on a customer connection for a while as well, the RFC
example I provided earlier is also valid.


> So for the block I am having an issue with the CNAME records should be
> For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it
> shouldn't have “/25” in the middle of it - you can’t even have “/“ in a DNS
> entry AFAIK)
>

according to the rfc you can.


> If I do another address from my block I get $ dig +short CNAME
> 191.168.207.107.in-addr.arpa
> 191.128/25.168.207.107.in-addr.arpa.
>
> Again that would should be 191.128.168.207.107in-addr.arpa.
>
> Somehow AT DNS got the “/25” prefix length in all of the  DNS entries…
>
>
nope, they are just following the rfc provided path for this.
yes it looks screwy, yes it also works fine.


> Matt
>
>
>
> On Oct 4, 2017, at 10:53 PM, Christopher Morrow 
> wrote:
>
>
>
> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman 
> wrote:
>
>> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They
>> are returning as
>> $ dig +short CNAME 128.168.207.107.in-addr.arpa
>> 128.128/25.168.207.107.in-addr.arpa.
>>
>> Which is obviously a completely invalid DNS entry. I have opened a ticket
>> through the web portal for “prov-dns” but Haven’t gotten a response for 7
>> days.
>>
>> If anyone from AT DNS or knows anyone from AT DNS that can help it
>> would be appreciated!
>>
>>
> isn't this one of the proper forms of reverse delegation in CIDR land?
>
> like:
> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-
> reverse-zone.aspx
>
> describes, or in a (perhaps more wordy fashion) in RFC2317?
>   http://tools.ietf.org/html/rfc2317
>
> I think it may be the case that the NS hosts are not prepared for such a
> domain/record mapping though... the nameservers that would need to to be
> authoritative for a zone like:
>
>
> 128/25.168.207.107.in-addr.arpa.
>
> and have a bunch of PTR records like:
>
> 128 IN PTR foo.you.com.
> 129 IN PTR bar.you.com.
>
> etc...
>
>
>
>

Re: Anyone from AT DNS?

[Matt Peterman]

You are correct through that that link does show having the CIDR prefix length 
in the CNAME which is weird because AT did not do this on my other /25 block. 
Interesting… Guess I need to do more digging. 

Matt



> On Oct 4, 2017, at 10:53 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman  > wrote:
> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are 
> returning as
> $ dig +short CNAME 128.168.207.107.in-addr.arpa
> 128.128/25.168.207.107.in-addr.arpa.
> 
> Which is obviously a completely invalid DNS entry. I have opened a ticket 
> through the web portal for “prov-dns” but Haven’t gotten a response for 7 
> days.
> 
> If anyone from AT DNS or knows anyone from AT DNS that can help it would 
> be appreciated!
> 
> 
> isn't this one of the proper forms of reverse delegation in CIDR land? 
> 
> like:
> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx 
> 
> 
> describes, or in a (perhaps more wordy fashion) in RFC2317?
>   http://tools.ietf.org/html/rfc2317 
> 
> I think it may be the case that the NS hosts are not prepared for such a 
> domain/record mapping though... the nameservers that would need to to be 
> authoritative for a zone like:
> 
> 
> 128/25.168.207.107.in-addr.arpa.
> 
> and have a bunch of PTR records like:
> 
> 128 IN PTR foo.you.com .
> 129 IN PTR bar.you.com .
> 
> etc...
> 
> 

Re: Anyone from AT DNS?

[Matt Peterman]

The correct format is as shown below (this is from another /25 I have from AT 
that has DNS setup correctly) 

$ dig +short CNAME 1.120.232.108.in-addr.arpa
1.0.120.232.108.in-addr.arpa.

So for the block I am having an issue with the CNAME records should be 
For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it shouldn't 
have “/25” in the middle of it - you can’t even have “/“ in a DNS entry AFAIK)
If I do another address from my block I get $ dig +short CNAME 
191.168.207.107.in-addr.arpa
191.128/25.168.207.107.in-addr.arpa.

Again that would should be 191.128.168.207.107in-addr.arpa. 

Somehow AT DNS got the “/25” prefix length in all of the  DNS entries…

Matt



> On Oct 4, 2017, at 10:53 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman  > wrote:
> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are 
> returning as
> $ dig +short CNAME 128.168.207.107.in-addr.arpa
> 128.128/25.168.207.107.in-addr.arpa.
> 
> Which is obviously a completely invalid DNS entry. I have opened a ticket 
> through the web portal for “prov-dns” but Haven’t gotten a response for 7 
> days.
> 
> If anyone from AT DNS or knows anyone from AT DNS that can help it would 
> be appreciated!
> 
> 
> isn't this one of the proper forms of reverse delegation in CIDR land? 
> 
> like:
> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx 
> 
> 
> describes, or in a (perhaps more wordy fashion) in RFC2317?
>   http://tools.ietf.org/html/rfc2317 
> 
> I think it may be the case that the NS hosts are not prepared for such a 
> domain/record mapping though... the nameservers that would need to to be 
> authoritative for a zone like:
> 
> 
> 128/25.168.207.107.in-addr.arpa.
> 
> and have a bunch of PTR records like:
> 
> 128 IN PTR foo.you.com .
> 129 IN PTR bar.you.com .
> 
> etc...
> 
> 

Re: Anyone from AT DNS?

[Christopher Morrow]

On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman  wrote:

> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They
> are returning as
> $ dig +short CNAME 128.168.207.107.in-addr.arpa
> 128.128/25.168.207.107.in-addr.arpa.
>
> Which is obviously a completely invalid DNS entry. I have opened a ticket
> through the web portal for “prov-dns” but Haven’t gotten a response for 7
> days.
>
> If anyone from AT DNS or knows anyone from AT DNS that can help it
> would be appreciated!
>
>
isn't this one of the proper forms of reverse delegation in CIDR land?

like:
http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx

describes, or in a (perhaps more wordy fashion) in RFC2317?
  http://tools.ietf.org/html/rfc2317

I think it may be the case that the NS hosts are not prepared for such a
domain/record mapping though... the nameservers that would need to to be
authoritative for a zone like:


128/25.168.207.107.in-addr.arpa.

and have a bunch of PTR records like:

128 IN PTR foo.you.com.
129 IN PTR bar.you.com.

etc...

Anyone from AT DNS?

[Matt Peterman]

The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are 
returning as 
$ dig +short CNAME 128.168.207.107.in-addr.arpa
128.128/25.168.207.107.in-addr.arpa.

Which is obviously a completely invalid DNS entry. I have opened a ticket 
through the web portal for “prov-dns” but Haven’t gotten a response for 7 days. 

If anyone from AT DNS or knows anyone from AT DNS that can help it would be 
appreciated! 

Matt

Re: BGP hijack: 64.68.207.0/24 from as133955

[Sandra Murphy]

Not to respond to my own post, or anything.  But.

Another interesting thing.

bgp.he.net reports show that AS133955 is/was also announcing 69.172.127.0/24  
"WiMore S.r.l.".  bgp.he.net shows a red key icon on that origination, meaning 
that there’s an RPKI ROA that does not match that origination.  And bgp.he.net 
reports an RADP route object with a proxy registration for AS133955 to 
originate 69.172.127.0/24, registered on 9/25 like the three prefixes below.  

RADB still reports that route object (along with a very old one)

route: 69.172.127.0/24
descr: Fleg Asia Telecom Ltd
Proxy-registered route object
origin: AS133955
notify: ipbb-a...@aptg.com.tw
mnt-by: MAINT-AS17709
changed: kiay...@aptg.com.tw 20170925 #00:31:36Z
source: RADB

route: 69.172.64.0/18
descr: Canaca-Com Inc
descr: 1650 Dundas Street East Unit 203
descr: Mississauga, Ontario
descr: CA
origin: AS33139
mnt-by: MNT-CANAC
changed: peer...@canaca.com 20100624
source: ARIN

stats.ripe.net shows 69.172.127.0/24 is presently being announced - "Originated 
by: AS133955 (valid route object in RADB)”, "100% visible (by 157 of 157 RIS 
full peers)"

The RPKI says that AS34526 (WiMore S.r.l.) is authorized to originate 
69.172.96.0/19.  But the aggregate prefix is not being announced.  If the 
AS133955 origination is valid, they really ought to update their ROA.

Hm. I am curious about that prefix.  Is it being hijacked?  Or am I just 
reading everything wrong?

—Sandy

> On Oct 4, 2017, at 1:45 PM, Sandra Murphy  wrote:
> 
> 
>> On Oct 4, 2017, at 11:29 AM, Theodore Baschak  wrote:
>> 
>> I noticed when I looked into both of these leaks 3 hours after Clinton's
>> message yesterday that I couldn't see them in any of the looking glasses I
>> was looking in (including the NLNOG looking glass)
>> 
>> Looks like things were able to be cleaned up very quickly.
> 
> Interesting.
> 
> bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24.  
> I don’t know what their refresh cycle is.
> 
> And, oh look, bgp.he.net points to an RADB proxy registration for the 
> AS133955 origination.  RADB no longer reports that route object.  But it must 
> have been there at some point.
> 
> RADB
> route:  64.68.207.0/24
> 
> descr:  Fleg Asia Telecom Ltd
>Proxy-registered route object
> origin: AS133955
> notify: ipbb-a...@aptg.com.tw
> mnt-by: MAINT-AS17709
> changed:kiay...@aptg.com.tw 20170830  #05:45:57Z
> source: RADB
> 
> stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been 
> originated by AS133955 off and on for the last month (since the RADB route 
> object’s change date?) in the BGP Update Activity and Routing History graphs. 
>  And a huge flurry of activity yesterday.
> 
> Could I be reading all this wrong?  Seems to have been going on for quite a 
> while.
> 
> —Sandy
> 
> P.S.  The other three prefixes mentioned below show similar results in 
> bgp.he.net, with route objects proxy registered on 9/25, and similar results 
> in stats.ripe.net, with off-and-on announcements, more off than on for these, 
> closely timed with the route object registration. 
> 
> 
>> 
>> 
>> 
>> Theodore Baschak - AS395089 - Hextet Systems
>> https://bgp.guru/ - https://hextet.net/
>> http://mbix.ca/ - http://mbnog.ca/
>> 
>> 
>> 
>> 
>> On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work  wrote:
>> 
>>> TELUS AS852 has three address blocks hijacked by AS133955 as well.   We
>>> have not been able to get in contact with AS24155.  It looks like they
>>> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505.
>>> 
>>> 68.182.255.0/24
>>> 74.49.255.0/24
>>> 96.1.255.0/24
>>> 
>>> 
>>> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote:
 
 as133955 is broadcasting bogus BGP announcement for our netblock
 64.68.207.0/24
 
 It's in China, and we're trying to contact as24155 but they are also in
 China and we're just emailing their whois record address.
 
 If you're nearby and in a position to block/dampen that might be helpful.
 
 Thx
 
 - mark
 
 --
 Mark Jeftovic 
 Founder & CEO, easyDNS Technologies Inc.
 http://www.easyDNS.com
 
 
>>> 

Re: Contact at Proofpoint?

[John Morrissey]

On Tue, Oct 03, 2017 at 05:19:12PM -0400, John Morrissey wrote:
> Anyone have a clueful contact at Proofpoint?

Think we're all set on this. Thanks, everyone.

-john

Re: BGP hijack: 64.68.207.0/24 from as133955

[Sandra Murphy]

> On Oct 4, 2017, at 11:29 AM, Theodore Baschak  wrote:
> 
> I noticed when I looked into both of these leaks 3 hours after Clinton's
> message yesterday that I couldn't see them in any of the looking glasses I
> was looking in (including the NLNOG looking glass)
> 
> Looks like things were able to be cleaned up very quickly.

Interesting.

bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24.  I 
don’t know what their refresh cycle is.

And, oh look, bgp.he.net points to an RADB proxy registration for the AS133955 
origination.  RADB no longer reports that route object.  But it must have been 
there at some point.

RADB
route:  64.68.207.0/24

descr:  Fleg Asia Telecom Ltd
Proxy-registered route object
origin: AS133955
notify: ipbb-a...@aptg.com.tw
mnt-by: MAINT-AS17709
changed:kiay...@aptg.com.tw 20170830  #05:45:57Z
source: RADB

stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been originated 
by AS133955 off and on for the last month (since the RADB route object’s change 
date?) in the BGP Update Activity and Routing History graphs.  And a huge 
flurry of activity yesterday.

Could I be reading all this wrong?  Seems to have been going on for quite a 
while.

—Sandy

P.S.  The other three prefixes mentioned below show similar results in 
bgp.he.net, with route objects proxy registered on 9/25, and similar results in 
stats.ripe.net, with off-and-on announcements, more off than on for these, 
closely timed with the route object registration. 


> 
> 
> 
> Theodore Baschak - AS395089 - Hextet Systems
> https://bgp.guru/ - https://hextet.net/
> http://mbix.ca/ - http://mbnog.ca/
> 
> 
> 
> 
> On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work  wrote:
> 
>> TELUS AS852 has three address blocks hijacked by AS133955 as well.   We
>> have not been able to get in contact with AS24155.  It looks like they
>> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505.
>> 
>> 68.182.255.0/24
>> 74.49.255.0/24
>> 96.1.255.0/24
>> 
>> 
>> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote:
>>> 
>>> as133955 is broadcasting bogus BGP announcement for our netblock
>>> 64.68.207.0/24
>>> 
>>> It's in China, and we're trying to contact as24155 but they are also in
>>> China and we're just emailing their whois record address.
>>> 
>>> If you're nearby and in a position to block/dampen that might be helpful.
>>> 
>>> Thx
>>> 
>>> - mark
>>> 
>>> --
>>> Mark Jeftovic 
>>> Founder & CEO, easyDNS Technologies Inc.
>>> http://www.easyDNS.com
>>> 
>>> 
>> 

Re: BGP hijack: 64.68.207.0/24 from as133955

[Theodore Baschak]

I noticed when I looked into both of these leaks 3 hours after Clinton's
message yesterday that I couldn't see them in any of the looking glasses I
was looking in (including the NLNOG looking glass)

Looks like things were able to be cleaned up very quickly.



Theodore Baschak - AS395089 - Hextet Systems
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/




On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work  wrote:

> TELUS AS852 has three address blocks hijacked by AS133955 as well.   We
> have not been able to get in contact with AS24155.  It looks like they
> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505.
>
> 68.182.255.0/24
> 74.49.255.0/24
> 96.1.255.0/24
>
>
> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote:
> >
> > as133955 is broadcasting bogus BGP announcement for our netblock
> > 64.68.207.0/24
> >
> > It's in China, and we're trying to contact as24155 but they are also in
> > China and we're just emailing their whois record address.
> >
> > If you're nearby and in a position to block/dampen that might be helpful.
> >
> > Thx
> >
> > - mark
> >
> > --
> > Mark Jeftovic 
> > Founder & CEO, easyDNS Technologies Inc.
> > http://www.easyDNS.com
> >
> >
>

Re: Contact at Proofpoint?

[Jaren Angerbauer]

Replied off list.

--Jaren



On Tue, Oct 3, 2017 at 5:19 PM, John Morrissey  wrote:

> Anyone have a clueful contact at Proofpoint?
>
> One of our e-mail domains is being blackholed by their products, and
> we're striking out via normal channels.
>
> -john
>

Contact at Proofpoint?

[John Morrissey]

Anyone have a clueful contact at Proofpoint?

One of our e-mail domains is being blackholed by their products, and
we're striking out via normal channels.

-john