Sending and Receiving Internet E-mail Using RFC

[Former Member]

Hi Experts,

Do any one have any Idea to Send and Receive Internet E-mail through RFC?

Regards,

Seshadri

[Former Member · Accepted solution]

Hi Seshadri,

I think so this may satisfy your requirement.

Sending and Receiving Internet Mail with R/3

Each release of R/3 adds a little more refinement to the email functions.

You can send and receive attachments, use LDAP for address lookups, and embed URLs in the body of a message that will launch an external browser when clicked.

Granted, SAPoffice is still not the most advanced mail client, but if you’re going to use it you might as well exploit some of the newer features.

This column will complement the online help in describing the available email options and underlying mechanics of sending and receiving Internet mail.

We’ll explain how the email jigsaw puzzle fits together as well as the more complex mail configurations.

Whether you’re new to the topic of email or a seasoned veteran, there should be plenty of conceptual and technical depth to appease you.

As usual, our test system was an Alpha running Digital Unix 4.0E. We used release 4.5B with sendmail; BOB is the SID of our system. (We have also run through this configuration with release 40B, and the process was exactly the same.)

CONCEPTS, PROGRAMS, AND ACRONYMS

Before we begin, we thought it would be helpful to present a list of programs and acronyms that we’ll use throughout the article:

• Mail transfer agents (MTAs) are responsible for rewriting address information and routing messages between different machines and networks. sendmail, smail, qmail, and Microsoft Exchange Server are MTAs.

• Mail user agents (MUAs) are programs used to read, reply to, and compose mail. Netscape’s Messenger, Microsoft’s Outlook and Outlook Express, pine, mutt, and mail are MUAs.

• Local delivery agents (LDAs) — which can be components of MTAs or standalone — are responsible for final message delivery to a user’s mailbox. For example, sendmail for RedHat Linux comes configured to use procmail as the LDA. In this configuration, sendmail would accept the message on behalf of our domain and hand it off to procmail for final delivery.

• Domain name system (DNS) is a distributed database responsible for resolving symbolic hostnames into IP addresses. An entry in the DNS database contains records that have specific information about a particular host. For example, a host might contain an address (A) record that specifies the host IP address, or a canonical name (CNAME) record. (CNAME records are host aliases.) Optionally, a host entry can contain a mail exchanger (MX) record, which specifies the hostname that either processes or forwards mail on behalf of that host.

• Simple mail transfer protocol (SMTP) is a server-to-server protocol for delivering email. Sendmail uses this protocol when communicating with other MTAs.

• Lightweight directory access protocol (LDAP) is a lightweight version of the directory access protocol (DAP), which is part of the X.500 standard for directory services in a network. LDAP enables individuals to locate organizations, individuals, files, and devices in a network, whether it’s private or on the Internet.

• mlunxsnd passes outbound mail from the R/3 System to an MTA such as sendmail.

• mlsomail accepts inbound mail from an MTA and delivers it to the R/3 System. mlsomail is SAP’s LDA.

• mlsomadm generates the configuration file (usually named <SID>_mailconfig) needed by both inbound (mlsomail) and outbound (mlunxsnd) Internet mail processes. This file contains information about the R/3 mail user, the R/3 gateway, and sendmail.

• Three-letter acronym (TLA) is important to know because we’ll be overusing them so often in this article.

INTERNET MAIL SERVICES

Several options are available when it comes to connecting R/3 to Internet-related mail services. We’ll discuss sendmail because we’re Unix fans. sendmail is also available for Windows NT through Sendmail Inc., which acquired the NT sendmail port from MetaInfo. In case you’re not a sendmail proponent, the SAP Exchange Connector — which was designed for use with Microsoft’s Exchange Server — is another option. Along with the connectors for sendmail and Exchange, SAP offers some other interesting mail integration tools:

• Mlsopop3 is a post office protocol (POP) server that allows you to retrieve your SAPoffice mail using a POP3-compliant MUA such as Messenger, Outlook Express, and mutt.

• SAP MAPI Service Provider is a MAPI interface that lets you retrieve your SAPoffice mail and access workflow items using a MAPI-compliant MUA such as Outlook.

• SAP LDAP Gateway is a client and server for accessing LDAP services from within SAP. The LDAP gateway also lets you export address information from the R/3 System to an LDAP server.

CONFIGURATION

We’ve organized the configuration setup into two parts (operating system and R/3) and outlined the high-level steps. For more detailed information, refer to the R/3 online documentation.

OS-level configuration settings

1. Create the saprfc.ini file in your /sapmnt/SID/exe directory. This step is optional because you can pass the relevant parameters by hand or in a script. For more detailed information, refer to the R/3 online documentation.

2. Create the <SID>_mailconfig file with the mlsomadm program.

3. Add the mlunxsnd program to your SAP Start profile so it automatically starts and registers with the R/3 gateway.

4. Add the Msap mailer and rules in Ruleset 0 to your sendmail.cf. This step allows sendmail to rewrite mail addresses and hand the message off to the mlsomail program for delivery in to the R/3 System.

R/3-level configuration settings

1. Create the R/3 CPIC user for the mlsomail program. When an inbound message is delivered, mlsomail logs on to the system as this user in order to deliver the message (via RFC). This user is created like any other (transaction SU01), although the User Type is set to CPIC and should be assigned security profile S_A.SCON. In our system, we’ve named this user MLSOMAIL_RFC.

2. Using SM59, create the R/3 RFC destination that calls mlunxsnd.

3. Add an Internet node to the SAPconnect configuration by using transaction SCOT. This step links the SAPconnect Internet node with the RFC destination created in step 2 (transaction SCOT -> View -> Node).

4. Schedule the SAPconnect job RSCONN01. This job is responsible for processing queued outbound mail (transaction SCOT -> View ->Jobs).

5. Maintain Internet mail addresses for your R/3 users by updating the appropriate user master record and maintaining an Internet address for that user.

If you plan to have sendmail running on another machine that’s not one of your R/3 instances, you will either need to allow rsh on that machine (not a great idea in our opinion) or install a standalone gateway.

SENDMAIL

sendmail is an MTA responsible for delivering and routing email among different machines and networks. The machines don’t need to be the same architecture nor do the networks need to be using the same protocol. This power comes with a price, however, because configuring sendmail can be overwhelming and complex. (For more detailed information on sendmail, please see the book by O’Reilly and Associates mentioned in the References section at the end of the column.)

If the MTA concept isn’t clear, here’s an analogy: sendmail is like the local post office. The post office has the responsibility of seeing that your letter either gets delivered directly to your mailbox or is forwarded to the proper local post office so that it can complete the delivery. This is analogous to routing email between machines on a similar computer network speaking the same protocol. What if the letter is addressed to a foreign country? Delivery would be similar to routing email between two different networks (for example, from TCP to UUCP).

Let’s assume the post office doesn’t open and read your letters. You might use a tool, such as a letter opener, to tear the seal on the envelope. You need a similar tool — an MUA — to read letters delivered to your electronic mailbox.

Internally, sendmail is straightforward: It selects the most appropriate program (or mailer) to deliver mail. In doing so, it rewrites both the sender and recipient addresses according to certain rules that ensure the address information is compliant to the receiving agent. The method or program used to deliver mail is called a Mailer. Mailers are defined in the sendmail configuration file and denoted by the letter M in the first column. For example:

Mlocal, P=/bin/mail, F=SlsDFMmnu, S=10, R=20, A=mail -r $f -d $u

Mprog, P=/bin/sh, F=lsDFM, S=10, R=20, A=sh -c $u

Mpop, P=/usr/lib/mh/spop, F=nsmFDM, S=10, R=20, A=pop $u

Msap, P=/sapmnt/BOB/exe/mlsoscpt, F=DFMPlLms, S=10, R=20, A=mlsomail

/sapmnt/BOB/exe/BOB_mailconfig $u

The Mailer definition has several options, all of which are described in the sendmail book; however, a few points are worth mentioning. The P flag specifies the Mailer program. The Msap mailer specifies /sapmnt/BOB/exe/mlsoscpt as the program. Actually, the program is a script that calls mlsomail. This script is optional but can be very helpful when it comes to debugging inbound mail because it lets you set a trace file and trace level for mlsomail. (See OSS Note 113932, which contains the mlsoscpt script.) If you choose not to use the script, simply use P=/sapmnt/<SID>/exe/mlsomail instead. In addition, the S and R flags specify additional Rulesets for address processing depending on whether the address is for the sender or recipient.

Rules are used to rewrite sender and recipient addresses as well as to select the appropriate mailer for delivery. Rules are specified in the configuration file by the letter R. Each rule potentially has three sections: the left-hand side (LHS), the right-hand side (RHS), and the comment, which is optional. If an address is matched according to the LHS expression, it is rewritten according to the RHS. The R/3-specific rules are:

