My feeder 205212 sent a feeder outage message as configured, but the postmaster of the email service web.de rejected it because ill-formatted headers. Missing outage messages may leed to loosing a streak, which is what might have happened to my feeder 36563 2117 days streak. Here is the error message of the postmaster:
554 Nemesis ESMTP Service not available Transaction failed Reject due to policy restrictions.
Reason
Please note that, if your email header is not RFC 5322 compliant, your message will be rejected by our system.
In your case, the information in the date header is syntactically incorrect or the time information deviates too much from the actual time.
Solution
Ensure that your server and client have the correct time configuration (date, time, time zone) to prevent any significant difference from the actual time appearing in the date header
Please also check the date header field for correct syntax, according to the RFCs.
As soon as the corrections have been made by you, you can deliver emails to our system again.
The policy is unfortunately not useful without a copy of the message (to check if there’s anything obviously wrong) or a specific reason for rejection. AFAIK nothing has changed on our side and we regularly send out a high volume of email with no significant problems.
I’d point out that requiring a close-to-current-time Date header is a losing strategy unless the bounds are very large; SMTP is a store-and-forward protocol, so in cases where the mail isn’t immediately deliverable, the Date header could be hours – or even days, in extreme cases – old.
I included it so that you can see if there is anything straight away which falls foul of it, based on how FlightAware constructs its outage notification emails.
It seems to me to be an overly strict policy, over and above RFC obligations, which would result in a lot of rejected email for their customers and making their email service not very practical.
Sorry, I do not have a copy of the message as it was not delivered to me, but rejected by postmaster. It should be a standard, automated feeder outage message delivered when the ADSB receiver does not send data for the past 6 our 12 hours.
I doubt there’s much we can do here without more specific details. I note that your ISP definitely did receive the contents of the email before choosing to reject it, because the Subject: line is contained within the main DATA phase, not part of the envelope. Can you go back to them and find out what specific problem there was (i.e. if it was rejected based on the Date header, what was the contents of the Date header?)
The “day” in the date header seems to be not conforming to RFC 5322,
it is “Do” (german abbreviation for Donnerstag = Thursday), RFC 5322 states to use “Thu”.
My Flightware account language is set to german, that might trigger the use of german weekdays. A similar problem might exist for the month abbreviations, where some, but not all are different from the english ones, e.g. “Dez” instead of “Dec”.