Jump to content

[Resolved] Problem when reporting to quick address


dbolt

Recommended Posts

Hi all,

I have updated my amavisd conf to send all spams (hits > 10) to a specific mailbox. Then, I wrote a PERL scri_pt to report all these messages to my quick report address.

Problem, I always receive the following feedback from the parser:

SpamCop.net
Here are the results of your submission:

  Processing spam:

  From: 
  Subject: 

  error:No IP found

I checked the headers (and particularly took care to let a blank line between the headers and the body). Amavisd does not detect those emails as having bad headers. Moreover, if I just copy/paste the email content in the "Process spam" textarea, it works well.

Example: I sent this email (full debug from PERL): Debug trace and I received the error message above. Then, I pasted the content in the textarea and it worked: Tracking URL

Do you have any idea regarding what I am doing wrong?

Thanks,

Dbolt

Link to comment
Share on other sites

I wonder if the "Removing whitespace from mangled header" message from the parser seen when using paste-in submission has anything to do with it? I'm seeing tabs (hex 09) as well as spaces (hex 20) in the continuation line indents. Maybe the form is more forgiving than the e-mail extraction of attachment from envelope when you quick report?

P.S. either tab or space(es) at the start of the continuations should be OK as far as I know but both may be problematical. I haven't been able to replicate the 'whitespace' message but have generated other minor (parsing) glitches using both so there COULD be envelop extraction complications for SC systems as well.

Link to comment
Share on other sites

Thank you, you were perfectly right. I removed unexpected whitespaces before normal tabs and it now works.

I don't understand why whitespaces are not automatically removed by the parser through the quick address...

Link to comment
Share on other sites

I don't understand either - except that the parser has never attempted to follow all the non-RFC convolutions used by consumer-grade mail clients to "improve the experience", so too perhaps for the pre-processing/extraction from envelope steps. One could wish otherwise if that's the case but ...

Anyway, thanks for feedback, that is good news, adding to the topic title and marking "Resolved" to assist any later searches for solutions in this area.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...