What is SMTP status code 556?

I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.

A user of mine had a mail message returned to him with the message:

556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net

I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing.

I searched for the SMTP status codes, finally found an RFC
or two, but they don't say anything about 556. In fact, the
status codes only go up to about 554.

Does anyone know what SMTP status code 556 means?

Lawrence Bleau
University of Maryland
Physics Dept., Space Physics Group
301-405-6223
bleau@umtof.umd.edu

Re: What is SMTP status code 556?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-3698-1114030332-0009
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Lawrence Bleau writes:

> I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.
>
> A user of mine had a mail message returned to him with the message:
>
> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net
>
> I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing.
>
> I searched for the SMTP status codes, finally found an RFC
> or two, but they don't say anything about 556. In fact, the
> status codes only go up to about 554.
>
> Does anyone know what SMTP status code 556 means?

It means the same thing that any SMTP status code 500 through 599 means: the
recipient's mail server refuses to accept the message, permanently.

The exact numerical code is for diagnostic purposes only, and varies from
system to system. Each particular mail server -- generally speaking -- may
use whatever 5xx code it wants in any particular situation where it wishes
to inform the sender that the message cannot be delivered to the recipient,
and the sender should not try again.

If you want to know what a particular code means, the only way to do so is
to contact whoever runs the mail server that issued the code. Although
there are some specific error numbers that are commonly used to denote
certain specific conditions, by most mail servers, this would not be the
definitive answer.



--=_mimegpg-commodore.email-scan.com-3698-1114030332-0009
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCZsD9x9p3GYHlUOIRAu2pAJ4iOJb1mrUF1PXBjpnLEutICTTaHQCe JNzG
LxAq3IE4CJmAyhs1kJxM7kA=
=PEeq
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-3698-1114030332-0009--

Re: What is SMTP status code 556?

Lawrence Bleau wrote:
> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net

When sending emails, the error code that the VMS sending SMTOP server
gives you are meaningless.

Enable tracing of the connection

$define/system tcpip$smtp_symb_trace
$TCPIP STOP MAIL
$WAIT 00:01:00
$TCPIP START MAIL

then send the message again.

Once message has been sent, delete the logical, stop and start mail
again. and analyse the contents of the log file (tcpip$smtp_common:*logfile.log)

You may find that the receiving SMTP server has provided a very
meaningful message which the VMS sending server didn't bother including
in the error message sent back to the user.

Re: What is SMTP status code 556?

Lawrence Bleau wrote:

> I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.
>
> A user of mine had a mail message returned to him with the message:
>
> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net

looks like should read 554 (as you said, RFC 821 stops here)
See INFO-VAX Wed, 19 May 2004 Volume 2004 : Issue 277 or Google groups
search, message by David Webb below:

Date: Wed, 19 May 2004 10:02:23 +0000 (UTC)
From: david20@alpha2.mdx.ac.uk
Subject: Re: Request for new SMTP
Message-ID:

.../..

>I have added *@yahoo.{it|fr|ca} to my 'reject-mail-from' list.
>
>Example from my mail today... my system bounced this message, and it
was bounced back to me....
>
>Date: Tue, 18 May 2004 20:13:52 -0500 (CDT)
>Message-Id: <04051820135245@firstdbasource.com>
>From: TCPIP$SMTP@FIRSTDBASOURCE.COM
>To: TCPIP$SMTP
>Subject: Returned mail
>
>---- Transcript of session follows ----
>554 %TCPIP-E-SMTP_XFAIL, remote transaction failure, yahoo.ca
>---- Unsent message follows ----
>
>Date: Tue, 18 May 2004 20:13:47 -0500 (CDT)
>Message-Id: <04051820134760@firstdbasource.com>
>From: TCPIP$SMTP@FIRSTDBASOURCE.COM
>To: irqwwwqjckwmgx@yahoo.ca
>Subject: Returned mail
>
>---- Transcript of session follows ----
>%%%%%%%%%%%% 18-MAY-2004 20:13:43.14 %%%%%%%%%%%%
>%MAIL-E-NOSUCHUSR, no such user 3CA09A38.EDD42A5B
>%%%%%%%%%%%% 18-MAY-2004 20:13:44.33 %%%%%%%%%%%%
>%MAIL-E-NOSUCHUSR, no such user 3CA09ACD.E65931BE
>%%%%%%%%%%%% 18-MAY-2004 20:13:45.56 %%%%%%%%%%%%
>%MAIL-E-NOSUCHUSR, no such user 3CA0EF32.F9EA4BF
>%%%%%%%%%%%% 18-MAY-2004 20:13:46.35 %%%%%%%%%%%%
>%MAIL-E-NOSUCHUSR, no such user 3CA14144.80B41CBD
>%%%%%%%%%%%% 18-MAY-2004 20:13:47.05 %%%%%%%%%%%%
>%MAIL-E-NOSUCHUSR, no such user 3CA2865D.AE018E65
.../..

