Subject: RE: Decode-error case in Eifax(RFC2532)

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 14 Jun 1999 23:28:49 -0700

> >> I am assume either of the following combination:
> >> 1) DSN: "delivered"/"success" & MDN: "processed"/" error"
> >> 2) DSN: respond with [RFC1893] status code of 5.6.1 regardless if DSN
> was
> >> requested.
> 
	Tamura-san said: 
> In short, when the docode-error happens,
> For the DSN request, the following is responded.
>   Action: delivered
>   Status: 5.6.1
	[Cancio, Vivian]  
	I think Action is "Failed". Note RFC 1891 Section 6.2.2. (f) and
	Section 6.2.6 (c) NOTE: Some MTAs are known to forward
undeliverables to the local postmaster or ... this is still considered
delivery failure, and does not diminish the requirements to issue a failed
DSN ...
	<snip>
> My question:
> >> > Another question for the POP3 or IMAP4 type terminal.
> >> > When it receives, decodes and "prints"(normal case of box type),
> >> > should it respond with "dispatched", not "displayed", not 
> >> > "processed" ?
> 
> -- quote of RFC2298 --
>    "dispatched"   The message has been sent somewhere in some manner
>                               (e.g., printed, faxed, forwarded) without
>                               necessarily having been previously
>                               displayed to the user.  The user may or
>                               may not see the message later.
> 
>    "processed"    The message has been processed in some manner (i.e.,
>                               by some sort of rules or server) without
>                               being displayed to the user.  The user may
>                               or may not see the message later, or there
>                               may not even be a human user associated
>                               with the mailbox.
> -- end of quote --
> 
> I think "dispatched" is better than "processed".
> Do you agree with me ?
	[Cancio, Vivian]  
	I think you are right but let me think about it ...

	Regards,
	Vivian
	-------------------------

> Regards,
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> Mail: [email-masked]
> Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)

---

From: Hiroshi Tamura <[email-masked]>
Date: Tue, 15 Jun 1999 19:00:41 +0900

Vivian-san,

Thank you for your response.

>> delivery failure, and does not diminish the requirements to issue a failed

If "Failed", "Diagnostic-code" field SHOULD be included.
In the typical example(user-unknown case):
   Diagnostic-Code: smtp; 550 user unknown

The docode-error case is after DATA command.

-- quote of RFC821 --
            DATA
               I: 354 -> data -> S: 250
                                 F: 552, 554, 451, 452
               F: 451, 554
               E: 500, 501, 503, 421
-- end of quote --

-- quote of RFC821 --
         421 <domain> Service not available,
             closing transmission channel
            [This may be a reply to any command if the service knows it
            must shut down]
         451 Requested action aborted: local error in processing
         452 Requested action not taken: insufficient system storage
          
         500 Syntax error, command unrecognized
            [This may include errors such as command line too long]
         501 Syntax error in parameters or arguments
         503 Bad sequence of commands
         552 Requested mail action aborted: exceeded storage allocation
         554 Transaction failed
-- end of quote --

What Reply-code is better in the decode error case ?
451 or 554 ?

Excuse me for the repetition of my previous message.

My question;
>> Other questions has come.
>> From 3.2.6.3 of RFC2298[MDN], when the disposition-modifiers are
>> "error" or "warning", further information is contained in an
>> Error or Warning field.
>> 
>> -- quote of RFC2298 --
>> 3.2.7 Failure, Error and Warning fields
>> 
>>    The Failure, Error and Warning fields are used to supply additional
>>    information in the form of text messages when the "failure"
>>    disposition type, "error" disposition modifier, and/or the "warning"
>>    disposition modifer appear.  The syntax is
>> 
>>      failure-field = "Failure" ":" *text
>> 
>>      error-field = "Error" ":" *text
>> 
>>      warning-field = "Warning" ":" *text
>> -- end of quote --
>> 
>> Any messesge is available in Error and Warning field ?
>> Of course there may be some limitations about the number of characters.
>> For example,
>>   Error: Decode error happened !

Regards,

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Jun 1999 07:27:33 -0700 (PDT)

> What Reply-code is better in the decode error case ?

4xy will cause the sender to retry the transaction later.
5xy will cause the sender to _not_ retry the transaction later.

A decode error will not succeed later, so 5xy (554, as you mention
above) is better.

-Dan Wing

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 16 Jun 1999 08:04:39 +0900

Wing-san,

Thank you.

