Let me see if I can explain your entire email. Ensuring that email flows freely between our mail complex and other top mail provider complexes is a support issue correct. Actually setting up the system to monitor and to ensure the support people get the data they need is operations/engineering. We like automating a lot of our procedures as our mail complex isn't staffed 24/7. Right now we have a script that monitors incoming mail sent from probes across the us. It monitors how long it takes the email to first hit the IronPort's, then how long it takes to hit the Brightmail, then how long it takes to hit the MTA's. Our script uses pop3 to grab the email and parse the headers we send from the probes (or in this case from the complex to the pop accounts). Yes I do realize some are webmail (AOL, MSN, Gmail), but even a lot of the webmail providers do have pop3 servers. Our intent here is not not only verify that the email got there but that it got there in a reasonable time (lets face it email is becoming a more imporant part of life/business today). As fair as teaching the support guys to go look at the mail queue, would you honestly want them to be doing that? We have over 65 mail machines and should I trust them with checking them every 10 min? Since we are not staffed 24/7 what happeneds if we have all gone home? The way we have it setup if the mail never reaches the complex tier-1 gets a page, 15 minutes later if the problem still isn't solved tier-2 gets a page. I believe automating the system rather then trutsing a staff member to check it and to pray that it dosen't break during the night is a much better way of doing it. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mark Foster Sent: Tuesday, September 14, 2004 4:04 PM To: Hannigan, Martin Cc: nanog@merit.edu Subject: RE: Email Complexes I find it interesting that you'd like pop3 access to a bunch of listed *webmail* providers. Who provide access via the web - NOT pop3. I also agree with the below statement - your mail queues themselves will provide far more accurate information. The issue of 'successful mail delivery' would be a support issue, not an operations issue, as long as you as an operations staffer can verify that your mailserver is not holding the mail for undue periods. (Mail doesnt have a delivery SLA in general, after all.) And if your support staff need offsite mail accounts to verify delivery delay times, they should be able to purchase them or otherwise obtain them, and keep a database of mail account access details that they can use *on demand*. This would of course entail them becoming customers and footing the regular monthly bill, or whatever. In every ISP i've ever worked for, all we've needed to do is verify that we're delivering the mail to the advertised MX in a timely fashion, and our responsibility ends at that point. Outside of the usual responsibilities of a good ISP - like providing responsive abuse/security staff, like providing a valid abuse@ contact :-) This would be one of the primary reasons your mail doesn't get accepted, and prevention is better than cure... So in all honesty - if your company wants to extend its monitoring-ability outside of its own network to those of other providers, it should do so in the 'usual fashion' - sign up. How is this something that yourself as an operations employee got involved in anyway, as it strikes me as a support issue? - Mark. On Tue, 14 Sep 2004, Hannigan, Martin wrote:
Ross,
There are a lot of knowledgeable people on this list [tier 3].
Why can't you already tell if you aren't getting through to major providers? Wouldn't your queues backup, or are you being blocked and the messages are being rejected and you are trying to track that?
-M<
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Hosman, Ross Sent: Tuesday, September 14, 2004 2:41 PM To: 'paul@adelphiacom.net'; Roy Cc: nanog@merit.edu Subject: RE: Email Complexes
Your right this isn't my department and it's not my place to tell them how to do their job. If Roy would like to send me a valid abuse complaint I'll make sure to forward it on or even walk it over to the abuse department supervisor.
I would also like to say I'm suprised at how many people have been
me on/off the list for asking a simple question. I'm just trying to ensure people are able to recieve/send mail from/to charter's mail complex. I didn't think asking for some help would be a big deal (as I thought there might be some people on the list from the companies that were knowledgeable instead of having to deal with typical tier-1 support).
-----Original Message----- From: Paul Bradford [mailto:paul@adelphiacom.net] Sent: Tuesday, September 14, 2004 1:31 PM To: Roy Cc: Hosman, Ross; nanog@merit.edu Subject: RE: Email Complexes
Come on... what is this.... Ross doesn't have the ability to put more "clueful" people in abuse, he's prolly an engineer like you and me.... we just want to fix the network.... why take this e-mail as a chance to bash Charter?
Ease up, Paul
On Tue, 2004-09-14 at 14:01, Roy wrote:
I suggest you concentrate some resources in your abuse department. One charter IP address hit my firewall 1617 times so far today. Repeated complaints to abuse@charter.net just get ignored.
According to the local newspaper, my fellow citizens consider Charter
attacking the
worst company in town.
Roy
On 14 Sep 2004, at 17:39, Hosman, Ross wrote:
Ensuring that email flows freely between our mail complex and other top mail provider complexes is a support issue correct. Actually setting up the system to monitor and to ensure the support people get the data they need is operations/engineering.
If getting mail from your mail complex is important to remote mail complex A then talk to remote mail complex A and arrange something. If remote mail complex A doesn't care, or doesn't return your mail, then maybe mail complex A doesn't think your mail complex is worth worrying about (or perhaps you are sufficiently notable that it's worth blocking mail from you without generating bounce complexes). Unless your mail complex is sufficiently big that remote mail complex A's customers are going to care (i.e. generate support complex load above the noise floor) I wouldn't hold my breath complex waiting for anybody to expend effort to help you with any of this for free. There isn't really any solution complex you're going to magically find from the NANOG list complex beyond the suggestion complex that has already been put forward (that of purchasing standard retail pop3 mailbox complexes from the other provider complexes you're interested in, and running text complexes between them and your mail complex.) Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-09-15, at 00.48, Joe Abley wrote:
On 14 Sep 2004, at 17:39, Hosman, Ross wrote:
Ensuring that email flows freely between our mail complex and other top mail provider complexes is a support issue correct. Actually setting up the system to monitor and to ensure the support people get the data they need is operations/engineering.
If getting mail from your mail complex is important to remote mail complex A then talk to remote mail complex A and arrange something. If remote mail complex A doesn't care, or doesn't return your mail, then maybe mail complex A doesn't think your mail complex is worth worrying about (or perhaps you are sufficiently notable that it's worth blocking mail from you without generating bounce complexes).
Unless your mail complex is sufficiently big that remote mail complex A's customers are going to care (i.e. generate support complex load above the noise floor) I wouldn't hold my breath complex waiting for anybody to expend effort to help you with any of this for free.
There isn't really any solution complex you're going to magically find from the NANOG list complex beyond the suggestion complex that has already been put forward (that of purchasing standard retail pop3 mailbox complexes from the other provider complexes you're interested in, and running text complexes between them and your mail complex.)
This is just way to complex for me. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQUfrZaarNKXTPFCVEQJh+wCfVVIlMV9TNIKzz3UuzeAJuzupVSkAnjW5 KFEaZxXJ5j1y4iR/P/k8OvhW =Lg2S -----END PGP SIGNATURE-----
participants (3)
-
Hosman, Ross
-
Joe Abley
-
Kurt Erik Lindqvist