1. pass SAPoffice mail to mlsomail

R$+<@bob.ambergroup.com> $#sap$:$1@bob.ambergroup.com

R$+<@bob> $#sap$:$1@bob.ambergroup.com

Rules are aggregated into Rulesets, which are specified in the configuration file by the letter S. Rulesets have well-defined numbers and specific purposes. Depending on whether an address is for the sender or recipient, it flows through the Rulesets in a well-defined manner. The flow of mail through the Rulesets is beyond the scope of this article; however, it is important to note that the function of Ruleset0 is to decide which mailer will handle delivery for the message recipient.

In sendmail, there is the concept of the Trusted User. Trusted Users are users who can call sendmail with the –f option. This option allows the caller to specify the “from” user, which would typically be the user who called the program. Because mlunxsnd will always be executed through the gateway, and therefore by user <sid>adm, <sid>adm needs to be Trusted in order to specify the proper sender in the R/3 System. Otherwise, all outbound email would be from user <sid>adm. Trusted users are defined with the T configuration option in the sendmail.cf file. Please see the following example:

1. Trusted users ###

Troot daemon uucp news bobadm

EXAMPLES

Now that we’ve inundated you with background information about the inbound and outbound mail architecture, we’ll present an in-depth discussion of both inbound and outbound mail processing. We’ll wrap up all the concepts we’ve discussed so far by presenting two imaginary examples of sending and receiving an email message.

Inbound Processing Example:

UserA at source.com wants to send an email to UserB at <SID>.destination.com, where <SID> is the SID of our R/3 systems. The goal is for this message to end up in the SAPoffice inbox of UserB. We use <SID>.destination.com instead of destination.com for a specific reason. We have Unix user accounts on this machine that receive email at UserName@destination. com. If we used this domain for our R/3 users, all mail bound for destination.com would end up inside the R/3 System (or as a failed attempt to do so). By using this naming convention, both Unix users and R/3 users can receive mail to the same machine. UserA@source.com composes the email and addresses it to UserB@<SID>.destination.com. The message envelope now contains UserA@source.com as the sender address and UserB@<SID>. destination.com as the recipient address.

The first thing that needs to happen is that source.com needs to know where to send mail for <SID>.destination.com. In order to determine this information, a DNS lookup occurs. As mentioned earlier, DNS records not only contain hostname and IP address information, commonly referred to as A records, but they also contain mail information called MX records. The MX record specifies where to send mail on behalf of a specific host. A host entry may have several MX records, and each MX entry has an associated priority. The following example shows a DNS entry that contains only MX records:

<SID>.destination.com MX 10 sap1.destination.com

MX 20 sap2.destination.com

The DNS lookup returns sap1.destination.com and sap2. destination.com as potential mail hosts for our electronic letter. Since sap1 has the higher priority, the first attempt at delivery will occur to sap1. Notice we don’t need to have an A or CNAME record for <SID>.destination.com because our MX record tells the MTA which host will deliver or forward mail on behalf of this host. OSS Note 71891 talks about this in some detail.

Once we hit the send button on our MUA, the letter is handed off to the local MTA. The local MTA then opens a connection to the destination MTA on sap1.destination.com. (This connection happens on TCP port 25, which is the port for SMTP.) Because our machines are running sendmail, it accepts the mail, determines the mailer, rewrites both sender and recipient addresses according to its rules, and finally passes the letter off to the program specified in the mailer. The program specified in the mailer will be mlsomail because this message’s destination is the R/3 System. Again, mlsomail is the program responsible for receiving mail from MTAs and making the inbound call to the R/3 gateway using remote function calls (RFCs).

The mlsomail program connects to the R/3 System through the gateway as the CPIC user MLSOMAIL_RFC. We created this user in the R/3 systems and specified it in the <SID>_mailconfig file we created with mlsomadm. Next, it calls the function module SX_OBJECT_RECEIVE, which is the SAPconnect function module for receiving inbound objects. SAPconnect takes the message from here and delivers the mail to the appropriate SAPoffice inbox.

SAPconnect understands that UserB@<SID>.destination.com corresponds to the R/3 user UserB because we’ve maintained UserB’s user master data and specified UserB@<SID>.destination. com as his or her Internet mail address.

Outbound Processing Example:

Now let’s consider what happens when UserB in the R/3 System wants to respond to the message from UserA. In SAP-office they’ll simply reply to the message and hit send. Let’s make sure we’ve got all of the components in place before we proceed:

