I posted a bug report for the 4.2.11 beta titled T9: [4.2.11] Alerts From Field Not Saved.... The bug was verified by Chewbacca but the issue was never addressed. The follow up question in that thread about other E-Mail address configuration issues was also never addressed.
Is this bug going to be fixed fixed for this next release? (My ReadyNAS NVX is in production mode so I can't test this new beta myself at this time.)
Regards, Ian.
EDIT: Subject adjusted to remove version number to indicate the issue affects *many* builds.
This bug appears to have fallen through the cracks. The new 4.2.12 public release *still* does *NOT* have this bug fixed.
In fact the problem is now worse. When the Internal mail provider is selected the From field is enabled but the value entered is not saved or used. This was the original bug. Now, if the Custom mail provider is used then the From field is now disabled so an entry can now not be entered. I found a hack work around but I really hope the Jedis will fix this bug quickly. I would rather not use another E-Mail server to relay the ReadyNAS messages.
The work around is to select the Internal mail provider to enable the From field and add the From address then immediately switch to the Custom mail provider to enable the SMTP server and port fields. The From field will still be present but is now disabled and dimmed but the value just entered will be present. Enter the SMTP server and port details and save the settings. This will cause *all* the settings, including the From field to be saved. The nominated SMTP server will now be used as will the From field.
While I am highlighting these Alert area bugs I would also like to take this opportunity to again mention an issue I posted in the "Public RAIDiator Beta for ReadyNAS NV+/Duo/1100" area:
Something that could really be helpful would be a description or listing of the validation rules used by Frontview to validate any and all E-Mail addresses entered into the UI.
I, for example, would like to enter an E-Mail address like "ReadyNAS No3 <myemail@isp.com>" into Frontview, That is the E-Mail address to be used is "myemail@isp.com" but the from/to display tag to be used is "ReadyNAS No3". This would allow me to quickly identify what ReadyNAS was responsible for sending what E-Mail messages. Needless to say Frontview does not appear to support this standard form of E-Mail address.
What would be even better than explaining how E-Mail addresses are currently validated would be if the Jedi team could update Frontview to allow all forms of RFC5322 compliant addresses.
This issue equally affects the 4.2.12 generation of firmware. I suspect they use similar validation code rules.
Can I please have an answer to the validation rules question and some acknowledgement that these Alert bugs will be fixed (Chewbacca has already confirmed the bug report)?
I will have our engineer look into your validation question.
I tried with 4.2.12
With internal From: Should be greyed out.
There is a issue with setting to custom and that the From: is still greyed out and can see the work around you are using and I will have our engineer look into this issue.
I will have our engineer look into your validation question.
Thank you. I hope they will also consider updating the validation rules to comply with current RFC standards.
Chewbacca wrote:
I tried with 4.2.12
With internal From: Should be greyed out.
Why is this the case? In the past the field was enabled but just not saved. The From field should *always* be available and used if defined. Please ask your engineers to reconsider removing this facility and rather fix it instead.
Chewbacca wrote:
There is a issue with setting to custom and that the From: is still greyed out and can see the work around you are using and I will have our engineer look into this issue.
Any news on a means to resolve this as this is the way that most of us monitor our NAS and without the alerts we can miss problems that are developing!!!!
With Custom the bug regarding no ability to access the From field has now been fixed.
With Internal the SMTP server and port fields are cleared and then locked out. The From field contents are greyed out and left visible/active. When the settings are saved the From field still has data. Visit another area in Frontview and come back now the From field is blank.
The From field should not be an Advanced Settings. It should be enabled and used at all times. *All* E-Mail must have From and To addresses! They are part of the fundamental communications with the SMTP gateway. For various reasons the From should not be locked to be the same as the To address. By all means default the From field to be the same as the To field but always allow it to be shown and edited/changed.
Also, the questions regarding the format and validation of all E-Mail addresses in Frontview has not been covered. The validation is certainly not compliant with RFC 5322 (or previous versions of this RFC).
With 4.2.20 now in development can this issue finally be investigated with a view to resolving the issues and enhancing/explaining the validation rules.
Yoh-Dah indicated in a PM to me that this would be considered.
I don't know if this issue has yet been addressed in current development code. In case this is still not being fixed I thought I should add a new twist that deserves consideration.
Recently I discovered that my IP address has been listed by Spamhaus in their CBL list for creating Internet SPAM. While I was quite surprised I took the listing seriously. A few days of intensive virus checking and I could not find any virus based cause for the listing. As a precaution I disconnected some new networked appliances to see if the situation changed. It didn't. In desperation I programmed my switch into promiscuous mode and used a PC running WirShark to log all SMTP traffic getting out of my network. When I converted the WireShark logs to real time reporting I was able to match activity in the CBL SPAM reports to my ReadyNAS backup schedule. I discovered that it was my ReadyNAS units sending me the backup logs that was causing the listings!
I used the "Internal" option for "Email Provider" setting in the "System > Alerts > Contacts" setup to send all NAS alerts to my gmail account. Because RAIDiator doesn't allow the From option to be used the alerts were being sent from the ReadyNAS mail service addressed to my "Alert Contact 1" gmail account and marked as coming coming from the same account. (To restate the bleeding obvious, in the current RAIDiator releases using the Internal mail service you can't set the "From" address so the "Alert Contact 1" address is used as the "From" address.) This is seen by Google as SPAM and appears to trigger a Spamhaus listing!
As a work around I have switched to the "Custom" option for "Email Provider" and used a different "From" address from the "Alert Contact 1" address. I inject these messages into my ISP's SMTP server. These messages are now received by Google as valid and are no longer flagged as SPAM.
For various reasons I would rather not bounce these messages via my ISP's SMTP gateway (or any other gateway) but would prefer the RAIDiator Internal gateway be fixed so that it provides appropriate headers that do not trigger SPAM listings. The Internal gateway is fully up to the task it is just that the RAIDiator configuration is forcing poor choices to be made.
Please Netgear isn't it time to review the Alerts and Email functions in *all* the RAIDiator builds with a view to making the system RFC compliant and SMTP friendly.
