-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with parsing non-standard To address in header. #169
Comments
Hi @jwp72 -- ooh, that's very interesting. You can get the raw header value by calling For both you should still be able to call |
I thought the issue was related to the format of the to: section of the header, but it seems it is bigger than that. The issue seems to happen specifically with lower end multi-function printers. There seems to be no consistency with adherence to RFC standards. The mail will deliver to standard mail servers, but it fails when we send to an endpoint that we created that uses your mime parser. We are trying to figure out how we can get some logging from your plug-in in order to determine where the issue lies. |
Unfortunately there's no error reporting or logging at the moment. A proposal for error reporting was made in #124 -- that and logging were hoped to be part of 2.0 but won't make it in. Best way at the moment is to attach a debugger and see what happens, sorry. |
Having an issue with receiving non-standard formatted to: in the header of a message from cheaper multi-function printers with a scan to e-mail function. The format is either "\"\" <[email protected]>" or "[email protected]". The first is a blank display name, and the second is just not in the correct format. When the message is received it either fails parse the to: or returns an empty response. We are only interested in the actual e-mail address, but since the response is empty we are stuck. Any ideas?
The text was updated successfully, but these errors were encountered: