[Question]: Consistent Error Messages when Processing Reports #12
Assignees
Labels
Comments
ryanrbftp
added
help wanted
|
To help a bit more - what version of Open Report Parser are you using? What DB and version are you using? |
|
Also, can you run it again with the debug flag ( |
|
Thank you for the response. I can find any version information anywhere or a command line to display such but this is what's present in the Perl file: We grabbed it a couple of days ago from Github. We're running MariaDB 10.1.48. I have run the usual script with the -d flag. Output below. Thank you for your help. |
|
That's helpful, thanks - I'll read through the debug output and see what I can pick out of it. |
|
Alright - one of the reports seems to be missing data in the As for the emails from mimecast - it seems to be failing to unzip the zip files being sent. Is |
|
Thank you for the response. Yes, that did cross my mind but... I had an idea that perhaps it can't write to /tmp/ so that was checked also: Perhaps the Mimecast attachments are in a different compressed format. I don't know. I would have thought there would be an industry standard for DMARC reporting. Any ideas are always greatly appreciated. Many thanks, John! |
|
Okay I've spotted something in your report-parser.pl source. We don't have "ungzip" on our system (Ubuntu). We have either "gunzip" or something like "gzip -d". In fact, I've never come across a "ungzip" executable. I could create a symlink to make it work but better would be to modify the Perl source? Let me know your thoughts and many thanks. |
|
This line seems to tell me it's trying to unzip a .dat file rather than a .zip file - the headers for the related message say that the attachment is a .zip file - perhaps your IMAP server is converting it into a .dat when it gets pulled? What IMAP server are you using? |
|
The |
|
Thanks for the update. I've just logged into the webmail (roundcube) for the mailauth-reports@ account to take a look at the failing reports and can confirm I am able to download the ZIP file from all of the Mimecast reports. I extract them locally and correctly get the XML. IMAP server is Dovecot 2.3.19.1. |
|
Alright, it seems like Mimecast is improperly setting content-type to application/gzip, but they are sending a .zip file. When it makes the attempt to unarchive it using It's frustrating that the wrong file type is being presented. I'll see if I can develop a workaround for this case, as it's not unreasonable for this to occur. |
|
Thanks for the update and digging. Perhaps ignore what the MimeType is set to, download the attachment locally, and then analyze once downloaded using "file" or something. |
userjack6880
pushed a commit
that referenced
this issue
Jul 6, 2023
|
I've pushed an update to the dev branch - pull the code and see if that solves your issue. Instead of ignoring the mimetype, I've gone the route that if it fails to extract the first time, it'll try again with the other method. Let me know if this resolves the issue. |
|
Thanks for actively working on this. Now we are getting: |
|
Ooops. Forgot to rename a variable. The dev branch should be updated and have that fixed. |
|
No probs and thank you! Okay looking good, those Mimecast reports have now been processed and deleted! We still have the wp.pl issue. Perhaps we can run a workaround for this? ... is source_ip really empty? I can't imagine a misconfigured report from someone like wp.pl. I can provide the XML if you would like to work with this. |
|
It is, the result is in the debug output. In fact, it looks like the entire XML they sent had no usable data. The only thing I would probably add is to delete the email, but this would potentially delete email that is useful elsewhere. Perhaps an option to do that could be added. EDIT: as we've seen, a company with MIME in the name didn't properly set MIME type for the file they sent, it's not unreasonable for someone like wp.pl to misconfigure a report. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We recently moved over from the techsneeze parser/reporting interface due to consistent errors when parsing reports.
We are continuing to get report parse errors.
I have included examples below. I have asked this as a question as it may be a problem on our end so any advice, tips, or suggestions to resolve are appreciated in advance. Many thanks!
The text was updated successfully, but these errors were encountered: