Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#87 closed defect (fixed)

Problem rescuing mail tagged as spam.

Reported by: maia@… Owned by: rjl
Priority: normal Milestone: 1.0.0 RC6
Component: PHP scripts Version: 1.0.0 RC5
Severity: normal Keywords: smtp_send crlf linefeed carriage return rfc
Cc: maia@…

Description

After rescuing an e-mail that was tagged as spam, the e-mail is kept in the spam cache, although it is sent through to the MTA (Postfix in this instance).

Errors are generated in the Postfix log file. I'll try to attach the e-mail and the messages from Postfix.

The e-mail was exported with the SQL statement of

select contents from maia_recipients where mail_id=id into outfile '/tmp/filename';

Attachments (2)

postfix.error.eml (2.3 KB) - added by maia@… 16 years ago.
Postfix message
problem.email.eml (15.5 KB) - added by maia@… 16 years ago.
The problem causing e-mail

Download all attachments as: .zip

Change History (13)

Changed 16 years ago by maia@…

Postfix message

Changed 16 years ago by maia@…

The problem causing e-mail

comment:1 Changed 16 years ago by maia@…

Actually,

select contents from maia_mail where mail_id=id into outfile '/tmp/filename';

but you probably already figured that out. ;)

comment:2 Changed 16 years ago by dmorton

Which version are you running?

comment:3 Changed 16 years ago by anonymous

  • Version set to 1.0.0 RC5

Grr...why did I not think to mention THAT. Sorry. It's early...(lame excuse, I know).

Version 1.0.0 RC5

comment:4 Changed 16 years ago by rjl

Could be a dot-stuffing issue; i.e. the mail begins with a '.' on a line by itself, which fools Postfix into prematurely thinking the mail has been completely received. i.e. https://www.renaissoft.com/cgi-bin/trac.cgi/ticket/29 29

Could also be a CRLF issue, since I note that QMail is involved. i.e. https://www.renaissoft.com/cgi-bin/trac.cgi/ticket/28 28

Are the '\' characters at the end of every line actually in the original e-mail that amavisd received, or were those added as a side-effect of cutting and pasting to Trac?

comment:5 Changed 16 years ago by rjl

Ignore that last question--you've already explained how you got the e-mail contents from the database, so I can presume it was received that way by amavisd (since amavisd stores the original mail unaltered).

That being the case, those '\' characters certainly should not be there. The fact that they appear after every line (including the latest "Received:" header) suggests that it's something being done by amavisd prior to storage. Do you have the Blowfish encryption feature enabled by any chance?

comment:6 Changed 16 years ago by maia@…

I didn't think I had it enabled--when I checked the system configuration page, I saw the field 'Encryption key file (optional):' had blowfish.key in the box. Peculiar since I don't remember adding that (I know I never generated the key).

I've since emptied that box and I'll check for more cached ham/spam to see what if those slashes remain. I thought that was fairly odd that they were added. (Other than that one e-mail, I've not noticed any problems at all with Maia--I like how in that "problem e-mail" it states 'misconfigured sender' in the headers).

Odd that that's the only one to get "stuck" out of many many e-mails processed by Amavis/Maia?.

I also thought it possibly could be the 'dot-stuffing' issue like #28, but not being certain, I filed this new ticket.

It just dawned on me that that e-mail was retrieved by fetchmail from my Comcast.net account...

The other mail software and versions used are: Postfix 2.1.4 Cyrus-IMAP 2.1.6 Fetchmail 6.2.5

comment:7 Changed 16 years ago by maia@…

FWIW: After removing "blowfish.key," newly cached e-mails still have slashes in them when using an SQL query such as:

select contents from maia_mail where id=105394 into outfile '/tmp/mail.txt';           

Without dumping the contents to a file, i.e. just looking at the results of the query from the MySQL prompt, the slashes do not appear. Interesting...

comment:8 Changed 16 years ago by dmorton

How is the status of this sticket in newer versions?

comment:9 Changed 16 years ago by Ed <maia@…>

(Sorry for not replying sooner, I didn't notice the update to this ticket until browsing the open ones just now.)

The last time this problem came up was on 2-Jan-05, but at that time I was still using 1.0RC5. Sometimes a few weeks will go by before I have an e-mail caught as spam that'll generate this kind of errors.

Last week I had upgraded Maia to the trunk version.

Just now I have removed certain senders that had given me problems in the past from the whitelist. I even wrote some custom SpamAssassin rules to ensure they'll be caught. :)

I'll let you know what the end result is.

comment:10 Changed 16 years ago by Ed <maia@…>

  • Keywords smtp_send crlf linefeed carriage return rfc added
  • Milestone set to 1.0.0 RC6
  • Resolution set to fixed
  • Status changed from new to closed

The problem seems to have been fixed with the newer versions. It's been nearly a month since I upgraded my installation to the svn version and the original problem has not reared its ugly head again.

It seems this have been fixed by [472], just as #28 & #29 had been.

Setting status to closed (if I'm in error by doing so (since I'm not one of the developers), please let me know).

comment:11 Changed 16 years ago by dmorton

Good to hear!

Note: See TracTickets for help on using tickets.