Also read these V7R1 SMTP changes from V7R1 memo to users
SMTP support for RFC 821 and RFC 822 removed
Starting in i 7.1, Simple Mail Transfer Protocol (SMTP) only supports RFC 2821 and 2822. RFC 2821/2822
deprecate many parts of the 821/822 e-mail standard. Behavior for smtp routes, smtp alias shadowing,
and processing mail through Mail Service Framework (msf) are not compatible with the RFC 2821 and
RFC 2822 standards, and should be used on an as is basis. The first part of a source route will still be
honored from RFC 821, other parts of the source route will not be contacted. The absolute address is the
recommended way to send e-mail. Read the RFC standards for more details.
SMTP changes for IPv6 support
IPv6 support was added in i 7.1. At this time, there is no IPv6 standard for real time black holes lists
(RBL). The RBL only works for IPv4 addresses. SMTP uses the API getaddrinfo() to look up e-mail DNS
records which does not guarantee the address will be looked up first as IPv6 then IPv4 which is different
from what Request for Comments (RFC) 3974 recommends. Parts of the DNS resolver were fixed in i 7.1
to be more correct. Some changed behavior might be noticed as a result.
MAILROUTER feature changes
This feature can be used either by using the Change SMTP attributes (CHGSMTPA) command parameter
MAILROUTER or through the IBM i Navigator SMTP server properties general tab under Mail router.
The MAILROUTER feature before i 7.1 would in some instances, forward all mail to the mail router even
if the e-mail address could be resolved. In i 7.1, MAILROUTER correctly forwards to the mail router only
when the e-mail address does not resolve.
The FWDMAILHUB feature was added in i 6.1 that allowed the forwarding of e-mail to a single address.
This feature can be used either by using the CHGSMTPA parameter FWDMAILHUB or through the IBM i
Navigator SMTP server properties general tab under Forwarding mailhub domain. FWDMAILHUB
always forwards the e-mail and does not attempt a resolve. MAILROUTER only supports A and AAAA
records, while FWDMAILHUB supports MX, CNAME, AAAA, and A.
For those customers that expect all e-mail to be forwarded to their mail router then copy the value of
MAILROUTER to FWDMAILHUB, and set MAILROUTER to *NONE as this is a mail hub. For those that
expect only e-mail that cannot be resolved to be forwarded to their mail router leave the configuration
as-is. Customers that want the SMTP server to resolve an address before forwarding to the mail hub,
must use MAILROUTER, as FWDMAILHUB does not resolve the address. Changing these values may
require a SMTP server restart.
The resolve path is now:
Chapter 4. Licensed programs 43
|
|
|
|
|
|
|
|
|
|
|
Forwarding Mail hub(if defined)->
Absolute Address/First part of source route->
mailrouter(if same domain)->
mailrouter(different domain) if FIREWALL(*YES).
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, December 18, 2013 7:02 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SNDDST not working after V7 upgrade
On 17-Dec-2013 13:11 -0800, fbocch2595@xxxxxxx wrote:
any info regarding SNDDST not working after upgrading to V7 from V6
and prior to that we sav21 and rst21 to the new iSeries at V6 then
upgraded to V7.
So, based on a sav21/rst21 I thought we had everything we needed on
the new iSeries for SNDDST
Was a /scratch install/ performed from the "sav21" media to effect the V6 "to the new iSeries", or was some other media used to install the
V6R1 on "the new iSeries"? If some other media was used, was the installation of the V6 *only* the LIC and the OS, or possibly were the QGPL and QUSRSYS features also installed? If the QUSRSYS had been installed before restoring from the "sav21", versus merely having been restored from the save option-21 [into an empty QUSRSYS per lack of it having been installed], then the restore option-21 would likely [if
ALWOBJDIF(*ALL) had been used] cause problems; even possibly, problems that might be manifest as described.
IIRC the ALWOBJDIF() used on the restore options from the GO SAVE menu was changed on v7r1 to use the special value *COMPATIBLE instead of the SpcVal *ALL to avoid the effects of renamed database files. Renamed database files in QUSRSYS would appear [on US English systems] with object TEXT starting with "Old name ". The restore option-21 presumably still uses ALWOBJDIF(*ALL) on v6r1.
Regarding the above "IIRC", seems possible [only as clear as mud; at least equivocal] that the v7r1 was changed to ALWOBJDIF(*COMPATIBLE), per the included change flags in the text snippet below:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarm/rzarmrst21.htm
_i Using restore menu options 21, 22, and 23 i_ "...
≤Start of change≥ ALWOBJDIF(*ALL) or ALWOBJDIF(*COMPATIBLE) will be specified on the restore commands ≤End of change≥
..."
and I think everything we need is started; servers active
Verify all the necessary jobs started and stayed active. There should be some (troubleshooting) TechNote documents; e.g.
www.ibm.com/support/docview.wss?uid=nas8N1017620
Reference #: N1017620 Historical Number: 21111802 _i Configuring OS/400 SMTP i_ " _Technote_ (troubleshooting)
_Problem_ (Abstract)
This document explains how to configure IBM Power Systems SMTP for sending e-mails. It also includes configuring the iSeries to use the native command SNDDST to send to Internet addresses.
_Resolving the problem_
This document explains how to configure IBM Power Systems SMTP for sending e-mails. It also includes configuring the iSeries to use the native command SNDDST to send to Internet addresses.
..."
cfgtcp copied to new i and same sysname and neta and IP's same
dire's
Had the system been scratch-installed using the original "Sav21"
data, there should have been nothing to _copy_ outside of the process to replace the physical system; and the upgrade would have kept all that the same as well.
Any ideas as to how to figure out why the SNDDST command runs with no
error but does not send to the email address?
I would look at the history since starting the necessary servers to see if any jobs ended unexpectedly, then review the spooled joblogs; also review the active joblogs of the other server jobs that started and remain active. I typically also look for T-AF entries in the audit log to see if perhaps there are some authority issues for the server jobs; e.g. a reason a server job might have ended abnormally, or might not be functional even if remaining active. Then figure out how to track the activity for the Send process; e.g.:
IIRC the QZMF Journal (*JRN) object tracks some of the activity for the Send Distribution (SNDDST) command; perhaps only since having
effected: CHGSMTPA JOURNAL(*YES)
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
