Sendmail+Cyrus IMAP "Data format error" and bounces

Andrea Venturoli ml at netfence.it
Tue Mar 17 08:49:44 EDT 2020


On 2020-03-17 11:58, Deborah Pickett wrote:
> Hi Andrea,

Hello and thanks a lot for your interest.
Finally I get some useful information on this!





> The status 5.6.7 seems to be related to encodings.  It's defined in RFC 
> 6531, SMTP Extension for Internationalized Email:
> 
> When the SMTPUTF8-aware SMTP
> server supports enhanced mail system status codes [RFC3463], reply-
> code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII
> addresses not permitted for that sender/recipient".
> [source: https://tools.ietf.org/html/rfc6531#section-3.5]

Please allow me to explain what I understand, then:

_ sendmail is SMTPUTF8-aware (this is confirmed by EHLO); however Cyrus 
isn't?

_ 5.6.7 means either the sender or the recipient is not ASCII:
   however I can see for sure that, at least in certain cases, the 
recipient is in fact ASCII (all my addresses are);
   possibly the sender isn't: altough in the logs I see an ASCII 
address, it might not be and it gets *represented* in ASCII? I'd find 
this strange, though;

_ or, possibly, other headers are non ASCII: that's what I thought prior 
to your mail and it still seems more probable to me, but then I should 
see 5.6.9 (or 5.6.8?), not 5.6.7.

Correct?



In any case, I'm fine if these messages are plainly rejected; I'm not 
fine if they are accepted and then bounced.
I guess this means the problem lies between sendmail and Cyrus, with the 
former accepting it and, only afterwards, the latter refusing it.
Any way to configure one of the two to avoid this?




> Do all of the failures have proto=UTF8SMTP(S) in them, or just this 
> example?

Yes, they do.




> I agree with them that your anonymization of the log with xxx may have 
> masked important information.

Unfortunately I have to. If both ends were mine, I'd have no problem, 
but I cant' violate the privacy of others.

> There may be temporary DNS failures going on but it's impossible to tell.

I don't question this statement; however, this is irrelevant.
AFAICT, the eventual DNS failure might cause the bounce to fail; however 
that's not my concern: I want to avoid the bounce in the first place.
Or is something slipping me through?

I can provide (alas anonymized) samples of logs where the bounce does 
not fail, if needed.


  bye & Thanks
	av.


More information about the Info-cyrus mailing list