Greetings, Encountered some issues during the night with three FreeBSD servers I have running. They all generate automatic system emails during the night and these emails are all sent to one mailing list on one of the servers. The mail system on the receiving side is using the latests courier from FreeBSD ports which is courier 0.65.3 and the mail list is handled by couriermlm.
The email last night seemed to contain something odd as the email generated on the receiving server together with the one from one of the other servers was rejected by couriermlm like this: Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: This message looks like an administrative request. The address Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: <mailto:[REMOVED]> is NOT Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: for administrative requests. This is the posting address for Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: the mailing list itself. For additional help, write to Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: <mailto:[REMOVED]>. To reach Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: the mailing list administrator, write to Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>: <mailto:[REMOVED]>. Jun 6 03:29:24 [REMOVED] courierlocal: id=[REMOVED],from=<[REMOVED]>,addr=<[REMOVED]>,status: failure I'm guessing the above means that a bounce is generated and in our setup, that bounce would be sent to the very same mailing list that generated this error and if the bounce contains the original message that would be an infinite loop. I can see in the maillog that this error occurs three times in a row for the email generated on the local machine. The first has the correct from address while the second has a empty from address and the third has #@[] set as from address. All this happens within one second and I see no trace of it after that and the mail queue is empty. The second server (running qmail) encountered the same error but just once and then got a backscatter error like this: Jun 6 03:46:48 [REMOVED] courieresmtp: id=[REMOVED],from=<>,addr=<[REMOVED]>: 250 Backscatter bounce dropped. Jun 6 03:46:48 [REMOVED] courieresmtp: id=[REMOVED],from=<>,addr=<[REMOVED]>,success: delivered: backscatter bounce dropped Jun 6 03:46:48 [REMOVED] courieresmtp: id=[REMOVED],from=<>,addr=<[REMOVED]>,status: success On the sender side (qmail) it looks as if the message was delivered successfully. The third server (running courier) however encountered the problem with 556 Address unavailable, like this: Jun 6 04:05:29 [REMOVED] courieresmtpd: error,relay=[REMOVED],from=<[REMOVED]>,to=<[REMOVED]>: 556 Address unavailable. Jun 6 04:05:29 [REMOVED] courieresmtpd: error,relay=[REMOVED],msg="502 ESMTP command error",cmd: DATA Just like the local errors on the reciever server I see three attempts here too and I see all three attempts on both sender and receiver side. First attempt that gets a 556 has the correct from address, second attempt has an empty from address and also gets a 556, the third has the #@[] from address and that one gets a 517 Syntax error and thats the end of it. I've been looking at logs on both sides and I can find no reason for the 556 error. I get why the local delivery and the delivery from the second server fail as it could enter an infinite loop but the 556 I cannot understand. We've tried to reproduce the error without success. Mail to the list worked before this error and has for months and now works again without any change to configuration. Also, the empty and the #@[] from addresses I see, is that intended or have we missed something in our configuration? Regards, Andréas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
