Re: Email relay

On 04-May-2015 10:45 -0500, John McKee wrote:

On Mon, May 4, 2015 at 10:13 AM, CRPence wrote:

On 04-May-2015 08:23 -0500, John McKee wrote:

This is QATMSMTP from my system. Record 3 was altered only on
the file produced by CPYF, to change part of the name. No other
changes.

5722SS1 V5R4M0 060210 COPY FILE
QUSRSYS/QATMSMTP CONFIG 05/01/15 14:39:47 Page 1

From file . . : QUSRSYS/QATMSMTP Member . . : CONFIG
Record format . . : QTMSMTPR
Record length . . . : 568
To file . . . . . . : *PRINT

Inline I write the correlation of the data to the parameter(s),
along with an indication of the any ¿confusion? or some indication
of the probability the inference may be correct following those
that are not known.

RCDNBR *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5

1 03 030 0 0 N

RTYMIN(10 003) RTYDAY(0 0) RTYRMTSVR(*NO) /* 0 -> *DFT */

2 ?

USRIDDELIM('?')

3 relay.XXXXX.net

MAILROUTER('relay.XXXXX.net')

4 N QSM QSMRMTAD TCPIP 1 00001

AUTOADD(*NO)
USRIDPFX('QSM') ADDRESS('QSMRMTAD')
SYSNAME('TCPIP ') TBLTYPE(*SYSTEM)
unknown( ¿¿00001?? )

5 Y Y

FIREWALL(*YES) AUTOSTART(*YES)

6 *CCSID *CCSID

TBLSMTPOUT(*CCSID) TBLSMTPIN(*CCSID)

7 00850

CCSID(00850)

8 N

JOURNAL(*NO)

9 N

ALLMAILMSF(*NO)

10 Y

PCTRTGCHR(*YES)

11 00 000

RTYHOUR(00 000) /* 0 -> *DFT */

12 N *NONE 0030

DIALSCD(*NO *NONE 0030) /* *NO is a single value */

13 N N N N *NONE

??? ??? ???
ETRNSVR Support ETRN for server *SAME, *NO, *YES
ETRNCLT Support ETRN for client Single values: *NO
Other values: Element list
Element 1:Enable client ETRN *SAME, *YES
Element 2:Incoming mail server addr Char( 15) value, *SAME
Element 3:Mail domain name Char(255) value, *SAME
MIME8BIT Support 8-bit MIME *SAME, *NO, *YES
NFYDLVRY Delivery sts notification Element list
Element 1:Responsible person Char(255) value, *SAME, *NONE
??? ??? ???

14 QSYS/QSYSWRK

SBSD(QSYS/QSYSWRK)

15 *NONE

RBLSVR(*NONE) /* ¿maybe? */

16 N

MIME8BIT(*NO) /* ¿maybe? */

17 *ALL

ALWRLY(*ALL) /* ¿must be? -- only one left allows *ALL */

18 *LIST

IFCDMN(*LIST) /* ¿maybe IFCDMN? ¡Moot however¡ */
/* ¡seriously wrong! ¡*LIST must be ALWRLY! */

19 *NONE

FTRACN(*NONE) /* ¿maybe? */

20 N

POPWDW(N ) /* ¿must be source of msg CPD0076 */
/* "'N ' for parameter POPWDW must be numeric." */

21 N

The prior RRNs 20 and 21 appear to be a[n accidental] repeat of
RRN-8 and RRN-9, as the apparent origin for corruption, and the
following appear to be what would be expected for RRNs 10 to 21,
such that if they were, then the problem should not occur because
rrn-32 minus 12 is rrn-20 which suggests POPWDW(00000) for which
00000 translates to *NONE.

22 Y
23 00 000
24 N 0030
25 N N N N *NONE
26 QSYS/QSYSWRK
27 *NONE
28 N
29 *ALL
30 *NONE
31 *NONE
32 00000
33 V5R3M0

