5.7.1 <DATA>: Data command rejected
Closed, ResolvedPublic


Email is not sent to recipient.

Error in logfile:
postfix/submission/smtpd[3351]: 447D82CBEF: reject: DATA from unknown[xxx:xxx:xxx:xxx]: 554 5.7.1 <DATA>: Data command rejected: Sender access denied; from=<> to=<> proto=ESMTP

Working workaround:
Extend size of the sender and recipient field from varchar(64) to varchar(255) in table policy_result

MariaDB [kolab]> drop table policy_result;
MariaDB [kolab]> CREATE TABLE policy_result ( id int(11) NOT NULL AUTO_INCREMENT, key varchar(16) NOT NULL, value tinyint(1) NOT NULL, sender varchar(255) NOT NULL, recipient varchar(255) NOT NULL, sasl_username varchar(64) DEFAULT NULL, sasl_sender varchar(64) DEFAULT NULL, created int(11) NOT NULL, PRIMARY KEY (id), UNIQUE KEY fsrss (key,sender,recipient,sasl_username,sasl_sender) ) ENGINE=InnoDB AUTO_INCREMENT=119 DEFAULT CHARSET=utf8;

mail:~ # rpm -qv pykolab

Event Timeline

izidor created this task.Mar 6 2017, 12:20 PM
machniak added a subscriber: machniak.

Indeed according to RFC3696 and the address length limit is 254 characters.

emunson added a subscriber: emunson.Nov 2 2017, 4:28 PM

My kolab install is rejecting emails from Amazon because of this bug. The logs when such an email arrive show:

Oct 21 09:57:41 machine postfix/smtpd[24703]: connect from[]
Oct 21 09:57:42 machine postfix/smtpd[24703]: 48F995CADD9:[]
Oct 21 09:57:42 machine postfix/smtpd[24703]: 48F995CADD9: reject: DATA from[]: 554 5.7.1 <DATA>: Data command rejected: Recipient access denied; from=<> to=<user@domain.tld> proto=ESMTP helo=<>

emunson added a comment.EditedNov 2 2017, 4:46 PM

For others who might run into the same issue, the above sql does not work. after fixing the syntax because md had interpreted the backticks, it left me unable to send or receive mail. I had to delete the table and let pykolab recreate it.

Using ALTER TABLE to adjust the columns after it was recreated did work for me.

sicherha raised the priority of this task from 60 to High.May 31 2018, 9:04 AM
sicherha added a subscriber: sicherha.

Raising priority because this bug causes data loss: emails are getting rejected.

Okay, so we have to modify the database schema. In it is suggested that the statistic table should also be altered, which looks plausible to me.

Can somebody confirm that both policy_result and statistic contain only temporary data and can be dropped at any time without bad things happening? That would make the upgrade path relatively simple: just include a post-install script in the .deb/.rpm packages that drops these two tables if they exist.

The above patch was the simple part; now we need a script that gets called when the package is upgraded and drops the respective tables. I assume it's okay to drop the tables whenever the PyKolab package gets an update - please veto if you disagree.

I see two options:

  1. Write a new script from scratch solely for that purpose.
  2. Add a command-line option (say, --drop-tables) to the kolab_smtp_access_policy script. If that flag is passed, the script drops the tables and exits immediately.

Any opinions?