So, ask HP/TCPIP Engineering why they changed it.
And remember, Google search is your friend.

HTH,

D.

Re: What is SMTP status code 556?

On Wed, 20 Apr 2005, Lawrence Bleau wrote:
> I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.
> A user of mine had a mail message returned to him with the message:
>
> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net
>
> I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing.
> I searched for the SMTP status codes, finally found an RFC
> or two, but they don't say anything about 556. In fact, the
> status codes only go up to about 554.
>
> Does anyone know what SMTP status code 556 means?

It means that you should report that system to rfc-ignorant.org. 556 is not a
valid defined code in RFC 2822 (which is current). I know of no subsequent RFC
or other standard which has added such a code.

Re: What is SMTP status code 556?

In article , "D. Stussy" writes:
> On Wed, 20 Apr 2005, Lawrence Bleau wrote:
[snip]
>> Does anyone know what SMTP status code 556 means?
>
> It means that you should report that system to rfc-ignorant.org. 556 is not a
> valid defined code in RFC 2822 (which is current). I know of no subsequent RFC
> or other standard which has added such a code.

RFC 2822 is irrelevant. It describes message format, not transfer
protocol.

RFC 2821 is the controlling document. It states:

An SMTP server SHOULD send only the reply codes listed in this
document. An SMTP server SHOULD use the text shown in the examples
whenever appropriate.

556 is not one of the listed codes. In the language of the RFC's, the
"SHOULD" means that use of code 556 is allowed but discouraged.

John Briggs

Re: What is SMTP status code 556?

"D. Stussy" writes:

>On Wed, 20 Apr 2005, Lawrence Bleau wrote:
>> I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.
>> A user of mine had a mail message returned to him with the message:
>>
>> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net
>>
>> I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing.
>> I searched for the SMTP status codes, finally found an RFC
>> or two, but they don't say anything about 556. In fact, the
>> status codes only go up to about 554.
>>
>> Does anyone know what SMTP status code 556 means?

>It means that you should report that system to rfc-ignorant.org. 556 is not a
>valid defined code in RFC 2822 (which is current). I know of no subsequent RFC
>or other standard which has added such a code.

The 5xx status tells the client the mail was rejected and the client should
not retry.

55x codes usually are used for "home grown" error messages, rather than
one of the predefined ones. These days they often are used for 'get lost,
spammer!' type messages
--
-Mike

Re: What is SMTP status code 556?

On Mon, 25 Apr 2005 briggs@encompasserve.org wrote:
> In article , "D. Stussy" writes:
> > On Wed, 20 Apr 2005, Lawrence Bleau wrote:
> [snip]
> >> Does anyone know what SMTP status code 556 means?
> >
> > It means that you should report that system to rfc-ignorant.org. 556 is not a
> > valid defined code in RFC 2822 (which is current). I know of no subsequent RFC
> > or other standard which has added such a code.
>
> RFC 2822 is irrelevant. It describes message format, not transfer
> protocol.
>
> RFC 2821 is the controlling document. It states:
>
> An SMTP server SHOULD send only the reply codes listed in this
> document. An SMTP server SHOULD use the text shown in the examples
> whenever appropriate.
>
> 556 is not one of the listed codes. In the language of the RFC's, the
> "SHOULD" means that use of code 556 is allowed but discouraged.