33 records copied to member or label *N in file QSYSPRT in library
QSYS. 0 records excluded.

* * * E N D O F C O M P U T E R P R I N T O U T * * *

I am not sure if the V5R4M0 is supposed to be the same as V5R3M0,
or even if the V5R4M0 was supposed to update the final record to
reflect the current OS release. The /same/ Copy File (CPYF) output
from the file QATMSMTP in QTCP FROMMBR(CONFIG) may be indicative of
the expectations in that regard. Perhaps the output from the
following request could be included in a followup reply?:
CPYF QTCP/QATMSMTP *PRINT FROMMBR(CONFIG)

Then the question remains, is the simple-but-destructive
/recovery/ from the error and corruption from which that prompting
error originates an acceptable\preferable route, or is a
surreptitious replacement of the data with what is the apparent
equivalent of what is the functional expectation for the feature
preferable instead?

Presumably the completed recovery from the destructive path is
[as inferred from the data] apparently the following request
[which alone, without the prior destructive action, has at least a
small chance of being corrective, though I am very doubtful]:

CHGSMTPA /* ¡Correct next _two_ lines! */
MAILROUTER('relay.XXXXX.net') /* Un-Munge this first! */
ALWRLY(*ALL) /*<- choose one or other -> */ ALWRLY(*LIST)
RTYMIN(10 003) RTYDAY(*DFT *DFT) RTYHOUR(*DFT *DFT)
RTYRMTSVR(*NO) AUTOADD(*NO) USRIDPFX(QSM) ADDRESS(QSMRMTAD)
SYSNAME(TCPIP) TBLTYPE(*SYSTEM) /* unknown( ¿00001? ) */
FIREWALL(*YES) AUTOSTART(*YES) USRIDDELIM('?')
TBLSMTPOUT(*CCSID) TBLSMTPIN(*CCSID) CCSID(00850)
JOURNAL(*NO) ALLMAILMSF(*NO) PCTRTGCHR(*YES) POPWDW(*NONE)
DIALSCD(*NO /* *NONE 0030 */) SBSD(QSYS/QSYSWRK)
RBLSVR(*NONE) /* ¿likely? */ MIME8BIT(*NO) /* ¿likely? */
IFCDMN(*NONE) /* ¿likely? */ FTRACN(*NONE) /* ¿likely? */
ETRNSVR(*NO) /* ¿likely? */
ETRNCLT(*NO /* svraddr maildmn */) /* ¿likely? */
NFYDLVRY(*NONE) /* ¿likely? */

QTCP version, per request, unmodified in any way.

Quoted content edited for compactness; content unchanged:

5722SS1 V5R4M0 060210 COPY FILE
QTCP/QATMSMTP CONFIG 05/04/15 10:30:24

From file . . : QTCP/QATMSMTP Member . . : CONFIG
Record format . . . : QTMSMTPR
Record length . . . : 568
To file . . . . . . : *PRINT

RCDNBR *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5

1 03 030 0 0 N

RTYMIN(03 030) RTYDAY(*DFT *DFT) RTYRMTSVR(*NO)

2 ?

USRIDDELIM('?')

3

MAILROUTER(*NONE)

4 N QSM QSMRMTAD TCPIP 1 00001

AUTOADD(*NO)
USRIDPFX(QSM) ADDRESS(QSMRMTAD)
SYSNAME(TCPIP ) TBLTYPE(*SYSTEM)
/* unknown( ¿¿00001?? ) */

5 Y N

FIREWALL(*YES) AUTOSTART(*NO)

6 *CCSID *CCSID

TBLSMTPOUT(*CCSID) TBLSMTPIN(*CCSID)

7 00819

CCSID(00819)

8 N

JOURNAL(*NO)

9 N

ALLMAILMSF(*NO)

10 N

PCTRTGCHR(*YES)

11 00 000

RTYHOUR(*DFT *DFT)

12 N 0030

DIALSCD(*NO /* *NONE 0030 */)

