> One thing that is interesting is that the message generates two BCC > copies with the *same* recipient address:
This is *only* the case with mails that later get deferred. Messages that are sucessfully sent to the appliance that archives the mails are only logged once, with the status "sent" obviously. The recipients address in this and all other cases is always the appliances address (maildepot@mailappliance.local) . The "real" recipients never appear as a duplicate. > Perhaps the appliance mishandles messages with duplicate recipient addresses? Could you please specify what you mean? > Is there any correlation between messages that repeatedly fail and messages > that have a duplicate recipient? Is the same feature observed in successful > archive deliveries? There is no correlation I am able to see yet, I guess that I have to take a more detailed look at the logfiles. But the behaviour sometimes is erratic, when I send two mails for test purposes, to the same recipient, one mail gets deferred and the other is archived just fine. The issue affects both incoming and outgoing messages, with both single and multiple recipients. A pattern or a link between these mails still needs to be found (and deducted from the logs) > Note also that for this to be a meaningful mail archive, you should lose the > original envelope recipient addresses (which happens with always_bcc) and > instead use a recipe based on "recipient_bcc_maps" with regular expression > mappings that capture each unique recipient as a unique archive recipient > address. I did already state this in the original post: I followed the instructions that the manufacturer of the appliance states on its website 1) Modify the transport_maps and include "mailarchive.local smtp:[192.168.1.30]:1025" - adapted of course 2) In the master.cf include "always_bcc = maildepot@mailarchive.local" Rehash, reload, add options to the main.cf if not already present and everything should be set and working fine - according to the manufacturer of the appliance. I already had contact to the company of the software as well, they just stated that no issues are know regarding this matter. (They got similar logs from me). As I could already rule out the filters and the MTU being an issue, there root cause apparently must be hidden elsewhere. I will continue searching for the link that connects the mails being duplicated and thus not sent. Regards, Niclas ________________________________________ Von: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org]" im Auftrag von "Viktor Dukhovni [postfix-us...@dukhovni.org] Gesendet: Montag, 5. Februar 2018 21:16 An: Postfix users Betreff: [MASSMAIL]Re: Duplicate mails in mailq / always_bcc > On Feb 5, 2018, at 3:00 PM, Niclas Rautenhaus > <rautenh...@team-datentechnik.de> wrote: > > I did not change anything that I am not able to revert back to it's original > settings. > I am not "blindly trying random changes" but implementing suggestions being > made in this > thread and / or I found elsewhere online when I searched for keywords like > "postfix", > "always_bcc", "content_filter" etc. Sadly, none of those things are immediately plausible work-arounds or get you closer to isolating the problem. At this time just collect sufficient logs and network captures to distinguish between the failure and success cases. > For the sake of keeping this mail readable, please refer to this link > (https://pastebin.com/nUz5BEdB) , there you will find an excerpt of the > maillog from two mails stuck in the queue. One thing that is interesting is that the message generates two BCC copies with the *same* recipient address: Feb 5 17:28:51 mail postfix/smtp[22771]: 363BD601EE: to=<maildepot@mailappliance.local>, relay=192.168.1.23[192.168.1.23]:1025, delay=0.1, delays=0.01/0/0.04/0.04, dsn=4.4.2, status=deferred (lost connection with 192.168.1.23[192.168.1.23] while sending end of data -- message may be sent more than once) Feb 5 17:28:51 mail postfix/smtp[22771]: 363BD601EE: to=<maildepot@mailappliance.local>, relay=192.168.1.23[192.168.1.23]:1025, delay=0.1, delays=0.01/0/0.04/0.04, dsn=4.4.2, status=deferred (lost connection with 192.168.1.23[192.168.1.23] while sending end of data -- message may be sent more than once) Feb 5 17:28:52 mail postfix/smtp[22773]: 363BD601EE: to=<user@external_domain.tld>, relay=smtp.ext-hoster.tld[XX.XXX.XXX.XXX]:25, delay=1.1, delays=0.01/0/0.24/0.8, dsn=2.0.0, status=sent (250 2.0.0 queued as V03a1fu15GSpL0R) Perhaps the appliance mishandles messages with duplicate recipient addresses? Is there any correlation between messages that repeatedly fail and messages that have a duplicate recipient? Is the same feature observed in successful archive deliveries? Note also that for this to be a meaningful mail archive, you should lose the original envelope recipient addresses (which happens with always_bcc) and instead use a recipe based on "recipient_bcc_maps" with regular expression mappings that capture each unique recipient as a unique archive recipient address. -- Viktor.