Nor defined. All that means is that if it's sent, it should be recognized as a
"PERMFAIL" of the message for future compatibility, but there currently exists
no circumstances under which it should ever be sent - so sending it is
currently a protocol error.

Re: What is SMTP status code 556?

On Tue, 26 Apr 2005, Michael Moroney wrote:
> "D. Stussy" writes:
> >On Wed, 20 Apr 2005, Lawrence Bleau wrote:
> >> I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.
> >> A user of mine had a mail message returned to him with the message:
> >>
> >> 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net
> >>
> >> I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing.
> >> I searched for the SMTP status codes, finally found an RFC
> >> or two, but they don't say anything about 556. In fact, the
> >> status codes only go up to about 554.
> >>
> >> Does anyone know what SMTP status code 556 means?
>
> >It means that you should report that system to rfc-ignorant.org. 556 is not
> >a valid defined code in RFC 2822 [sic] (which is current). I know of no
> >subsequent RFC or other standard which has added such a code.
>
> The 5xx status tells the client the mail was rejected and the client should
> not retry.
>
> 55x codes usually are used for "home grown" error messages, rather than
> one of the predefined ones. These days they often are used for 'get lost,
> spammer!' type messages

However, 554 is the proper code defined in RFC 2821 for policy rejections after
the DATA subcommand. You will find that the RFC contains a listing of valid
error states that may be returned after certain commands, and 556 is not among
them.

Re: What is SMTP status code 556?

"D. Stussy" wrote:
> > 556 is not one of the listed codes. In the language of the RFC's, the
> > "SHOULD" means that use of code 556 is allowed but discouraged.

But it isn't a given that the 556 was actually issued in the SMTP (821)
dialogue. My experience shows that the VMS software may use "556" when
generating the non-delivery notification text instead of using the code
and text that the remote SMTP server really provided.

Re: What is SMTP status code 556?

In article , "D. Stussy" writes:
> However, 554 is the proper code defined in RFC 2821 for policy rejections after
> the DATA subcommand. You will find that the RFC contains a listing of valid
> error states that may be returned after certain commands, and 556 is not among
> them.

Re-read the RFC. There's no requirement that the code that is returned
be listed there.

John Briggs

Re: What is SMTP status code 556?

In article <1115029711.806842530ce3a09b93a029186a99ffda@teranews>, JF Mezei writes:
> "D. Stussy" wrote:
>> > 556 is not one of the listed codes. In the language of the RFC's, the
>> > "SHOULD" means that use of code 556 is allowed but discouraged.
>
> But it isn't a given that the 556 was actually issued in the SMTP (821)
> dialogue. My experience shows that the VMS software may use "556" when
> generating the non-delivery notification text instead of using the code
> and text that the remote SMTP server really provided.

Synthesizing an RFC 2821 style status code that never appeared in an
RFC 2821 dialogue? In place of an RFC 2821 status code that actually
did appear in that dialogue?

I can smell that from here. Peeuuuu.

John Briggs

Re: What is SMTP status code 556?

In article , "D. Stussy" writes:
> On Mon, 25 Apr 2005 briggs@encompasserve.org wrote:
[snip]
>> RFC 2822 is irrelevant. It describes message format, not transfer
>> protocol.
>>
>> RFC 2821 is the controlling document. It states:
>>
>> An SMTP server SHOULD send only the reply codes listed in this
>> document. An SMTP server SHOULD use the text shown in the examples
>> whenever appropriate.
>>
>> 556 is not one of the listed codes. In the language of the RFC's, the
>> "SHOULD" means that use of code 556 is allowed but discouraged.
>
> Nor defined. All that means is that if it's sent, it should be recognized as a
> "PERMFAIL" of the message for future compatibility, but there currently exists
> no circumstances under which it should ever be sent - so sending it is
> currently a protocol error.

Violating a "should" does not constitute a protocol error. Find me a
"must" and we'll talk. Note the following:

"The list of codes that appears below MUST NOT be construed as
permanent. While the addition of new codes should be a rare and
significant activity, with supplemental information in the textual
part of the response being preferred, new codes may be added as the
result of new Standards or Standards-track specifications.
Consequently, a sender-SMTP MUST be prepared to handle codes not
specified in this document and MUST do so by interpreting the first
digit only.

