8bolt
New Contributor II
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Inbound e-mail delay
Hi Coleen, thanks for your reply. I've been tied up away from this project but will still try to get you all the data you've requested and do some better testing. I want to rule out Wider's observation that the Cox mail partner 'might' be holding me because my test send location was a Yahoo mail server, already listed negatively. more as soon as I can .... 8bolt0Views0likes0CommentsRe: Call Recipients Receiving Multiple Calls from ME After We Connect
Hi Michael, Do all 3 of your CO lines allow outward calls? You might be able to test if the Panasonic, for whatever reason doesn't think the first call succeeded, and after some sort of timing interval chose to try calling out on another line. This assumes that the Panasonic 'rolls' that way. If it's possible, perhaps you could test with one of your sympathetic callees ,after temporairly disconnecting two of the co lines? This is a stumper, and I cannot think of any NETWORK based reason for a second call to sent to the callee. On the other hand, I suppose anything's possible on the Network side, but I'm at a loss to think of any valid reason. The only other clue to help isolate the cause is if your co lines identify by unique numbers, and the callees see two different numbers when called, suggesting that he Panasonic is seizing the second line and re-calling. If the SAME number appears, and you don't have them Optioned to identify by the same number, then I'd suspect the network. Good hunting!!0Views1like1CommentTechnical characteristics of TA derived Phone lines
I need to find out if Cox has any published standards regarding their Company Provided TA devices, and how they are supposed to behave, with regard to basic D.C. Telephony services. Does Cox comply with the Bellcore G.R.s regarding things like on-hook timing for flash, leakage across T-R for determining on-hook vs off conditions. Here are my reasons why I need this information: 1. Off-the shelf Uniden wireless phones are constantly keeping line siezed on hangup, causing High & Wet conditions, or failure to provide Dial tone on next off hook. The only remedy to date is to break the D.C. Path between the TA and the base unit for the phones. This NEVER occurred on a 5E-hosted Dialtone line at 18KF from C.O. 2. Off hook duration for 3W-calling or SW-Flash for call waiting, more often than not causes the TA to lock-up, sending 120 IPM Dial Tone to me, or tears down the call in progress, forcing us to try and start all over. I've lost count of the times I've bid for Dialtone, only to hear Silent Batt, or 120 IPM, then gone thru the open-pair drill before it will clear. 3. Calls to National 800 number companies with IVRs will fail, with no ability to get into the company's directory or menu choices, because the IVR is receiving some sort of voice primitive, or tone or impluse noise that prevents me from instructing it, when I am NOT SENDING ANY TONE OR VOICE through the call session. The Same IVR will work as expected from any Cell phone or C.O. based origination in the same area. For this trouble, I need tier 2 or 3 support to prove the trouble either towards the IVR sponsor ( NOT likely since this symptom is occurring on Companies all over the U.S., therefore at different distances [echo return variances, and possibly +|- .5 DB level variances]) or towards your network or the default level settings in the TA or the head end with regard to how your network converts Analog voice and background noise before sending it towards the called IVR. Ideally I would like towork with the tech who has No-Test capability and a "GOD's eye" view of the network and stable path through it so he or she can hear for themselves what I am putting up with. The most recent & frustrating site for me has been the national U.S.P.S. call center at 1-800-275-8777. Before the first choice offers are even completed, the IVR halts and returns "I didn't understand that input" the re-starts the menu choices over again, never to be satisfied. I eventually have to bail out from the call.Re: Robo calls out of control
Hi Karen, I agree with others that this is an industry problem, and the industry - not just cox- has failed to help address it. Why not implement "white listing"- That is, allow me to build a list of acceptable numbers that I agree to accept without further inbound screening. Part of the reason we live with this scourge is the telcos who terminate VOIP( where the scammers generate their calls from) to DDD calls get paid for every call regardless whether it is terminated or not. This takes away the incentive to force presenters of calls to the DDD users that each and every call is valid and proveable back to a legitimate Billing Tel #, regardless of whatever BS the caller wants to put in the callee's Caller ID device. You give me that and watch how fast these scumbags dissapear from the game; They don't provide you with valid call data, they don't get to complete andyou don't incur as much cost | engineering overhead attempting to complete bogus calls, against the loss of completion revenue. This validation is trivially easy to implement via the AIN/CCS network already in place, and used for caller-ID. The other idea is to offer a DMZ like call treatment that gives a caller, not otherwise tainted "the benefit of the doubt". Prove you are a legit caller to me, and get sent to voice-mail, or allowed through - at MY discretion. No mo robo is a cool valid solution, but does not satisfy all the issues, nor is it able to support traditional DDD users who's providers cannot implement simultaneous ring capability.0Views1like0CommentsRe: Inbound e-mail delay
Hi Colleen, Here's the "whole story" with appropriate areas munged.... I'm hopeful you can pattern on any of the message_IDs still left here in the clear, else I can PM you. Pls advise.... Thanks, 8bolt Delivered-To: g***********ail.com Received: by 2002:a17:90a:326a:0:0:0:0 with SMTP id k97-v6csp1790268pjb; Mon, 14 May 2018 06:30:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZruG5D7dKCeL2NYtMCaDYdyvtKgAm91oYz0zmol+7o/DlreoJWPociU/nYt3W+BSwZG9e0t X-Received: by 2002:a9d:11f1:: with SMTP id y46-v6mr7722347oty.286.1526304656175; Mon, 14 May 2018 06:30:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526304656; cv=none; d=google.com; s=arc-20160816; b=kAfcSMlEfpWwZnB6T3nHJZYbsQzbU5A/3zhYn8GxkXWQYme5QKiGM+KSoc2ogw5vtH kJ37ejS7ePZOb2ywXhPa06HEhnpQGUvsvsvLPaDMiaq3xu0JkweYq/HhKKydESsRLk2J 1f/GVP6q0qhLojcU1z7FqhehdPhkhqlXgFRTyDjU3Hs54bM4rsge7jl1NEWt0B8s5JKl mp4rXz5qfOO6Y3zr18kn97bGrAr3ZOAboQWtP+aws1hObho7mxBUoaOkc/7U2NAxu1Jj JyMotkw6ie38KMnqTEWOtoAjJ/G1G2BkD8QN7sqqReCkibFHTfSjEhGo2YK4a4bruvRV KXaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:content-transfer-encoding:mime-version:subject:to :reply-to:from:date:dkim-signature:delivered-to:message-id :message-id:arc-authentication-results; bh=6R8ZYyI8Ryuqroi5QwtRMLkO2uaPhlt9syC4bRaqFAM=; b=yKJOgecH8BDBW/Df3r55ChKTJYaGmPyTGWjXkflCDMVNbhKyp/cB9B4VNOMnb4d4CZ EPS9scOWLczXwrIv5alERZZiSZO0/FNR237ExYuYIBEKSr4r+ptIE6av1o6JauhBtmB5 1YheN9v0u4fXQyu6FoDfHspA/2scqYhoP7f8UoeuR8YiTOI2Dt53CSWI+BIz9kP4Wrwp pOp4bb8LQChcNcQqCcCGrlCLgRrZRMV+RUCDyCVRC+whr7okzwNgRz00lVcW/nB7aW3P 75vX49s6TlZKEXAICLsVnE8Y3wf+H06QVSRn34ScQBTq2oN2zKKTdTtYR7Tm1zbYqWza R9uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=m18QjWZ+; spf=neutral (google.com: 68.230.241.216 is neither permitted nor denied by domain of azpost58@yahoo.com) smtp.mailfrom=azpost58@yahoo.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yahoo.com Return-Path: <a***********om> Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net. [68.230.241.216]) by mx.google.com with ESMTP id e30-v6si3437645otc.4.2018.05.14.06.30.55 for <g************om>; Mon, 14 May 2018 06:30:56 -0700 (PDT) Received-SPF: neutral (google.com: 68.230.241.216 is neither permitted nor denied by domain of azpost58@yahoo.com) client-ip=68.230.241.216; Authentication-Results: mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=m18QjWZ+; spf=neutral (google.com: 68.230.241.216 is neither permitted nor denied by domain of azpost58@yahoo.com) smtp.mailfrom=azpost58@yahoo.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yahoo.com Message-ID: <501958615.940580.1526303719792@mail.yahoo.com> Message-ID: <5af98f90.1c69fb81.4f42a.04deSMTPIN_ADDED_BROKEN@mx.google.com> X-Google-Original-Message-ID: <mDKL1x01s3mCCp601DKMYz> Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo201.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180514133055.RUVG1466.eastrmfepo201.cox.net@eastrmimpo110.cox.net> for <g**********gmail.com>; Mon, 14 May 2018 09:30:55 -0400 Received: from cox.rs.oxcs.net ([146.20.112.67]) by eastrmimpo110.cox.net with cox id mDWv1x00N1TJ2zW01DWvkK; Mon, 14 May 2018 09:30:55 -0400 X-Authority-Analysis: v=2.2 cv=YPnv8VOx c=1 sm=1 tr=0 a=IN5e7ORV7WapKVHgxEPmgA==:117 a=ylJUl8t0XBMA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=mxjmbrwEMGcA:10 a=VUJBJC2UJ8kA:10 a=4YQPKlbQ4VIA:10 a=gvEpj-ScY2wA:10 a=dsDnT69CCvkA:10 a=HzKupFY-tgkQth6VA5kA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from imap-backend-63.dovecot.iad.rs.oxcs.net (imap-backend-63.dovecot.iad.rs.oxcs.net [10.12.4.63]) by mx.cox.rs.oxcs.net (Postfix) with ESMTP id 36214119B489 for <g*********il.com>; Mon, 14 May 2018 13:30:55 +0000 (UTC) X-Sieve: Pigeonhole Sieve 0.4.devel (404c208) X-Sieve-Redirected-From: 3@******** Delivered-To: 3@******* received: from imap-director-2.dovecot.iad.rs.oxcs.net ([10.12.2.9]) by imap-backend-63.dovecot.iad.rs.oxcs.net with LMTP id WBrZCY+P+VojFwAA+uxsgg for <3@******; Mon, 14 May 2018 13:30:55 +0000 Received: from mx.cox.rs.oxcs.net ([10.12.2.9]) by imap-director-2.dovecot.iad.rs.oxcs.net with LMTP id 0G6kCI+P+Vq5FgAAI4j0GA ; Mon, 14 May 2018 13:30:55 +0000 Received: from eastrmimpi112.cox.net (unknown [68.230.240.52]) by mx.cox.rs.oxcs.net (Postfix) with ESMTP id 40l1WG4hjdz1DvXJ for <g*******cox.net>; Mon, 14 May 2018 13:19:22 +0000 (UTC) Received: from sonic303-48.consmr.mail.ne1.yahoo.com ([66.163.188.174]) by eastrmimpi112.cox.net with cox id mDKL1x01s3mCCp601DKMYz; Mon, 14 May 2018 09:19:21 -0400 X-Authority-Analysis: v=2.2 cv=X5giECbe c=1 sm=1 tr=0 a=Tw/DI8y6L6HZCs/9Y5OoYw==:117 a=ylJUl8t0XBMA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=mxjmbrwEMGcA:10 a=VUJBJC2UJ8kA:10 a=dsDnT69CCvkA:10 a=HzKupFY-tgkQth6VA5kA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0.00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1526303960; bh=6R8ZYyI8Ryuqroi5QwtRMLkO2uaPhlt9syC4bRaqFAM=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=m18QjWZ+QKO7f1o8dia1+xVxavy9MgVfPz4MXWa/gms/f7gY54E6qDcMRSxNuuKCP+NguHhtq5ZFzh7DK3xJl6PHouoZSw4qP0SB6z9D/UnwRb6epoSXEaHwxwOcgqrU/tvOVn/rQcLtgsqks/LiefHEBhvOYgYLTvJzjAmv8Rx6YwKLLC0OYppPXXHgA6n9AfDSiJhVzbU1COU1pju/9fCaMw/79ZoB9xtRtrXvdWtoBFL7zHlTrbKVO6kUg0/j5rqjLuCEGqm4zxfcoOsRFPWX33GHgVuFfh/8D4jh7pUTFCBkeMDuPstZ9/NdIS9l3Ut+BriD+ng4+KlAZkVzLA== X-YMail-OSG: yhFLdwMVM1mA4n76TGqK.auD5069IIjo5DtNkitK7m_JaKbYPHAgsTTu6SU4ipK yuKYq3A9vN2nFyeNU1x_bSZJSUmEedUADQJ6JPsIAOxiyjoSZAJYsG5yCWtR19vnXdB4MwvAzJGg 72rqSaN6ZTxwmVi_WCkZgPNbpDul8yU33Y5uFW3jW7DJ1U2.o75xRZ03w8pA7WpHZMBKcinp4ilR PrciAQopyEJNqXC6QHhdVhh_sXB6g3a.YRh4SOCP7YylwIjESzE0Jk7cLTZSDhxDQPwCE3xy_AL9 pUue.CuuKXKzlA_UexVwMG7uD25gDb40rY6K01nhs2id2YB.sCOg.kxewKwTbrvFT2.yVIoqRm1D rsosdN6K.9UwSMUMth93928pVCWgc8Ir.KjsLyDdwAGJH.oVgN1Fe2bSnjucA7XZUjesh1EFho3m 6Z21nO8L9x2_ZIfRNINbAV9Vta.ZZ93AhA55DU3jZbYWpZWUQUKVHn2Zd5q.1iCS44paRrHtpFNj qJHcpKyvcjnULMppoOMDLOQ3Xqpd9JpPH0J8bzEOqepQMqJj.DxgEyvuJDET.vCoFNrR0k4S_2D8 r64cU5UJHfPLW_mg2Y.KeYmTtv.NsBY0TO.qtrT2bWymAeoPYKJ37m5j6XpWXp.FRNjG.Ov5iYZ6 SkQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 14 May 2018 13:19:20 +0000 Date: Mon, 14 May 2018 13:15:19 +0000 (UTC) From: P*******************com> Reply-To: P*****************hoo.com> To: <g***********et> Subject: TEST-2-b MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <501958615.940580.1526303719792.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11871 YahooMailBasic Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 checking delay in real time leaving YAHOO @ 06:15:17 Calib to USNO TYCHO MSTR CLK0Views0likes2CommentsLinux Compatability
Dear Cox: Given that you claim to support contour on MAC OS-X desktops, and Android, why do you fail to support it on, at least the top-5, ports of Linux. Worse than that, The advertising media on the homepages of the website say: "anyone with internet, and the appropriate level of TV service, can watch programming online." Well, sorry, but that is not the case with Linux users. After clicking the button at the bottom of this page.... https://www.cox.com/residential/tv/watch-tv-online.html?campcode=resaccount_tools_tv-online Here's what we get in our face: https://watchtv.cox.com/upgrade " Your System isn'tcompatible with Contour" If you are not going to support Linux, can you please consider making your advertising / web site claims accurate? Many Thanks7.4KViews0likes0CommentsInbound e-mail delay
Good Mornintg. I am new to Cox services, and am seeking information relative to processes that cause e-mail delays inbound. My quest is to understand if this circumstance is something I must accept and adapt to for all emails. Specifically the Following: Received: from imap-backend-63.dovecot.iad.rs.oxcs.net (imap-backend-63.dovecot.iad.rs.oxcs.net [10.12.4.63]) by mx.cox.rs.oxcs.net (Postfix) with ESMTP id 36214119B489 for <g*******l.com>; Mon, 14 May 2018 13:30:55 +0000 (UTC) X-Sieve: Pigeonhole Sieve 0.4.devel (404c208) X-Sieve-Redirected-From: 3@6***** Delivered-To: 3@6***** Received: from imap-director-2.dovecot.iad.rs.oxcs.net ([10.12.2.9]) by imap-backend-63.dovecot.iad.rs.oxcs.net with LMTP id WBrZCY+P+VojFwAA+uxsgg for <3@6*****3>; Mon, 14 May 2018 13:30:55 +0000 Received: from mx.cox.rs.oxcs.net ([10.12.2.9]) by imap-director-2.dovecot.iad.rs.oxcs.net with LMTP id 0G6kCI+P+Vq5FgAAI4j0GA ; Mon, 14 May 2018 13:30:55 +0000 <<<< DELAY BETWEEN INTERNAL HOSTS >>>>> Received: from eastrmimpi112.cox.net (unknown [68.230.240.52]) by mx.cox.rs.oxcs.net (Postfix) with ESMTP id 40l1WG4hjdz1DvXJ for <g*********et>; Mon, 14 May 2018 13:19:22 +0000 (UTC) Received: from sonic303-48.consmr.mail.ne1.yahoo.com ([66.163.188.174]) by eastrmimpi112.cox.net with cox id mDKL1x01s3mCCp601DKMYz; Mon, 14 May 2018 09:19:21 -0400 Which clearly illustrates the delay between 2 internal cox_labeled servers. Is this the 'normal way' cox rolls, delay_wise? Many Thanks8.5KViews0likes4Comments