Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I have been lurking in this forum for a while and recently bought a DNS-323 (due to the hacking wisdom found here) and have been experimenting with ffp 0.5. I too have the email alert failure problem with account login since upgrading to firmware 1.06. I have figured out why this is failing.
The DNS firmware uses msmtp to send mail, and the configuration file that the web gui sets up is at /.msmtprc
I added the line
logfile /.msmtp.log
to the config file to log the SMTP connection, but .msmtprc is updated by the firmware every time email is sent. I got around this by using
chattr +i /.msmtprc
With my AT&T DSL connection, the test email fails and the msmtp log showed
Jan 04 09:41:22 host=smtp.att.yahoo.com tls=off auth=on user=***@sbcglobal.net from=***@sbcglobal.net recipients=***@sbcglobal.net errormsg='cannot use a secure authentication method' exitcode=EX_UNAVAILABLE
Further searching on msmtp revealed that it will not use a non-secure login method by default, which is what the error is indicating. The .msmtprc file that the DNS firmware creates contains the line
auth on
and by changing it to
auth plain
my email alerts now work with account login. The only issue is I have to leave this file with the +i attribute otherwise the changes get overwritten. I understand that the / mount point is also a ramdisk so this would not survive a reboot either.
I'm sure others who have better understanding of the platform can probably figure out a way to create a more permanent fix.
Offline
The similar problem was and for me!
Dares usage anonymous SMTP a server and inclusion of an anonymous mode on DNS.
Good luck!
Offline
Note that I had to create the workaround since AT&T does not allow anonymous SMTP access. Note that you can use msmtp to query your SMTP server to see what authentication methods it supports.
/ # msmtp --serverinfo
SMTP server at smtp.att.yahoo.com (smtp1-f.sbc.mail.vip.mud.yahoo.com [68.142.19
8.11]), port 25:
smtp103.sbc.mail.mud.yahoo.com ESMTP
Capabilities:
PIPELINING:
Support for command grouping for faster transmission
AUTH:
Supported authentication methods:
PLAIN LOGIN
/ #
msmtp will not allow SMTP authentication to be sent in the clear by default. From their documentation:
By default, msmtp chooses a method automatically, and it will never choose one that puts the authentication data at risk.
If msmtp chooses the method itself, it will never choose an insecure method. If TLS is active, all methods are considered secure in this context, because the connection to the server is protected by TLS. If TLS is not active, only the CRAM-MD5, DIGEST-MD5, and GSSAPI methods are considered secure in this context, because all the others methods put the authentication data at risk.
If you really want to risk your authentication data, you have to force msmtp to do that by manually setting the authentication method while TLS is off.
So that is why in my case I had to change the auth parameter from on (i.e. automatic) to plain.
Offline