Unknown Non-Delivery Reason (520)

[rex007can]

Could someone please explain this message?
It's the second time a user reports getting this error while sending, and I can't figure out who's end is at fault.
(And both were trying to email important board of directors people (why always them?))

----------------------------- ERROR REPORT -----------------------------
Message could not be delivered to the following recipient:

user.name / internet
DDT1=RFC-822; DDV1=user.name@domain.com;

because: Unknown Non-Delivery Reason (520)
------------------------------------------------------------------------

[rex007can]

Okay. I'm getting this from 2 other destinations now.
It's not funny anymore!

[rex007can]

Hello?
Nobody has ANY idea what a 520 error stands for?
I have a hard time believing that.

[ScalixSupport]

I found this doing a google search:

http://www.imc.org/ietf-smtp/old-archive/msg01148.html

11.5 Receiving characters with the high octet set without prior
agreement for enhanced (especially 8-bit) transport.

As mentioned above, sending SMTPs MUST NOT transmit octets with the
high bit non-zero without first successfully negotiating 8-bit
transport with the receiver. Receivers are not required to enforce
this requirement, but should be sufficiently robust to avoid serious
failure if the requirement is violated by a sender. If a receiver
detects octets with the high bit set after a DATA command, it MAY
reject the message with a 520 error code, indicating an attempt to send
invalid data over the transmission channel. This message SHOULD NOT be
sent until the terminating CR LF . CR LF is received. In any event,
senders and receivers MUST NOT impute successful negotiation of 8-bit
transport from the use of DATA with 8-bit characters, since other
requirements may not have been met.

These principles generalize to transport of extended-length characters
involving multiple octets. In those cases, sending without negotiation
and acceptance by the receiver is likely to cause very severe problems;
it is not clear that it is possible to make a server adequately robust
against the sending of arbitrary chunks of bits as "characters" of
unknown character set and origin.

So, please provide more information. What version of the server? What client are you using to send? Can you send to that domain with a telnet smtp session? What is the receiving mta? What language are you trying to send.

Thanks,
Don

[rex007can]

I don't know what the receiver's email systems are. There are more than one, all from different companies, most of them financial companies or investment banks.

As far as I can tell it's either
7.5 Receiving characters with the high octet set without prior
agreement for 8-bit transport.

OR

The <qhlo-id> in the client's QHLO command MUST match the <qhlo-id> issued by the server in its <qsmtp-greet>, or the <qhlo-id> that the server would have issued in its <ehlo-ok-rsp> response to an EHLO command from the client. If the <qhlo-id> matches, the server SHOULD respond with a <qhlo-ok-rsp> response. If the <qhlo-id> does not match there are two possible responses: if the server has already listed its supported service extensions (e.g. in a <qsmtp-greet>) it responds with a "520 Please use the correct QHLO ID" response; otherwise (e.g. after STARTTLS or AUTH) it responds with a <qhlo-long-no>, which includes the list of extensions supported by the server.

But both of those refer to the SENDER being responsible. I guess the destinations are particularly sensitive to that. I don't know. And frankly, it doesn't matter to me. Bottom line is, I'm the only company they deal with who uses Scalix, and I'm the only one having these problems. So chances are...it's us.

But since the people I'm having these problems with are our investors, board members and so on (important people) I kind of have to do someting about it.