Subject: information on SMTP error code

From: Franck Martin <[email-masked]>
Date: Tue, 6 Aug 2002 16:20:01 +1200

Can someone clarify the following?

Note that I'm using Postfix as mail server.

Thanks

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: [email-masked] <mailto:[email-masked]> 
Web site: http://www.sopac.org/
<http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/
<http://fmaps.sourceforge.net/> 
Certificate: https://www.sopac.org/ssl/ 

This e-mail is intended for its addresses only. Do not forward this
e-mail without approval. The views expressed in this e-mail may not be
necessarily the views of SOPAC.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, 6 August 2002 3:32 
To: Franck Martin
Cc: [email-masked]
Subject: Re: FW: Postfix SMTP server: errors from
maya.usp.ac.fj[144.120.8.5]

Hi Frank,

Well it all depends where the 552 code is issued and from my
understanding this is
somewhat of a bug in the original RFC 821 specifictaion.

Sometimes 552 code means its a temporary failure and other time its a
permanent failure.

As you can see below, the "250 Ok" is issue and that is the reason the
mail is requeued
after the it has failed because 552 code was issue later on.

> Out: 250 Ok
> In:  MAIL FROM:<[email-masked]> SIZE=4070400
> Out: 250 Ok

cheers
Satendra.

>Further to our previous messages requesting to stop this particular
e-mail,
>it seems that maya is not SMTP compliant as upon receiving a 5xx error
code
>it should stop immediately the transaction, but it does not...

>cf: http://www.ietf.org/rfc/rfc0821.txt

>Please fix maya mail server.

>Cheers.

>Franck Martin
>Network and Database Development Officer
>SOPAC South Pacific Applied Geoscience Commission
>Fiji
>E-mail: [email-masked] <mailto:[email-masked]>
>Web site: http://www.sopac.org/
><http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/
><http://fmaps.sourceforge.net/>
>Certificate: https://www.sopac.org/ssl/

>This e-mail is intended for its addresses only. Do not forward this
e-mail
>without approval. The views expressed in this e-mail may not be
necessarily
>the views of SOPAC.

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Tuesday, 6 August 2002 1:24
>To: [email-masked]
>Subject: Postfix SMTP server: errors from maya.usp.ac.fj[144.120.8.5]

>Transcript of session follows.

> Out: 250 Ok
> In:  MAIL FROM:<[email-masked]> SIZE=4070400
> Out: 250 Ok
> In:  RCPT TO:<[email-masked]>
> Out: 552 Message size exceeds fixed limit
> In:  DATA
> Out: 554 Error: no valid recipients
> In:  RSET

>No message was collected successfully.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 05 Aug 2002 21:44:52 -0700

> Can someone clarify the following?

Sure.  The person with whom you're corresponding hasn't read the standards
that they're appealing to.

> understanding this is somewhat of a bug in the original RFC 821
> specifictaion.

> Sometimes 552 code means its a temporary failure and other time its a

Wrong.

   5yz   Permanent Negative Completion reply
      The command was not accepted and the requested action did not
      occur.  The SMTP client is discouraged from repeating the exact
      request (in the same sequence).  Even some "permanent" error
      conditions can be corrected, so the human user may want to direct
      the SMTP client to reinitiate the command sequence by direct
      action at some point in the future (e.g., after the spelling has
      been changed, or the user has altered the account status).

If it were a temporary code, it would be 4xx.

> mail is requeued after the it has failed because 552 code was issue
> later on.

An earlier command succeeded and a later command failed.  That doesn't
mean the message should be retried as if it were a temporary error.  This
sentence basically makes no sense.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Aug 2002 10:31:48 -0400

> Sometimes 552 code means its a temporary failure and other time its a

one of the examples of the use of 552 in RFC 821 was "exceeded storage 
allocation" - a condition which is often better treated as a temporary 
failure than a permanent one.    some senders try to compensate for
this use of 552 by treating it as a temporary failure even though it
begins with 5.

Keith