[CONFIRMED] [7.380] Missing "INFO-302 New Firmware Up2Date installed" notification

same here.

hmm, now that you mention it, i had the same.

The reason for this is the reboot after the up2date installation. The smtpd is not restarted in time after the up2date installation to receive the notification, so the notification email is queued by the notification daemon. Unfortunately, this queue is temporary and deleted during the reboot, so there is no retry possible. We'll see on monday how we can fix this.

Cheers,
 andreas

Didn't receive the notification after installation of 7.385, too.

Cheers,
Bastian

That's because we didn't fix it. I did a closer investigation and noticed that there is a bug concerning the notification queue and dynamic/multi-part notifications, resulting in a potential notification loss of queued notifications. Depending on the up2date (smtp server might be down during up2date) and the configuration of the ASG (using external SMTP host for notifications, or load of local SMTP server), if the INFO-302 notification can't be successfully sent at once it will get queued, resulting in a loss.
Additionally, if the up2date contains a reboot, the situation is even worse, since the notification queue is not retained through a reboot. The notification queue is not meant to be a safe mail queue (there are _real_ queueing systems in the SMTP daemons for this), so if the notification can't be sent to the smtp daemon before the reboot it is lost too.
Concerning the first part, this is a real bug and will be fixed (but not sure if this will happen in 7.400 though). The latter part is 'by design' - in regular use, queuing will be rarely necessary, and the race condition against the system reboot can't be avoided easily.

Cheers,
 andreas

Andreas, I'm guessing this is related, so I'm posting it here...

in 7.386, if I have a gmail address as one (of two) of my 'notifications' addresses, gmail rejects it (as I have a dynamic IP. fine.)
However, there is no sign of the message in the Mail Manager.

I believe in older versions that bounced notifications would show up.

Thanks,
Barry

Hi Barry,
it's unlikely this is related to the previous postings. When the notification has been delivered to a real SMTP server (either the local exim, or a remote SMTP host) which tries to deliver it to gmail, it depends on the sender configuration what happens with the bounce. If the default sender is used (Management->Notifications->Sender, do-not-reply@fw-notify.net), the bounce will be delivered to this address which is configured to blackhole everything. If you configured a sender address which refuses to accept the bounce it will become a "frozen bounce" and (at least on the ASG) be deleted. If the sender address is valid and accepts the bounce, you will see it in your inbox. At least that's how Tom explained it to me [:)]

Cheers,
 andreas

Hi Andreas, it's not a bounce, but a 5xx error which results in a rejection, so the email should still be in the queue on Astaro, or Astaro may be trying to bounce it.

I have the sender set to do-not-reply@mydomain.dyndns.org atm.

Thanks,
Barry

Hi Barry, 
in your notification settings, you did not configure a remote SMTP server? If so, you should see everything in the smtp.log; that the notification has been delivered to the local exim process, that the exim tried to deliver the notification to gmail but got a 5xx error, and there should also be something about what happened to that mail afterwards. Can you please post the relevant log lines?
Thanks,
 Andreas

I don't have a remote SMTP server right now...

Gmail.com said '550', that is in the log, but it's not clear what happened to the message on the firewall after that; it wasn't showing in the mailqueue in the proxy manager.

2009:01:27-16:48:38 fw exim[13498]: 2009-01-27 16:48:38 SMTP connection from [127.0.0.1]:44399 (TCP/IP c
onnection count = 1)
2009:01:27-16:48:39 fw exim[13525]: 2009-01-27 16:48:39 [127.0.0.1] F= R= Accepted: from relay
2009:01:27-16:48:39 fw exim[13525]: 2009-01-27 16:48:39 [127.0.0.1] F= R= Accepted: from relay
2009:01:27-16:48:39 fw exim[13525]: 2009-01-27 16:48:39 1LRybf-0003W9-0l  me@mydomain.net
 R=dnslookup T=remote_smtp H=mail.mydomain.net [216.65.48.66]:25 X=TLSv1[:D]HE-RSA-AES256-SHA:256
2009:01:27-16:48:51 fw exim[13531]: 2009-01-27 16:48:51 0zrDsI-0003W9-0l Completed
2009:01:27-16:49:19 fw smtpd[13529]: SCANNER[13529]: Nothing to do, exiting.
2009:01:27-16:49:21 fw exim[13532]: 2009-01-27 16:49:21 0zrDsH-0003W9-0l ** me@gmail.com R=dnsl
ookup T=remote_smtp: SMTP error from remote mail server after end of data: host gmail-smtp-in.l.google.com [209.
85.199.114]: 550-5.7.1 [76.83.x.x] The IP you're using to send mail is not authorized\n550-5.7.1 to send email
 directly to our servers. Please use the SMTP\n550-5.7.1 relay at your service provider instead. Learn more at\n
550 5.7.1 mail.google.com/.../answer.py
2009:01:27-16:49:21 fw exim[13541]: 2009-01-27 16:49:21 1LRycL-0003WP-2M <> R=0zrDsH-0003W9-0l U=exim
 P=local S=2367
2009:01:27-16:49:21 fw exim[13532]: 2009-01-27 16:49:21 0zrDsH-0003W9-0l Completed
2009:01:27-16:51:42 fw smtpd[3735]: MASTER[3735]: (Re-)loading configuration from Confd

email and domain names and IP changed to protect the guilty

Thanks,
Barry