Although I have no answer for dash, colon fails might be extractHeaders code taking “Success:” as a header, which will cause the regex to fail because it expects that to be part of the string following a “Subject:” header. Another guess is that the configuration parser which is documented as taking a colon or equals, is confused.
Basically, the Pythex exam is useful, but the regex and the subject line both have to get there as they should.
Thanks, I re-tried with the dash instead of a colon and it works just fine. With this method I can just use
- subjectregex = Duplicati Backup report
and it works great. It definitely doesn’t like the colon for some reason.
EDIT - Note I originally thought this worked, but later realized using the dash broke the source/destination portion. Continue reading below for a fix.
To figure out which of the two reasons it is, you could try adjusting Duplicati and subjectregex to have a space before the colon. I think that will be enough to avoid mistaken identity. Header parser needs a colon attached.
Putting the space before the colon works using the same regex as my last message. I’m sure it would work with the wildcards as well, but it seems unnecessary to me since I’ll never have other emails with those words in the subject in this mailbox.
I think that’s evidence that Duplicati information after the email Subject: string was missing before. Thanks. Maybe dupReport will someday recognize “header” names only at start of the line. Multiline mode might help. Meanwhile, I’m glad you found a workaround that is enough for your situation and for others doing the same.
Thanks for the quick help everyone!
Glad to hear you got it working (mostly) like you want!
Just to be clear, this is what worked for you?
- In Duplicati:
–-send-mail-subject=%PARSEDRESULT% - Duplicati %OPERATIONNAME% report for %backup-name%(Note the dash, not a colon, after %PARSEDRESULT% - In dupReport.py script (of DupReport.rc file):
subjectregex = Duplicati Backup report
That is correct! Only thing to note is the --send-mail-subject needs the 2 dashes at the front in Duplicati, not just one. I’m sure that was just a typo though.
I believe it would also work if you did not put spaces, like %PARSEDRESULT%-Duplicati. I definitely tried %PARSEDRESULT%- Duplicati, which worked with the same regex, as did using a comma instead of a dash.
EDIT - Note I originally thought this worked, but later realized using the dash broke the source/destination portion. Continue reading below for a fix.
1 Like
Hi folks. Sorry I’ve been absent from the conversation, I took a few days off for the holiday.
After a small bit of testing I can confirm @ts678’s theory that the colon in the subject specification is confusing extractHeaders() and it’s seeing “Success:” as a separate header field. This causes the program to parse the header info as follows:
Clearly, ‘Success’ is not a standard email header. DOH!
I will open an issue on the GitHub site for this and see if there is a better way to parse the headers to avoid this problem. Stay tuned…
HG
2 Likes
OK, I think I have a fix for this. I rewrote and simplified the extractHeaders() code to address the “double colon” problem. This will allow colons in subject lines like “Success: Backup for test1-test2: All is well”.
New code has been uploaded to the Issue_103 Branch on GitHub. Please download that code and try it to see if it (1) fixes the colon issue and (2) doesn’t break already-existing installations (if you are using “normal” subject lines.)
I may also have an explanation for the dash (-) issue described above. dR uses the dash as the default source/destination separator (as in <source>-<destination>). If there is an additional dash in the subject line that may throw things off, depending on how it’s used. If you’re really intent on using a dash in the subject and you find it’s not working for you, change the [main] “srcdestdelimiter =” option in the .rc file to some other character, then make sure your backup job names use the new character. Please don’t ask me to provide a similar fix for this “dash” problem, as “<source>-<destination>” is used all over the code base and is not as isolated as the subject colon issue was.
Anxious to see if this gets it right. Please let me know.
HG
JonMike, see handyguy’s comments below. I thought it was working with the dash, but didn’t look closely enough that all of my source/destinations had been stripped from the table, so all backups were being put together in the table as a single blank src/dst.
handyguy, thanks for taking the time to work on this. I can confirm the src/dst did break when I used the dash (I didn’t notice until just today). I can also confirm I downloaded Issue_103 code and using success: is now working for me!
I haven’t fully tested failure: and warning: though. I had one old warning report. The word warning did show up in the table, but the red/yellow formatting and error description isn’t there. I haven’t read up on this section of the guide though, so not sure when the added detail is triggered (maybe only on more recent warnings?). I’ll post back once I have a more thorough test.
Looks like the red/yellow formatting and details only show up for failure reports, not successful reports with warning. If this is the normal behavior, then I just confirmed this is working. Thanks again!
Good to hear that solved the problem. I’ll updated the docs to mention the “dash problem.”
Check the displaymessages=, displaywarnings=, and displayerrors= options in the [report] section of the .rc file. If any of those are set to “false” they won’t show up in the report.
Pushed this fix up to GitHub as part of the pre_prod branch.
Hi, I don´t read anything about configuring email notifications if we have 2fa in our gmail accounts.
I try it with this fantastic thread, and it works. Maybe most of you have a gmail account with 2fa and know how to configure it.
We have to create a new password application in our account preferences and paste it in --send-mail-password=your_application_password instead of your normal password.
hola buena tarde, manejo un proxy en mi empresa y cuando esta activo el proxy no me envía las notificaciones, de lo contrario me funciona perfectamente, ¿alguien le ha pasado? gracias
Gmail will disable connections with password (insecure programs) the only way to send an email via gmail will be with Oauth 2.0 this implies that --send-mail will no longer work with gmail addresses. is there a plan to improve --send-mail to integrate OAuth2.0 authentication
Thank you.
Gmail will disable access to unsecure programs was posted as a new topic a few minutes after above. Probably best to continue there to figure out what’s up (reply made, awaiting reply) than continue here.
Crossposted from the other thread:
Fairly sure this is a non-issue. The notice is about “account access”, not email send authentication. This quote directly from the original Google notification:
No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails.
Further, if the receiving account is Gmail or GSuite, you don’t need to authenticate at all.