Dovecot LDA error - Invalid -f parameter: Invalid character in path
Hi list. I'm using dovecot as postfix's LDA. The version is 2.3.6. Last week some spammer set the envelope's FROM to "foo@bar@domain.com" (with two @). While trying to deliver (as this one didn't hit the spamassassin's score), dovecot said the following:
Jun 21 02:35:58 mymailserver postfix/pipe[29736]: ADA268195E: to=<user@mydomain>, relay=dovecot, delay=0.08, delays=0.03/0.02/0/0.04, dsn=5.3.0, status=bounced (command line usage error. Command output: lda: Fatal: Invalid -f parameter: Invalid character in path )
Which caused postfix to put it on the bounce list, but the spammer's destiny don't really exist.
I could successfully mimic the spammer using telnet and putting two @ in "mail from" address. I don't think this should be an expected behaviour, right? Or is this some config based error?
Thanks!
Hi Bruno,
Am 24.06.19 um 17:05 schrieb Bruno de Paula Larini via dovecot:
I'm using dovecot as postfix's LDA. The version is 2.3.6. Last week some spammer set the envelope's FROM to "foo@bar@domain.com" (with two @). While trying to deliver (as this one didn't hit the spamassassin's score), dovecot said the following:
Jun 21 02:35:58 mymailserver postfix/pipe[29736]: ADA268195E: to=<user@mydomain>, relay=dovecot, delay=0.08, delays=0.03/0.02/0/0.04, dsn=5.3.0, status=bounced (command line usage error. Command output: lda: Fatal: Invalid -f parameter: Invalid character in path )
Which caused postfix to put it on the bounce list, but the spammer's destiny don't really exist.
I could successfully mimic the spammer using telnet and putting two @ in "mail from" address. I don't think this should be an expected behaviour, right? Or is this some config based error?
No, this is a bug in Dovecot's logic tracked internally at Open-Xchange AG / Dovecot OY as DOP-1045.
Dovecot LDA and LMTP should just not care about remote address validity when delivering locally. It's not the LDA's business.
See <6386018f-22b2-9562-b5a2-36e81cbe2892@debian.org> (bounces on invalid UTF-8 in localpart) for my error report from March. There have been multiple other users asking about this on the ML, too.
Kind regards, Daniel
participants (2)
-
Bruno de Paula Larini
-
Daniel Lange