Troubleshooting
Problem
This document explains how to configure an existing local OS/400 mail user so that SMTP mail is automatically forwarded to a new address.
Resolving The Problem
This document explains how to configure an existing local OS/400 mail user so that SMTP mail is automatically forwarded to a new address. Included is a detailed example of creating the necessary System Distribution Directory (SDD) entry that forwards mail to a new domain or local address. The forwarding function will work with mail sent from almost any source including:
|
o | OfficeVision/400 or JustMail locally or from any other SNADS server |
| o | A local POP3 client |
| o | Any SMTP/MIME capable server on the Internet or intranet |
| o | A Lotus Domino user using the SMTP/MIME MTA |
| o | OfficeVision/400 or JustMail locally or any remote SNADS server |
| o | A local POP3 client |
| o | Any SMTP/MIME capable server on the Internet or intranet |
| o | A Lotus Domino user using the Domino STMP/MIME MTA |
Mail sent to the olduserid@domain mail address is switched to the newuserid@domain and forwarded because of the preferred address of a SDD user defined field name FORWARDING. The forwarding function also works with mail addressed to the old user ID/address using system naming convention (OLD ADDR).
Instructions
Do the following:
| 1. | Use the following command to define two user-defined fields in the SDD. On the OS/400 command line, type the following: CHGSYSDIRA USRDFNFLD((FORWARDING *NONE *ADD *ADDRESS 256) + (FWDSRVLVL *NONE *ADD *MSFSRVLVL 1)) Press the Enter key. Perform this step only one time per iSeries 400 or AS/400 system. The fields are defined from then on. If you normally save the SDD as part of a regular backup and recovery plan be sure to save the SDD again after you add the user-defined fields. |
| 2. | Use the following command for each user whose mail is to be forwarded to some new address. In this example, the old send-to address is OLD ADDR for userid address naming or the SMTP/MIME address of olduserid@domain (associated with OLD ADDR by the system alias table or the SMTP/MIME address in the SDD entry). The mail is sent to newuserid@domain which is the new forwarding address. If the new SMTP address is associated with the same OS/400 user profile on the local system (for example, you changed your SMTP address and want to receive mail for both addresses) , you may also wish to modify the User Profile field and the System Name/Group field. See Additional Considerations below. CHGDIRE USRID(OLD ADDR) + USRDFNFLD((FORWARDING *NONE newuserid@domain)) + MSFSRVLVL(FWDSRVLVL *NONE) + PREFADR(FORWARDING *NONE ATMIME) Note: On some older systems such as R320, the preferred address of MIME must be used in place of ATMIME. |
| 3. | To check the entry use the command DSPDIRE USRID(OLD ADDR), and press F20 = Display User-Defined Fields. |
| Caution: Do not forward to your own (OLD) address. There is no test for circular forwarding - Directory entry A forwards to B that forwards back to A (even indirectly). If this is done, the result is an addressing loop. QMSF jobs will stay very busy forwarding to an address that forwards to an address that forwards to (you get the idea). The QMSF job will do little else on that system except loop and use CPU. |
Additional Considerations
| o | There is no restriction on how many old addresses might be forwarded (from the same system or many different systems) to the same new address. |
| o | This forwarding implementation does not (and cannot) use the old (R310) Office Vision to SMTP bridge (QSMTPQ support) once the SDD has been altered to perform forwarding. Use context switching to perform OV/400 SMTP addressing instead of a distribution queue. |
| o | It does not matter if you have performed the conversion of the SMTP alias table into the system distribution directory (SDD). This has no affect on the forwarding function. |
| o | Mail can still be sent from the old address (OLD ADDR) with OfficeVision/400 or from a POP3 user defined by the SDD entry with the olduserid@domain. As long as the user is still enrolled in OfficeVision/400 or is a valid local POP3 user, changing to route to a forwarding address just means that no mail would be returned to the old e-mail location. |
| o | You are not required to always define the new forwarding address (newuserid@domain) in the system alias table or otherwise in the SDD of the forwarding system. However, there are exceptions. You will need an entry for the new address in the SDD/system alias table when: 1. The new forwarding address represents a user that is local to the same forwarding system (as in the case where mail sent to an old address is forwarded to another POP3 user on the same system). 2. The user at a new address is now a remote user; they send mail to Office Vision/400 users on the old system; and they want the reply to function to work correctly. Further details on each of these two cases are provided below. 1. Forwarding to a new address on the same system. Two SDD entries, one for the old address and one for the new address. It is possible to have two (or more) SDD entries for the same user. However, only one of them can be the real entry that contains their user profile, system name, and so on. The forwarding or old SDD entry would typically be used as the false entry. It exists only as a kind of placeholder for the old or alias address. It effectively points the alias SMTP address to the new or true SMTP address. You do not need any user profile in this entry, in fact you really do not want one as it exists only to forward mail to some other address. You will have to use a fake system name so this entry can be added/changed in the SDD. Example: You are an OS/400 POP3 user and would like to change your e-mail address from VeryLongName_Smith@as400A.ibm.com to vsmith@as400A.ibm.com. You want mail sent to the old address (VeryLongName_Smith@AS400A.ibm.com) to be forwarded to the new address for the first few months after the change. In this case, you would first want to change the existing SDD entries SMTP alias to the new SMTP address. Use the command WRKDIRE and then take option 2=Change to modify your existing SDD entry. Now press F19=Change name for SMTP and change the existing entry to the new SMTP alias (vsmith@AS400A.ibm.com). Press the enter key once to exit the screen and a second time to confirm/exit. Now make a second fake entry for the old address. ADDDIRE USRID(VSMITH FAKESYS) USRD('old smtp address entry for smith') + SYSNAME(FAKESYS) NETUSRID('VSMITH FAKESYS') + USRDFNFLD((FORWARDING *NONE vsmith@AS400A.ibm.com)) + MSFSRVLVL(FWDSRVLVL *NONE) PREFADR(FORWARDING *NONE ATMIME) Use WRKDIRE and use Option 2=Change to modify the new entry. Press F19=Change name for SMTP and then press enter when prompted to create a new entry. Type the old address (VeryLongName_Smith@AS400A.ibm.com) and press enter twice to save and exit. When you decide to delete the old address completely, just delete the SDD entry for FAKESYS system. |
| 2. The second case where a SDD entry for the new user might be needed involves how the from address will appear when the new forwarded user (on a remote system) sends mail to an Office Vision/400 user on the old system. When the new user sends mail, there is a new return address on it. This is fine for POP (and Domino for AS/400) users but OV/400 user cannot directly reply to a SMTP address if there is no SDD entry associated with it. This problem is not unique to forwarding, it is a consideration for any OV/400 user receiving remote SMTP mail. Example I previously had an entry in the SDD on a system called RCHAS400 that was GJROMANO RCHAS400 and that mapped to gjromano@rchas400.ibm.com. Now I move to another system, NEWSYS, and my new SMTP address is gjr@newsys.bim.com. I know how to find my old SDD entry on RCHAS400 and using the forwarding instructions, set up my old SDD entry on RCHAS400 to always forward mail sent to gjromano@rchas400.ibm.com to my new address gjr@newsys.ibm.com. This works fine. So now someone on RCHAS400 sends some mail to me from OV/400 using GJROMANO RCHAS400. It gets to my new user address on NEWSYS just fine. And then I reply BACK to that OV/400 user. The return address on my reply is gjr@newsys.ibm.com and is not gjromano@rchas400.ibm.com. Unless someone added a brand new entry in the SDD that turned gjr@newsys.ibm.com into say GJROMANO NEWSYS or had auto registration turned on, there is not a SDD entry on RCHAS400 that defines what OV UserID Address to match up with my new return address. The return UserID Address that appears on the OV message will end up with something like GJR NEWSYS or something which looks okay but is not in the SDD of RCHAS400. An OV user that gets this message is not able to reply using the reply key. If they attempt to reply to this address they receive an error when OV/400 performs address verification. For the reply function to work correctly, the local user must make a new SDD entry for my new mail address, type in the new SMTP address (using the OV/400 SMTP addressing feature), or enable auto registration. | |
| o | If Object Distribution messages (SNDNETF, SNDNETMSG, and SNDNETSPLF) are sent to the local, forwarded address (OLD ADDR) from any other SNADS system (such as another iSeries 400 or AS/400), they are not forwarded to the new address. Instead, they will be delivered to the local user as configured in the SDD entry. Object Distribution messages are only forwarded to remote users via SNADS routing when the SDD entry routes mail to another system due to the system name in the SDD. If you used the technique described above to remove the userid field and change the system name, the message will not be delivered. |
| o | Do not confuse the new user-defined forwarding field with the field shown below: |
| Change Directory Entry User ID/Address . . . . : USER14 SYSTEMA Type changes, press Enter. Building . . . . . . . Office . . . . . . . . Mailing address . . . . Forward from user identifier: Do not use this field User ID/Address . . . More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F18=Display location details F19=Change name for SMTP F20=Specify user-defined fields F24=More keys |
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]
Historical Number
533286549
Was this topic helpful?
Document Information
Modified date:
11 November 2019
UID
nas8N1012796