13 N N N N *NONE

??? ??? ???
ETRNSVR Support ETRN for server *SAME, *NO, *YES
ETRNCLT Support ETRN for client Single values: *NO
Other values: Element list
Element 1: Enable client ETRN *SAME, *YES
Element 2: Incoming mail server addr Char( 15) value, *SAME
Element 3: Mail domain name Char(255) value, *SAME
MIME8BIT Support 8-bit MIME *SAME, *NO, *YES
NFYDLVRY Delivery sts notification Element list
Element 1: Responsible person Char(255) value, *SAME, *NONE
??? ??? ???

14 QSYS/QSYSWRK

SBSD(QSYS/QSYSWRK)

15 *NONE

RBLSVR(*NONE) /* ¿maybe? */

16 N

MIME8BIT(*NO) /* ¿maybe? */

17 *NONE

ALWRLY(*NONE) /* ¿must be? */

18 *NONE

IFCDMN(*NONE) /* ¿maybe? */

19 *NONE

FTRACN(*NONE) /* ¿maybe? */

20 00000

POPWDW(*NONE) /* ¿must be? */

21 V5R3M0

The last record is an effective /release level/ implying the layout of the preceding data records; the v5r3m0 level is known to have 21 records, not the 33 seen in the problematic scenario. FWiW, the v6r1m0 layout changes to add new records according to the Memo To Users (MTU) for IBM i 6.1 [and allusion to new field(s) but I have no DSPFFD nor data nor anything else, per no access to any systems, to see nor verify anything about those changes].

21 records copied to member or label *N in file QSYSPRT in library
QSYS. 0 records excluded.

* * * E N D O F C O M P U T E R P R I N T O U T * * *

So if the destructive /recovery/ action [which BTW, follow my script, not what might be found elsewhere; e.g. an appallingly bad and poorly /documented/ _recommendation_ as in <http://archive.midrange.com/midrange-l/200108/msg02043.html>] were to be performed after a SAVOBJ taken as backup, then [a portion of] the _additional recovery_ from the destructive action would be the already mentioned CHGSMTPA invocation in my prior reply [quoted above]; noting, the effect of the automatic data-recovery effected after the destructive /recovery/ action is performed, is the description of the correlated parameter specifications from the data spooled for the member CONFIG in the file QATMSMTP in QTCP.

Let me know if you want a script for the destructive recovery action finalized with [a variant of the aforementioned] fully-specified CHGSMTPA invocation, or if you want a script of a surreptitious replacement of the data; the former is easier, but presumes the corrective to the prior destruction is effected by the CHGSMTPA rather than only by other means [such as starting the server; the archived message did not reveal that, among other important details that are lacking]. But even if the recovery of the destroyed\deleted object is not by CHGSMTPA, the same /tricks/ that can be employed to reset the data via the latter\more-complex data-replacement scenario still can be performed. I suppose you could email me for my phone number and I could walk you through the steps over the phone in case they are not exacting; I can not test them, for lack of access to a system, but what they would do I am all but assured will cure the problem. I could just post both, but for inability to confirm them /by my own hand/, I would rather only post the former... if requested.

FWiW: Because the file QUSRSYS/QATMSMTP is probably not journaled <http://archive.midrange.com/midrange-l/200907/msg00539.html>, when and what was the origin of the corruption is not likely going to be found; the "AnyMail/400 Mail Server Framework journal (QUSRSYS/QZMF)" would be a good choice, and would seem a natural consequence of CHGSMTPA JOURNAL(*YES). FWiW: Given no explicit changes had ever been made to the data via CHGSMTPA since the corruption, the prior mentioned information to collect from DSPOBJD and DSPFD [but were not provided in this topic thread] could at least identify the date\time; and given the /conversion/ of the data is likely to have occurred post-install upon the first start of the server, then that is the likely time, and my SWAG is that the conversion code is not properly coded, so accidentally allowed concurrent /conversions/ to perform record /insert/ activity.