Recently, I have problems sending emails to Germany. The mails sent are returned with the error: The header field "Date" is syntactically not correct. See image:
How can I correct this? Using Pmail V4.8 on imap.

If you kept a copy of the sent message, look at the Date: header in its raw view for anything strange.

You can also enable internet session logging and then send a message to one of the failing addresses. The resulting log file will contain the transmitted Date: header. Do not post the entire log file. It contains your credentials in a form that is easily decrypted. The Date: header entry will look something like this:

07:32:59.953: << Date: Sun, 23 Jun 2024 07:32:56 -0400<cr><lf>

I just looked at my copy to self folder, and that is exactly the format I am seeing.
Date: Sat, 22 Jun 2024 14:08:23 +1000

So, first thing I would do is look at copy to self and examine latest messages.
In the preview window it is showing Date Sent:, but looking at the raw view, it is showing just the Date:

I did a quick look in tools options, and under advanced it an option for timezone. Mine has auto checked, and has +1000 selected with is Guam Timezone.

Seeing what is being shown, would determin if Pegasus is somehow really doing an error, or if the site has an error in its code. Think Pegasus just gets date from Windows (or Linux), but seeing exactly what is being placed in field

So would confirm what is actually being placed in message would be first step.

It's almost impossible that this diagnosis can be true: The RFC they are quoting contains the most basic email configuration requirements which Pegasus Mail obeys to ever since they have been released. The only reason I can think of causing such an issue must be something in between creation of the message by Pegasus Mail and arriving at the complaining SMTP server, i.e. something else is messing with your emails, typically AntiVirus or so-called "malware protection" software.

To figure this out we would need the headers of such a rejected message which they typically return along with their error report. Then you can compare it to a message created by Pegasus Mail, i.e. its final form before being sent: This one can be created in Pegasus Mail's message queue by copying (not moving!) a queued message (which only cointains a script) to another folder, which will create this final form as being sent to the SMTP server.

I did a web search on "554 Nemesis ESMTI Service not available" and found one hit where the software generating the email message was populating the Date field with a German day of the week. I can't imagine that Pegasus Mail would do this but I do not have any experience with the German version. The content of the transmitted Date: header remains the starting point to this puzzle.

These are the headers in the sent message:
"X-cs: R
X-CS-Version: 1.0
From: my name my@address.nl
X-RS-ID: <Default>
X-RS-Flags: 1,0,1,1,0,0,0
X-RS-Header: In-reply-to: trinity-8fbcca1a-1b8c-4c08-abb2-eb1f99284426-1719137746491@msvc-mesg-web112
X-RS-Header: References: trinity-8fbcca1a-1b8c-4c08-abb2-eb1f99284426-1719137746491@msvc-mesg-web112
X-RS-Sigset: -1
To: tomail@address.de
Subject: Re: Buchung Apartment
Cc: copymail@address.de
Comments: Confirmation of reading was requested.
MIME-Version: 1.0
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
Date: Sun, 23 Jun 2024 13:41:49 +1

I don't see the problem.

Is this what they returned to you?

+1 is not valid. What is your actual timezone?
If it is one hour ahead of GMT it should be +0100

I am from Guam, where my time zone is +1000
Hawaii is -1000

What do you see under tools / options / advanced settings / SMTP timezone.
Shows format as (+xxxx or -xxxx)
Mine shows +1000 grayed out with auto checked.

What does yours have?? Seems Pegasus does let one enter +1, but not sure why it would allow that?

From MANUAL.PDF

SMTP time zone This field only applies to mail sent using Internet mail transports other than
the Charon and Mercury gateways. It indicates your timezone relative to the rest of the world,
and should be entered as a 4 digit offset from Universal Standard Time (Greenwich Mean
Time). As an example, New Zealand is 12 hours ahead of GMT, so the correct value for New
Zealand would be +1200.

Auto If you check the Auto control (the default setting), then Pegasus Mail will ignore
whatever is entered in the SMTP Time Zone field, and will work out the time zone by
asking the Windows operating system. The main advantage of using the Auto setting is
that daylight savings compensations will be applied automatically, and the format of the
time zone field is guaranteed to be correct. We strongly recommend that you use this
option.

So, I would check that setting, and if your timezone is 1 hour ahead of GMT, it should be +0100
Otherwise check on the auto, and try sending a message and see what it get from auto.
If it uses auto and gets +1 I think it is an OS issue of some type.

Hope that solves it.

https://docs.oracle.com/cd/E19566-01/819-4437/6n6jckr2o/index.html

Shows a lot of example
Basically + or - saying that timezone is ahead or behind GMT
4 digit number with format HHMM.
Hours different from GMT as 2 digits
Minutes different from GMT as 2 digit.
Most have 00, but there are a few with 30 or 45?

Did a quick scan of timezones in my PMAIL.PMM and got these results
10 -1000
28 -0800
81 -0700
163 -0600
1010 -0500
701 -0400
230 -0300
45 +0000
161 -0000
265 +0100
134 +0200
210 +1000
6 +1100
2 +1300

Don't understand the +1300??

This where I suggest looking as well. Pegasus Mail does indeed accept +1, which produces the header in the form of

Date: Sun, 23 Jun 2024 13:41:49 +1

Never took a look at this since I've just enabled Auto. Are you going to notify David Harris about this, Brian?

Yes.

To Confirm I just tested it. Turned off auto and entered +1 for smtp.
Sent myself a messages and DATE: did show +1 as the timezone.
So, Pegasus does take the +1

Interestingly, Google SMTP accepts messages submitted with the invalid date format creating a new valid though expectedly inaccurate Date: header somewhere along the way.

This is what is in the headers of a received test message (my actual offset is -0400):

Date: Tue, 25 Jun 2024 12:16:55 -0700 (PDT)
X-Google-Original-Date: Tue, 25 Jun 2024 15:16:53 +1

Saw a similar thing with mom's Compuserver email. @cs.com Mom was in Nevada, but there server was in New York, so message all had the New York Time zone. That used a web interface.

Hopefully, the original sender of message has been able to resolve this.
Sending message thru my ISP mail server smtp1.guam.net it didn't change the +1 in the message that came thru.

It appears that the handling of a send attempt of a message with an invalid Date header varies by SMTP server. A gmx.com SMTP server rejected the message with a 554 error but a gmail SMTP server accepted it, added a valid header, and delivered it.

With SMTP time zone set to +1 and auto unchecked
Date: Wed, 26 Jun 2024 09:23:28 +1

With SMTP time zone set to +1000 and auto checked.
Date: Wed, 26 Jun 2024 09:26:19 +1000

I have called this to the attention of David Harris. I think data validation on the content of the SMTP time zone field is needed, or automatically fill any missing characters with a zero.

Looking at my PMAIL.INI using linux I see my 3 identites
grep Timezone <PMAIL.INI
Timezone for internal transport = +1000
Timezone for internal transport = +1000
Timezone for internal transport = +1000

Under wine this is windows find option?
find "Timezone" PMAIL.INI

---------- PMAIL.INI
Timezone for internal transport = +1000
Timezone for internal transport = +1000
Timezone for internal transport = +1000

If was going to test
Character 1 needs to be a + or -
Character 2 and 3 would go 00 to 11
Character 4 and 5 would be 00 or 30 or 45 from what I saw?