The SMTP client is required to deal with the issue. As long
as the first digit is correct, and the SMTP client is compliant, no
protocol error can result

You really need to quote some text to support your contentions. According
to the RFC, you're zero for two.

John Briggs

Re: What is SMTP status code 556?

"D. Stussy" writes:

>On Mon, 25 Apr 2005 briggs@encompasserve.org wrote:

>> 556 is not one of the listed codes. In the language of the RFC's, the
>> "SHOULD" means that use of code 556 is allowed but discouraged.

>Nor defined. All that means is that if it's sent, it should be recognized as a
>"PERMFAIL" of the message for future compatibility, but there currently exists
>no circumstances under which it should ever be sent - so sending it is
>currently a protocol error.

The boilerplate definition in RFC 2821 reads:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but the
full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.

In 4.2 it reads:

An SMTP server SHOULD send only the reply codes listed in this
document. An SMTP server SHOULD use the text shown in the examples
whenever appropriate.

meaning it's OK for other codes not listed to be used, but this is
discouraged. Also:

The list of codes that appears below MUST NOT be construed as
permanent. While the addition of new codes should be a rare and
significant activity, with supplemental information in the textual
part of the response being preferred, new codes may be added as the
result of new Standards or Standards-track specifications.
Consequently, a sender-SMTP MUST be prepared to handle codes not
specified in this document and MUST do so by interpreting the first
digit only.

meaning a client MUST accept a 556 status as a permanent error and deal
with it appropiately.

In addition:

The third digit and any supplemental information that may be
present is reserved for the finest gradation of information.

Don't read into it too much, in other words. As to 556 "not defined",
only partially true. The first 5 means a permanent error, the second 5
definition is: "x5z Mail system: These replies indicate the status of
the receiver mail system vis-a-vis the requested transfer or other mail
system action." 554 is overly broad: "Transaction failed." In theory,
no need for codes 550-553 (or anything oddball like 556), "transaction
failed" could cover all cases.

This is computer communications, not the fine points of law. Having said
that, if VMS is replacing a standard status passed to it with a 556
status, that is wrong and should be corrected.
--
-Mike

Re: What is SMTP status code 556?

"D. Stussy" writes:

>> The 5xx status tells the client the mail was rejected and the client should
>> not retry.
>>
>> 55x codes usually are used for "home grown" error messages, rather than
>> one of the predefined ones. These days they often are used for 'get lost,
>> spammer!' type messages

>However, 554 is the proper code defined in RFC 2821 for policy rejections after
>the DATA subcommand. You will find that the RFC contains a listing of valid
>error states that may be returned after certain commands, and 556 is not among
>them.

Actually, 550, not 554, is designated for rejection for policy reasons.

--
-Mike

Re: What is SMTP status code 556?

On Mon, 2 May 2005, Michael Moroney wrote:
> meaning it's OK for other codes not listed to be used, but this is
> discouraged. Also:
> [snip]
> meaning a client MUST accept a 556 status as a permanent error and deal
> with it appropiately.
> [snip]
> Don't read into it too much, in other words. As to 556 "not defined",
> only partially true.
> [snip]
> This is computer communications, not the fine points of law. Having said
> that, if VMS is replacing a standard status passed to it with a 556
> status, that is wrong and should be corrected.

All of the above is correct.

This is what Postel's robustness principle ("be liberal in what you
accept, be conservative in what you send") is all about:
. when reading, an application MUST acccept all valid input, even when
it is different from what the specification says should be sent or even
if the specification says it should not be sent.
. when sending, an application should limit itself to what the
specification says should be sent; and in particular it should eschew
what the specification says should not be sent.

There are two misunderstandings of Postel's principle.

The first is the notion that an application should attempt to apply "do
what I mean" semantics to malformed input rather than rejecting it: "OK,
the specification does not allow that space there; but your program should
have accepted it anyway rather than saying syntax error." Typically,
server authors hear this from aggrieved client authors who can't be
bothered to read the specification and instead empirical testing. This is
the If It Works With Outlook Then It Must Be Correct fallacy.

