Ironport enhanced smtp status code

look like this:

501 #5.1.1 bad address

As I read rfc2034 the leading # symbol is non compliant. Am I correct
and is this on purpose?

Thanks,

Joe

Re: Ironport enhanced smtp status code

jmaimon@ttec.com wrote:

> look like this:
>
> 501 #5.1.1 bad address
>
> As I read rfc2034 the leading # symbol is non compliant. Am I correct
> and is this on purpose?
>
> Thanks,
>
> Joe
>

What do you mean?

The error code returned and seen by the connecting server is 501.
#5.1.1 bad address is the explanation that would only be seen by the
sender of the message that just bounced.

AK

Re: Ironport enhanced smtp status code

On Tue, 21 Mar 2006, AK wrote:
> jmaimon@ttec.com wrote:
>> 501 #5.1.1 bad address
>> As I read rfc2034 the leading # symbol is non compliant. Am I correct
>> and is this on purpose?
> What do you mean?

He means that the "#" in the response is non-compliant with RFC 2034.

He is correct.

It doesn't answer why the server is doing it. That "#" prevents an RFC
2034 capable client from interpreting the extended status response.

> The error code returned and seen by the connecting server is 501. #5.1.1 bad
> address is the explanation that would only be seen by the sender of the
> message that just bounced.

There's more to it than that.

Please read RFC 2034.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: Ironport enhanced smtp status code

Mark Crispin wrote:
> On Tue, 21 Mar 2006, AK wrote:
> > jmaimon@ttec.com wrote:
> >> 501 #5.1.1 bad address
> It doesn't answer why the server is doing it. That "#" prevents an RFC
> 2034 capable client from interpreting the extended status response.
>
The reason I ask about the vendors intentions, if anyone would possibly
know them, is because the system does not announce

250-ENHANCEDSTATUSCODES

in response to ehlo

So they do not advertise that they support them. However they use them
in this non-compliant format. Perhaps they simply want to make it
unparseable by machine?

Is this some kind of bs marketing "hardening" or is there some actual
value to it?

Re: Ironport enhanced smtp status code

Mark Crispin wrote:

> On Tue, 21 Mar 2006, AK wrote:
>
>> jmaimon@ttec.com wrote:
>>
>>> 501 #5.1.1 bad address
>>> As I read rfc2034 the leading # symbol is non compliant. Am I correct
>>> and is this on purpose?
>>
>> What do you mean?
>
>
> He means that the "#" in the response is non-compliant with RFC 2034.
>
> He is correct.
>
> It doesn't answer why the server is doing it. That "#" prevents an RFC
> 2034 capable client from interpreting the extended status response.
>
>> The error code returned and seen by the connecting server is 501.
>> #5.1.1 bad address is the explanation that would only be seen by the
>> sender of the message that just bounced.
>
>
> There's more to it than that.
>
> Please read RFC 2034.
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.

Oops,

I stand corrected.

AK

Re: Ironport enhanced smtp status code

In article <1142952405.438497.253700@e56g2000cwe.googlegroups.com>,
wrote:
>look like this:
>
>501 #5.1.1 bad address
>
>As I read rfc2034 the leading # symbol is non compliant. Am I correct
>and is this on purpose?

Perhaps somebody was trying to be compatible with this:

http://cr.yp.to/proto/hcmssc.txt

(for whatever reason, maybe somebody saw #x.x.x codes and imitated it)
and not making it.

mm