>> A decode error will not succeed later, so 5xy (554, as you mention

This reminded me of the importants points.
Excuse me for previous question.

For the DSN request, it's about what should be responded.

Eifax-A  --> MTA --> Eifax-B

MTA and Eifax-B support SMTP and DSN.

Case A:
If the decode error happens in Eifax-B and Eifax-B respond
with 554 after receiving contents and <CRLF> + '.' + <CRLF>,
MTA(not Eifax-B) creates DSN and returns it to Eifax-A.
Its DSN is the existing DSN. It's maybe,
  Action: failed
  Diagnostic-Code: smtp; 554 xxxxxx
  Status: 5.x.x
...

Question 1:
How about "Status: " field in this case ?
In this case, MTA doesn't determine the message cannot
be processed, it is not "5.6.1". Am I right ?

Case B:
If the whole message are received by Eifax-B('250' is
returned after receiving contents and <CRLF> + '.' + <CRLF>)
and the deocde error happens and Eifax-B itself create DSN, ...

Question 2; (My previous question)
Even in this case, What is in Action field ?
In this case, Action is failed ? as Vivian-san indicated ?
If so, what should be included in Diagnostic-Code ?
I think some SMTP responses should be included in it.
If it is right, there are no suitable ones in it.
Am I wrong ?
In this case my feeling is as follows.
  Action: delivered
  Status: 5.6.1
  ....

If I am wrong, please show me.

Regards,

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Jun 1999 17:54:45 -0700 (PDT)

> be processed, it is not "5.6.1". Am I right ?

If Eifax-B implements RFC2034 ("SMTP Service Extension for Returning
Enhanced Error Codes"), then MTA can return the enhanced-error-
code in the "Status:" field of the DSN.

RFC2034 simply says that Eifax-B would return "554 55.44.33 xxx"
which allows MTA to return a DSN that looks like:

    Action: failed
    Status: 55.44.33

Of course, 55.44.33 isn't a valid response, but I wanted to
show that the value from Eifax-B's enhanced status code is
returned in the DSN "Status:" field.  The example in RFC2034
(section 6) shows how this works.

> In this case, Action is failed ? as Vivian-san indicated ?

Yes, that would be fine.

> If so, what should be included in Diagnostic-Code ?

The X.6.X codes are for media conversion problems, so I think
one of the 5.6.X codes would be appropriate.  Any of these 
seem appropriate:

       X.6.0   Other or undefined media error
       X.6.1   Media not supported
       X.6.3   Conversion required but not supported
       X.6.4   Conversion with loss performed
       X.6.5   Conversion Failed

X.6.2 is "Conversion required and prohibited" which probably doesn't
fit well.

> If I am wrong, please show me.

I think any of the 5.6.x codes would work -- 5.6.1 is certainly
a good choice.  I don't recall what our implementation uses.

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Jun 1999 18:20:47 -0700 (PDT)

On Tue, 15 Jun 1999 20:20 -0500, Richard Shockey wrote:

> Speaking of implementation issues.... did the WG not agree that a
> "Implementers Guide" was within scope? I seem to recall some discussion
> about that in Minneapolis.

Yes, that was the consensus.

> This thread seems a proper and reasonable subject for such a Guide and
> could be very useful.

Agreed.

It sounds like you're volunteering, Richard?

I think combining this thread with Mike Ruhl's document would provide a
reasonable start ....

-d

---

From: Richard Shockey <[email-masked]>
Date: Tue, 15 Jun 1999 20:20:41 -0500

Richard Shockey
Shockey Consulting LLC                  
8045 Big Bend Blvd. Suite 110    
St. Louis, MO 63119
Voice 314.918.9020
Fax   314.918.9015
INTERNET Mail & IFAX : [email-masked]
eFAX 815.333.1237 
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Tue, 15 Jun 1999 20:46:47 -0500

>I think combining this thread with Mike Ruhl's document would provide a

An excellent suggestion.  But if I'm not mistaken our Chair had previously
identified an author for a 'Implementers Guide'.  Jim???

I would, of course, be willing to assist in that effort. There is much to
implement.

Considering that we are witnessing a explosion in free IVOICE/ IFAX portal
services ( my list is a dozen and counting ) it might be useful to offer
some guidance here.

The good news is that the market is being educated to the value of  RFC
2305/2532.

Richard Shockey
Shockey Consulting LLC

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 16 Jun 1999 11:15:53 +0900

Wing-san,

Thank you for your explanation. I almost understand.

Shockey-san
>> >> This thread seems a proper and reasonable subject for such a Guide and

I also agreed.

>> >I think combining this thread with Mike Ruhl's document would provide a

Which document ?
I don't think it is a coverpage document.

Regards,

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Jun 1999 19:48:55 -0700 (PDT)

> I don't think it is a coverpage document.

Mike's Internet Draft described coverpages, but it also described 
recommended behaviors for coverpages.  I believe Mike has abandoned
the document.

-Dan Wing

---

From: James Rafferty <[email-masked]>
Date: Tue, 15 Jun 1999 23:11:45 -0400

>>Yes, that was the consensus.
Correct.    
>>> This thread seems a proper and reasonable subject for such a Guide and
Ditto.    
>identified an author for a 'Implementers Guide'.  Jim???
Mike Moldovan of Genoa expressed interest, but I've seen no document.   If
you and Mike Ruhl wanted to step forward, that would be fine from my
standpoint.   Mike M. may have something to add later, but he tends to get
busy on internal things.   

James

*------------------------------------------------*
James Rafferty			
President, Human Communications LLC	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email/Internet Fax:  [email-masked]
	 [email-masked]
     [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------

---

From: Dan Wing <[email-masked]>
Date: Tue, 15 Jun 1999 20:19:45 -0700 (PDT)

> standpoint.   Mike M. may have something to add later, but he tends to get

I can't speak for Mike Ruhl, but I know that I don't have time to work on
such a document (and I have reservations about the usefulness of such a
document, as well).

-Dan Wing