The second misunderstanding arises as an overreaction to the first one; it
assumes that the "liberal" part of Postel's principle is wrongheaded, and
therefore it is mandatory that the application enforce the specification.
These folks promote "SHOULD" to "MUST"; and "SHOULD NOT" to "MUST NOT".
In the face of explicit text that the other end's behavior is permitted,
they point to "SHOULDs" and "SHOULD NOTs".

The specifications do a good job in defining "be conservative in what you
send". That is what all the MUSTs, SHOULDs, SHOULD NOTs, and MUST NOTs in
the RFCs are all about. They don't describe "be liberal in what you
accept" at all.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Re: What is SMTP status code 556?

In article , briggs@encompasserve.org writes:
>
> I can smell that from here.

Multinet returns an appropriate code which is not called out in the
RFC when a sender is rejected by multinet:smtp_server_reject.

Smells good to me. There is no RFC code for "get lost, spammer".

Re: What is SMTP status code 556?

In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
>
> An SMTP server SHOULD send only the reply codes listed in this
> document. An SMTP server SHOULD use the text shown in the examples
> whenever appropriate.

I've not yet found an SMTP server which uses those texts. Some of
them, but not all of them. In fact the RFC uses different text in
its own examples.

Re: What is SMTP status code 556?

briggs@encompasserve.org wrote:
> Synthesizing an RFC 2821 style status code that never appeared in an
> RFC 2821 dialogue? In place of an RFC 2821 status code that actually
> did appear in that dialogue?

Yep. Don't ask me. But i have seen it happen with TCPIP Services 5.3 for
outbound mail.