• UserB must have an Internet mail address specified in his or her user master (transaction SU01 -> UserB -> Other Communication -> INT)

• SID_mailconfig file must have already been created using the mlsomadm program.

• mlunxsnd must be running and registered with the gateway. We wrote the following short script, /usr/sap/BOB/SYS/ exe/run/mlunxsnd.csh, to start it:

#!/usr/bin/csh

setenv GWCONFIG /usr/sap/BOB/SYS/exe/run/BOB_mailconfig

1. Sleep 30 seconds to allow the gateway to start before actually starting mlunxsnd

(sleep 30; /usr/sap/BOB/SYS/exe/run/mlunxsnd -t - ahostname.mlunxsnd.bob001 –ghostname -x sapgw00) &

We then added the following line to the bottom of our SAP start profile (in our case /sapmnt/BOB/profile/START_DVEBMGS00_ hostname) so that it starts every time we start our R/3 system:

Start_Program_05 = local $(DIR_EXECUTABLE)/mlunxsnd.csh

• An RFC destination (transaction SM59) must exist corresponding to the registered mlunxsnd program. We called our RFC destination SAP_INTERNET_GATEWAY_SERVER and configured it as follows:

Connection Type: T (for TCP/IP)

Activation Type: Registration

Program ID: hostname.mlunxsnd.bob001

Then we tested it using Test Connection to make sure it was communicating successfully.

• A configured Internet node in SAPconnect (transaction SCOT -> View -> System Status) must exist specifying the RFC Destination (SAP_INTERNET_GATEWAY_SERVER) we created in the previous step.

• We also need a SAPconnect Transmission Process job (transaction SCOT -> View -> Jobs) using the INT (Internet) Variant, which will actually send pending mail. We’ve scheduled ours to run every five minutes.

• Finally, we’ll need user <sid>adm to be a Trusted user listed in the sendmail.cf configuration file.

With all this in place, when UserB hits the send button responding to UserA’s message, UserB’s Internet address will get looked up from the user master and specified as the source address. At this point, the message will be queued.

The next time the SAPconnect Transmission Process runs, it will pass the message on to the RFC destination SAP_INTERNET_ GATEWAY_SERVER, which specifies the registered gateway program mlunxsnd. mlunxsnd will then pass the message on to sendmail with the –f flag specifying the source address as <R/3user> @<SID>.destination.com or in this example UserB@<SID>. destination.com. Once sendmail has the message, it routes it to the remote MTA at source.com, is responsible for getting the message to UserA.

I think so you enjoyed the content.

Regards,

Dhayanandh.S

[Former Member · Accepted solution]

Hi Dhayanandh,

Can we debug it?

If so How?

Regards,

Seshadri

[Former Member · Accepted solution]

Hi Seshadri,

Thank you for rewarding points.

here is some small nuts for debugging,

DEBUGGING

What can you do if your configuration isn’t working properly? You have several options depending on where you think the problem might be occurring. If you believe the problem is sendmail, then you can view the system mail logs with the tail –f command. To figure out where sendmail is appending its log information, take a look at your syslog.conf file. The line beginning with the word mail specifies the appropriate log file. It is also possible to increase or decrease the debugging information levels. For more information on this topic, please see the syslogd man pages.

It’s also possible to place sendmail in address test mode by passing it the –bt flag so you can see Rulesets at work. For example, you can tell sendmail to process an address through a particular Ruleset and return the value:

1. sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

> 3 userb@sid.destination.com

rewrite: ruleset 3 input: userb @ sid . destination . com

rewrite: ruleset 7 input: userb < @ sid . destination . com >

rewrite: ruleset 7 returns: userb < @ sid . destination . com >

rewrite: ruleset 3 returns: userb < @ sid . destination . com >

> ^D

If you’d like even more rule debugging information, specify the debug flag –d 21.12 while sendmail is in address test mode. This will display the match attempt for each rule in the Ruleset you specify. If a match succeeds, the resulting output is displayed on the screen.

Lastly, if you’re having difficulties getting mail into R/3 and you believe the problem is with mlsomail, you can use the mlsoscpt script (as mentioned in the inbound processing example) to create a trace file with debugging output.

Regards,

Dhayanandh.S

[former_member184619]

Hi Raj,

U can use the following RFC's to send the Internet mail through RFC

SO_NEW_DOCUMENT_SEND_API1 and

SO_NEW_DOCUMENT_ATT_SEND_AP to send an attachemnt in mail..

Go through documentation of these.

Sachin