Whenever you decide to use a Mail Adapter Sender Channel to pump data from the oustside world into XI, you should probably worry a little about spam, a so diffused Internet plague. There are a lot of dedicated software to accomplish this task (try googlin' "anti spam software" and you'll see). Indeed the suggested method here is a very basic spam protection, neither it is that real smart and sharp idea, just a suggestion.
You can apply this technique if you are on a XI box with SPS that supports Dynamic Configuration.
On the other hand, the awful limitation is that an email message header can be easily faked, so that you may receive an email message from a sender claiming to be someone else: in fact one of the most used spam method is to randomly choose sender adresses (so that anti-spam software won't have easy life by simply putting a sender address in a black list, for instance), plus smart scrambling of subject and email body.
There's really no secure method to be sure of "who is sending what", except using PGP (Pretty Good Privacy) perhaps. I have developed an Adapter Engine module to perform PGP encryption and decryption, but this is another story. Contact me directly if you're interested in learning more on this topic.
Next, we need to play with the Receiver Determination. Let's assume the receiver is only one: an SAP ECC system (data provided by our partner via email will be then mapped, for instance, against an IDoc or ABAP Proxy). In this case you wouldn't need any Condition, and that's just here where we need to operate.
Talking about strategy, I would like messages that won't pass the check not to be restartable, so check the "End Message Processing Without Error" radio button (but this is really up to you).
Open the Condition Editor for your receiver.
Choose the left operand with the Search Help from the Context Objects category. This will open a popup. The attributes we can work on are in the http://sap.com/xi/XI/System/Mail namespace, and starts with "S" (those starting with "T" are relevant in a Receiver Channel).
Now I would populate the conditions as follows: with the above said assumptions, you know whom the mail is coming from, and you can agree on fixed subject, so that a list (in OR) of possible senders/subjects (in AND) can be populated.
And, that's it. Only those sender/subject combination will go inside XI for the rest of the process to take place, while junk mail will stop.
Feel free to play with other relevant attributes in the same way (it depends on your scenario).
Of course, if you have kinda content conversion in the mail adapter sender channel, and you receive some funny "Viagra" email messages without an attachment (or with an attachment that doesn't fit what you expect), the message will hang in the Adapter Engine, and won't even reach these checks described here.
But, you know, we're never on the safe side enough. 🙂
A different and more effective approach would be to code a custom Adapter Engine module for the sender channel that would make this checks "just on the real source", but this can be another episode, maybe.
You can apply this technique if you are on a XI box with SPS that supports Dynamic Configuration.
Assumption and Limitations
The basic assumption is that sender email adresses are known. To furtherly strengthen the protection, you'll probably want to agree on a fixed email subject with your partners outside.On the other hand, the awful limitation is that an email message header can be easily faked, so that you may receive an email message from a sender claiming to be someone else: in fact one of the most used spam method is to randomly choose sender adresses (so that anti-spam software won't have easy life by simply putting a sender address in a black list, for instance), plus smart scrambling of subject and email body.
There's really no secure method to be sure of "who is sending what", except using PGP (Pretty Good Privacy) perhaps. I have developed an Adapter Engine module to perform PGP encryption and decryption, but this is another story. Contact me directly if you're interested in learning more on this topic.
In practice
First of all, on the mail sender channel (the one that will periodically poll a POP3 or IMAP4 mailbox) you need to check the "Set Adapter-Specific Message Attributes" flag, and probably the "Variable Transport Binding" flag as well (this shouldn't be mandatory, but my experience and my memory suggest me that it's better to flag it too, and won't hurt anyway). This will force XI to populate the Dynamic Configuration Soap Header section of the XI message with the relevant data taken from the mail message header. Next, we need to play with the Receiver Determination. Let's assume the receiver is only one: an SAP ECC system (data provided by our partner via email will be then mapped, for instance, against an IDoc or ABAP Proxy). In this case you wouldn't need any Condition, and that's just here where we need to operate.
Talking about strategy, I would like messages that won't pass the check not to be restartable, so check the "End Message Processing Without Error" radio button (but this is really up to you).
Open the Condition Editor for your receiver.
Choose the left operand with the Search Help from the Context Objects category. This will open a popup. The attributes we can work on are in the http://sap.com/xi/XI/System/Mail namespace, and starts with "S" (those starting with "T" are relevant in a Receiver Channel).
Now I would populate the conditions as follows: with the above said assumptions, you know whom the mail is coming from, and you can agree on fixed subject, so that a list (in OR) of possible senders/subjects (in AND) can be populated.
And, that's it. Only those sender/subject combination will go inside XI for the rest of the process to take place, while junk mail will stop.
Feel free to play with other relevant attributes in the same way (it depends on your scenario).
Of course, if you have kinda content conversion in the mail adapter sender channel, and you receive some funny "Viagra" email messages without an attachment (or with an attachment that doesn't fit what you expect), the message will hang in the Adapter Engine, and won't even reach these checks described here.
But, you know, we're never on the safe side enough. 🙂
A different and more effective approach would be to code a custom Adapter Engine module for the sender channel that would make this checks "just on the real source", but this can be another episode, maybe.
7 Comments
