Page MenuHomePhorge

5.7.1 <DATA>: Data command rejected
Closed, ResolvedPublic

Description

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=<xxxxxx@xxxxxxxx.cz> to=<58aefd42e4b07b4b260704ee166b7edb-b261-aaaa-aaaa-efb2a1bc3db6@mail.smartrecruiters.com> 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
pykolab-0.7.20-6.4.noarch

Details

Ticket Type
Task

Event Timeline

machniak subscribed.

Indeed according to RFC3696 and https://www.rfc-editor.org/errata_search.php?eid=1690 the address length limit is 254 characters.

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 a13-34.smtp-out.amazonses.com[54.240.13.34]
Oct 21 09:57:42 machine postfix/smtpd[24703]: 48F995CADD9: client=a13-34.smtp-out.amazonses.com[54.240.13.34]
Oct 21 09:57:42 machine postfix/smtpd[24703]: 48F995CADD9: reject: DATA from a13-34.smtp-out.amazonses.com[54.240.13.34]: 554 5.7.1 <DATA>: Data command rejected: Recipient access denied; from=<20171021135739619e64957d31417aa1e1f80192a0p0na@bounces.amazon.com> to=<user@domain.tld> proto=ESMTP helo=<a13-34.smtp-out.amazonses.com>

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 subscribed.

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

Okay, so we have to modify the database schema. In https://kolab.org/hub/topic/260/google-mails-rejected/4 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?