In fact, it was for an email to HP.COM wich would return some "user not
found" message, when in fact, once symbiont tracing was turned on, the
HP SMTP server was clearly issued another message about spam protection.
(this was as a response to the RCPT TO: command though.

The VMS bounce messages were telling me that Sue Skonetski was an
invalid username at HP.

(this was when I had a dynamic IP with a cable company who had sent all
its IPs to the RBLs, so my IP was not able to send to hp.com directly).

Re: What is SMTP status code 556?

In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article , briggs@encompasserve.org writes:
>>
>> I can smell that from here.
>
> Multinet returns an appropriate code which is not called out in the
> RFC when a sender is rejected by multinet:smtp_server_reject.
>
> Smells good to me. There is no RFC code for "get lost, spammer".

You snipped the context.

JF is reporting his understanding which says (paraphrasing from memory)
that TCPIP Services, acting as an SMTP client is taking the RFC 2821
error code from the server, discarding it, creating a new RFC 2821
style error code and reporting that to the message sender.

You have to use a lot of air freshener with that sort of behavior.


Yes, I agree that it's permissible for an SMTP server to report
a 556 error code. I've already posted here to that effect.

John Briggs

Re: What is SMTP status code 556?

On Mon, 2 May 2005 briggs@encompasserve.org wrote:
> In article , "D. Stussy" writes:
> > However, 554 is the proper code defined in RFC 2821 for policy rejections after
> > the DATA subcommand. You will find that the RFC contains a listing of valid
> > error states that may be returned after certain commands, and 556 is not among
> > them.
>
> Re-read the RFC. There's no requirement that the code that is returned
> be listed there.

Acceptance by a client of that merely allows for further expansion of the
codes. However, any proper server that currently complies with RFC 2821 will
NEVER send such a code - because it is NOT listed in the valid error states.

Re: What is SMTP status code 556?

On Mon, 2 May 2005 briggs@encompasserve.org wrote:
> In article , "D. Stussy" writes:
> > On Mon, 25 Apr 2005 briggs@encompasserve.org wrote:
> [snip]
> >> RFC 2822 is irrelevant. It describes message format, not transfer
> >> protocol.
> >>
> >> RFC 2821 is the controlling document. It states:
> >>
> >> An SMTP server SHOULD send only the reply codes listed in this
> >> document. An SMTP server SHOULD use the text shown in the examples
> >> whenever appropriate.
> >>
> >> 556 is not one of the listed codes. In the language of the RFC's, the
> >> "SHOULD" means that use of code 556 is allowed but discouraged.
> >
> > Nor defined. All that means is that if it's sent, it should be recognized as a
> > "PERMFAIL" of the message for future compatibility, but there currently exists
> > no circumstances under which it should ever be sent - so sending it is
> > currently a protocol error.
>
> Violating a "should" does not constitute a protocol error. Find me a
> "must" and we'll talk. Note the following:
>
> "The list of codes that appears below MUST NOT be construed as
> permanent. While the addition of new codes should be a rare and
> significant activity, with supplemental information in the textual
> part of the response being preferred, new codes may be added as the
> result of new Standards or Standards-track specifications.
> Consequently, a sender-SMTP MUST be prepared to handle codes not
> specified in this document and MUST do so by interpreting the first
> digit only.

....And when such a code is added, there will be a new RFC documenting it. In
the meantime, this simply tells clients that as SMTP evolves, it is possible
that new codes will show up. However, any such new code will not be RFC 2821,
but will be "RFC X" where "RFC X" will presumedly state that it overrides,
replaces, or otherwise modifies RFC 2821.

> The SMTP client is required to deal with the issue. As long
> as the first digit is correct, and the SMTP client is compliant, no
> protocol error can result.

However, an RFC 2821 server will NEVER generate such a code, as it is
undefined.

> You really need to quote some text to support your contentions. According
> to the RFC, you're zero for two.

And you fail to understand the term "reserved for expansion and/or future use."
Clients must be prepared to accept codes that servers currently do not generate
as standards are revised. "Adapt or die."

Re: What is SMTP status code 556?

On Mon, 2 May 2005, Michael Moroney wrote:
> "D. Stussy" writes:
> >> The 5xx status tells the client the mail was rejected and the client should
> >> not retry.
> >>
> >> 55x codes usually are used for "home grown" error messages, rather than
> >> one of the predefined ones. These days they often are used for 'get lost,
> >> spammer!' type messages
>
> >However, 554 is the proper code defined in RFC 2821 for policy rejections after
> >the DATA subcommand. You will find that the RFC contains a listing of valid
> >error states that may be returned after certain commands, and 556 is not among
> >them.
>
> Actually, 550, not 554, is designated for rejection for policy reasons.

In response to "MAIL FROM:" or "RCPT TO:", 550 is correct. However, following
"DATA", 554 is the code to use.

Re: What is SMTP status code 556?

"D. Stussy" writes:

>> The SMTP client is required to deal with the issue. As long
>> as the first digit is correct, and the SMTP client is compliant, no
>> protocol error can result.

>However, an RFC 2821 server will NEVER generate such a code, as it is
>undefined.

Wrong. RFC 2821 does not state 'NEVER' (MUST NOT), but states SHOULD NOT.
As previously mentioned, a code such as 556 isn't truly undefined, as
the client knows from the first digit what to do (and it MUST respond
correctly to the first digit), and additionally knows from the second
digit it's a mail system status.

>> You really need to quote some text to support your contentions. According
>> to the RFC, you're zero for two.

>And you fail to understand the term "reserved for expansion and/or future use."

You fail to understand the difference between MUST NOT and SHOULD NOT.
--
-Mike

Re: What is SMTP status code 556?

"D. Stussy" writes:

>> Actually, 550, not 554, is designated for rejection for policy reasons.

>In response to "MAIL FROM:" or "RCPT TO:", 550 is correct. However, following
>"DATA", 554 is the code to use.

RFC 2821 is somewhat ambiguous here. It lists 550, not 554 as a policy
reason rejection code. In the command line sequence portion they don't
list 550 as a possible response (probably because they didn't consider
policy rejection as a response to a DATA command - that is detecting spam
or something), but do list it as possible response when discussing error
responses to the DATA command. That's the problem with interpreting many
RFCs, many things are ambiguous. If coding a SMTP server which may reject
a message based on some policy reason based on the message data, you might
use a 554 response while I might use a 550 response. That's why the
clients must be broad in what they accept, both are correct.
--
-Mike

Re: What is SMTP status code 556?

Post removed (X-No-Archive: yes)

Re: What is SMTP status code 556?

Post removed (X-No-Archive: yes)