Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-2913

PerRecipientHeaders are not applied for RemoteDelivery




      Jerry Malcolm reported this on the DEV mailing list:

      I noticed in 3.3 that the SpamAssassin mailet changed to support different spamassassin results per recipient in a multi-recipient email.  I understand MailImpl's PerRecipientHeaders.  And I found MailDispatcher's addSpecificHeadersForRecipient(...) that adds the actual headers.  But it appears that MailDispatcher is outbound only.   The per-recipient spamassassin results are analyzed in IsMarkedAsSpam matcher.  No problems with any of that.
      Here's my issue... I am adding an option for debug purposes to store additional spamassassin output as headers.  I'm simply adding a few more entries in the PerRecipientHeaders object.  But it appears that the PerRecipientHeaders are not being converted to actual headers on inbound mail.  I figure that's reasonable since spamassassin mailet was the only code adding them, and the spam matcher handles it.  But if any other mailets (or in my case, additions to spamassassin mailet) add PerRecipientHeaders, they are lost.
      I know how to convert them to real headers. I can easily make the addition to the code. My concern is that I don't know when they should be added.  This is where it gets muddy for me.  Where in the flow (what class) does an inbound email get split into per-recipient instances?  Obviously, per-recipient headers need to get added 'per recipient/instance' (after the split).
      Can someone tell me the recommended class to add any 'per recipient' headers as real headers to an inbound email?  If my understanding is totally wrong, I'm up for some education as well... 

      Clearly, RemoteDelivery should set per-recipient headers before sending the email.

      While making that change, we should be carefull about outbound performance degradation this might incurs: mails that do not have per recipient headers SHOULD still be sent within a single SMTP transaction to avoid useless DATA duplication. (We can assume DATA will always be different for mails having custom headers).

      We need to write an integration test for this within "server/mailet/integration-tests".




            Unassigned Unassigned
            btellier Benoit Tellier
            0 Vote for this issue
            1 Start watching this issue