我们陷入了一个相当困难的境地。 Masterhost的技术支持员工拒绝满足客户的请求，即通过个人帐户发布请求的邮件日志文件。 我们不知道该怎么办...
问题的实质是：一段时间以前，在线商店的用户开始抱怨来自其中一个站点的邮件停止了（订单确认等通过php脚本在站点上实现的服务）。 一项小型调查显示，问题仅在箱子的所有者身上发现了……@ mail.ru
我们找到了一个准备好解决问题的人，而他要做的唯一工作就是来自托管者的邮件日志。 并且我们在Masterhost上托管（似乎您已经可以写“托管”）。 出乎意料的是这是一个问题...
一切开始都很好。 在致电技术支持并详细说明问题之后，该员工强烈承诺-我们将毫无问题地发布您需要的日志，而您唯一需要做的就是通过控制面板发送授权请求。 立即完成（在13:30）。
答案还没到一个小时就到了，但是没有一个承诺的日志文件，而是一个问题，信的地址没有到。 “好吧，很明显，那个人在向我们发送日志文件之前，决定设法解决它。”我感激地说道，并报告了发现问题的地址之一。
再过一个小时的等待，但在收到的信中，再也没有日志。 取而代之的是，有一条声明说一切正常，并附上了梦log以求的日志文件中的一行，以确认今天存在一个事实，即该地址收到了Masterhost服务器的来信。 是的，来自另一个域……我不得不（隐藏一点烦恼）再次说明它来自一个域，而不是来自另一个域……，我们需要一个日志文件，该日志文件是我们在应用程序中编写的！ 跟着，他们说申请已经结束了！！！
下一封信我们等待了2.5个小时。 您认为其中有日志吗？ 不，他们不在那里了。 但是还有几行确认来自问题域的几个字母。 到了这个时候（这发生在星期五），答应解决这个问题的程序员提到了紧迫的事情，并写着：“继续玩你的玩具，他们在星期五在家里等我，”他离开了：（我们并没有输希望他们仍然将日志发送给我们，继续通信。
我们又等了2个小时才得到下一个答案。 墙上的时钟敲响了19:00，当下一个答案来了……又一次没有请求的日志文件！ 在这封信中，五个小时前开始我们无休止对话并要求指出特定文件的人，这次是对发现问题的特定时间感兴趣。 那些留在办公室的人已经沸腾了。 :)为了最终停止这种愚蠢行为，我们再次致电Masterhost，有礼貌的员工答应（事实证明他也撒谎）他会在机票上记下我们不需要通信，而是一个日志文件，并将其发送到最近的位置。时间。 同时，我们的程序员已经大声咒骂，在膝盖上收集了一份测试表格，并在mail.ru上注册了一个新帐户，这样即使是有关该问题的潜在问题也会从那个不让我们周末离开的年轻人那里消失了。 然后，我们天真地想，他将有怜悯之心，并且将这个他妈的日志文件全部发送给我们！
- 在20:21，我们收到了一封简短的信，其中包含以下建议：（您已经收到日志，这已经很明显了）：“您的信已经到达并落入了SPAM文件夹，出于什么原因-请与mail.ru联系”
...，实际上，在创建的邮箱中，有三位来自Masterhost的小伙子的来信：
进一步的通信似乎毫无意义。
我们现在坐在那里，正在考虑在这种情况下该怎么办？ 实际上，没有太多选择：
也许Masterhost的适当雇员之一会阅读此主题，并通过私人信件将2017年5月12日的邮件日志文件发送给票证[masterhost.ru＃：30122215776]中指定的联系地址。 我保证匿名。
也许有人与Masterhost的理智员工有联系，因为那里有100％的普通人。 如果不困难，请在PM中放弃您的联系人。
可以等到班次变化并尝试从另一个更理智的“专家”那里请求日志吗？
- 还是利用周末搬到其他托管服务提供商？
UPD：恰好在提交我们的请求后的一天，日志文件已发布！ 在第二天的13:20，我们已经没有任何重复的请求，收到一封信，指示我们可以在指定的日期提取请求的转储。 即 昨天全天为我们服务的员工从一开始就了解我们的需求，但出于某种原因，决定“与我们一起玩”。 显然，Masterhost TP上有满足客户应用程序条款的说明，应用程序截止日期为24小时。 因此，通过在2017年5月12日13:30提交申请，我们在2017年5月13日13:20收到了所要求的文件。 我真诚地希望相信这是一个雇员的暴政，而不是公司管理层的政策。
UPD2：结果，此情况已解决如下：
- 通过站点脚本将我们的邮件中的“返回路径”字段更改为我们的邮箱后，收到的第一个字母是来自mail.ru的垃圾，我们将其发送到mail.ru支持服务进行调查。 4天后，他们简短回答，说问题已解决，请检查。 而且的确，通过mail（）函数发送的信件开始出现。
- 同时，由于评论者对此主题的评论，我们重新通过SMTP masterhost从站点发送邮件。 有帮助！ 信件也开始到达。
- 答案来自领导层，其本质如下（我引用）：“是的，虽然确实应该立即宣布答案，但确实延迟了申请的处理。” 信中还提到，该事件的详细信息已发送给对该情况感兴趣的一些人。 顺便说一句有用的生活技巧！ 您网站上的信息只能通过授权的请求获得，而在他人的请求中则可以（仅通过写给管理层的信）获得。
- 在通信过程中，我们互动的另一个细节被揭示。 令人惊讶的是，从听众的反应来看，人们更关心的不是延长一天的最简单服务的事实（打开文件，选择三打行，Ctrl + C，Ctrl + V，发送给客户端），而是测试主机的电子邮件标头的文本。 最后，我设法弄清了原因。 :)事实证明，经过7个小时的询问，从日志中摘录后，我们的程序员为masterhost员工制定了一个测试脚本，他以粗鲁的形式表达了对该员工职业水平的看法。 在那之后，这个“专家”只是……得罪了！ 我衷心为程序员的低压力性表示歉意，并准备向公司管理层确认主持人您的员工的话：“他首先开始……”-绝对公平！