MDaemon日志报错:550 aa@*.com must check for new mail first

最近在smtp入的日志看到一个报错,跟大家分享一下。截取了其中一段日志,报错信息如下:

该vin..的用户使用bis绑定了自己的企业邮局。发送邮件是报错550 vin*@*.cn  check for new mail first,这个意思是说请检查一下是否有新邮件。看到这个报错解释,就应该立刻想到mdaemon的用户验证方式里有一个pop先于smtp验证,这种验证方式用简单的语言表达就是:在发送邮件之前,先要进行收邮件,默认有效时间是5分钟。取消这个具体操作:安全---安全设置---pop先于smtp---取消勾选 本地发件人必须能访问邮箱于,默认是5分钟。请见下面截图:

换句话说,也可以通过收邮件来解决此问题,也不是必须取消掉该验证方式。

本文出自 “邮件服务器及网络管理笔记” 博客,请务必保留此出处http://19281928.blog.51cto.com/2327194/669096

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/Servers/Mail/

时间: 2025-01-21 09:01:06

MDaemon日志报错:550 aa@*.com must check for new mail first的相关文章

storm配置后启动nimbus后查看日志报错

问题描述 storm配置后启动nimbus后查看日志报错 [WARN] Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect java.net.NoRouteToHostException: 没有到主机的路由 at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_45]

nginx日志报错:ngnix:[notice] 30499#0: signal process started

问题描述 nginx日志报错:ngnix:[notice] 30499#0: signal process started 前台页面显示:500 Internal Server Error,在nginx日志报的错:ngnix:[notice] 30499#0: signal process started,这是什么问题的错误呢. 解决方案 查看access.log中,nginx怎么处理的

hadoop datanode日志报错

问题描述 hadoop datanode日志报错 2016-04-10 11:35:08,998 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: IOException in offerService java.io.EOFException: End of File Exception between local host is: "master/10.13.6.186"; destination host is: &quo

程序运行就闪退,log日志报错如下,求大神支招

问题描述 程序运行就闪退,log日志报错如下,求大神支招 05-24 18:28:21.920 32733-32733/com.example.administrator.myapplication W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0x415ebc38) 解决方案 这信息也太少了... 解决方案二: 0.0,稍等 05-24 18:35:47.070 843-1911/? W/Temper

阿里云大数据利器Maxcompute学习之--数据同步任务常见日志报错总结

在使用大数据开发套件时最常用的就是数据同步模块,工单里最常见的问题就是其中数据同步的问题,这里总结一些常见一些从Maxcompute到其他数据源的同步任务报错案例,主要是日志中出现数据回滚写入的问题.   那首先看下日志中数据回滚的原因,当数据写入rds或者hybridDB等一些支持事务的数据库中,数据批量写入,一旦由于各种原因没有写入成功,这个批次的数据会回滚重新写入,如果再次写入失败,就会报脏数据的错误导致任务失败.数据写入失败可能是以下原因导致回滚.1,脏数据(数据值超过数据类型最大范围,

大数据开发套件中数据同步-日志报错回滚信息的一些问题总结

在使用大数据开发套件时最常用的就是数据同步模块,工单里最常见的问题就是其中数据同步的问题,这里总结一些常见一些从MaxCompute(原名ODPS)到其他数据源的同步任务报错案例,主要是日志中出现数据回滚写入的问题. 那首先看下日志中数据回滚的原因,当数据写入rds或者hybridDB等一些支持事务的数据库中,数据批量写入,一旦由于各种原因没有写入成功,这个批次的数据会回滚重新写入,如果再次写入失败,就会报脏数据的错误导致任务失败.数据写入失败可能是以下原因导致回滚.1,脏数据(数据值超过数据类

MQ6.0发送消息时对方总是丢消息,日志报错。但是用笔记本与服务器直连,MQ正常。

问题描述 浪潮服务器的03系统,在用MQ6.0发送消息时对方总是丢消息,日志报错.但是用笔记本与服务器直连,MQ正常.日志报:数据发送到主机220.21.11.33的错误,在将数据通过TCP/IP发送到220.21.11.33时发生错误.其原因可能是通信故障,TCP/IP(send)调用的返回码是10054X('2746').记录这些值并通知系统管理员 解决方案 解决方案二: 底层网络不通排查防火墙设置timeout解决方案三: 还有就是回退阀值解决方案四: 网络问题核实网络吧解决方案五: 防火

oracle 11.2.0.1告警日志报错ORA-03137与绑定变量窥探BUG9703463

2017年12月份第二次oracle数据库巡检中,发现某一地市oracle数据库发现SQL语句触发特定版本BUG,详细信息如下: 操作系统版本:windows server 2008R2数据库版本:oracle 11.2.0.1问题描述:2017年12月份第二次巡检中,发现告警日志报错,报错信息如下:19/12/2017 08:27:35 Tue Dec 19 08:27:35 2017 ORA-03137: TTC 协议内部错误: [12333] [6] [50] [48] [] [] []

Linux 日志报错 xxx blocked for more than 120 seconds

        监控作业发现一台服务器(Red Hat Enterprise Linux Server release 5.7)从凌晨1:32开始,有一小段时间无法响应,数据库也连接不上,后面又正常了.早上检查了监听日志,并没有发现错误信息.但是检查告警日志,发现有下面错误信息: Thread 1 advanced to log sequence 19749 (LGWR switch)   Current log# 2 seq# 19749 mem# 0: /u01/oradata/epps/r