none
Developing a connector - The pickup directory and the 'To' header RRS feed

  • Question

  • I'm building a simple connector that will generate and save MIME messages to the Exchange 2007/2010 transport pickup directory.

    This works perfectly fine when the messages to be delivered have a MIME 'To:' header that matches the RCPT TO envelope address. However it fails when there's a difference.

    I see there exists software available (like GFI MailEssentials) that has a POP3 connector that puts files into the Pickup directory. It can be configured to send mail to a different address than the one seen in the 'To:' header, yet the original value is maintained from the POP3 server to my Outlook inbox, so clearly MailEssentials is not simply replacing the To header (I tried out when you do, you end up with data-loss if it's an internal address, as you've got the original value of the field; and if it's an external address than Exchange routes it to the External connector and it never lands in the right inbox).

    However I'm not able to intercept MailEssential's *.eml files in time to see the headers they use, and when I disable the Exchange services I don't see any files left uncollected in the directory. But I digress...

    How do I craft *.eml files to be placed in the Pickup directory such that the actual recipient does not necessarily match the MIME 'To:' header?

    Thanks.

    Monday, January 10, 2011 2:07 AM

All replies

  • You need to use X-Receiver and x-sender which will represent the P1 headers in for items in the pickup directory if you have a read of http://technet.microsoft.com/en-us/library/bb124230.aspx this explains how these fields are interpreted by the server.

    cheers
    Glen 

    Monday, January 10, 2011 4:37 AM
  • Thanks for the info. I originally passed over the Replay directory, not thinking it was appropriate for me, but I guess it is.

    Nonetheless, I can't get it to work. I followed all the rules (X-Sender and X-Receiver both at the very beginning of the *.eml file with valid addresses) but whatever I put into the Replay directory gets renamed *.bad and nothing happens.

    I tried the sample test email message described in that article, but even that gets rejected as badmail. I copied it exactly, but made the following changes to it:

    X-Receiver: <david@domain.local> NOTIFY=NEVER ORcpt=david@domain.local
    X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345AB
    Subject: Optional message subject
    
    This is the body of the message.
    I changed the X-Receiver address and removed the auth= parameter from X-Sender.

    The email address "david@domain.local" does exist, it's a proxy address on my Exchange mailbox (not my primary address).

    I checked the System Event Log and set the Transport Logs to Verbose, but I can't see anything that explains why the message was rejected.

    Tuesday, January 11, 2011 2:34 AM
  • I would suggest you try it without the extra envelope fields what your submitting isn't valid anyway and they aren't needed eg just use

    X-Receiver: <david@domain.local>  
    X-Sender: <bob@fabrikam.com>   

    And that should work okay

    Cheers
    Glen

    Tuesday, January 11, 2011 5:40 AM
  • I would suggest you try it without the extra envelope fields what your submitting isn't valid anyway and they aren't needed eg just use

    X-Receiver: <david@domain.local>  
    X-Sender: <bob@fabrikam.com>   

    And that should work okay

    Cheers
    Glen

    Yes, that worked. But interestingly I had some messages that went through, others were read in by Exchange, but were never delivered, nor was any message logged anywhere. The only difference between the messages that were sent and those that weren't was the Message-Id header.

    Does Exchange do anything special with this header? For example, if two messages are deposited in the Replay folder with the same content and Message-Id does it treat it as a duplicate and ignore it?

    Friday, January 14, 2011 12:00 AM
  • What may have happened is that the message you tried generated a NDR you should be able to tell this by looking at the message tracking logs on the server to see if a NDR was generated.

    Cheers
    Glen

    Friday, January 14, 2011 2:10 AM