On 21 Jun 2020, at 07:32, David Hartley wrote:
erhaps not surprisingly the best MTU value turned out to be 1492, so I set my
network card to 1492.
Since then I have received two emails from btinternet.com.
On 21.06.20 09:59, @lbutlr wrote:
But this problem was isolated to only mails for
On 21 Jun 2020, at 07:32, David Hartley wrote:
> erhaps not surprisingly the best MTU value turned out to be 1492, so I set my
> network card to 1492.
>
> Since then I have received two emails from btinternet.com.
But this problem was isolated to only mails for BT? You would get mails fine
Hello All,
I am delighted to report that I have found and fixed my problem.
I first followed Viktor's advice and increased the debug level for email
from BT.
This did not reveal much more than we already knew; my server was timing
out waiting for data.
I then followed up the MTU issue
On 19/06/2020 10:18, Nick Tait wrote:
> Hi David.
>
> I think I can guess what your problem is, because I had exactly the
> same symptom with a different bulk email provider...
>
> Basically this sounds like an MTU issue: The SMTP client
> (mailomta12-sa.btinternet.com[213.120.69.18] in your case)
Nick Tait:
> Hi David.
>
> I think I can guess what your problem is, because I had exactly the same
> symptom with a different bulk email provider...
>
> Basically this sounds like an MTU issue: The SMTP client
> (mailomta12-sa.btinternet.com[213.120.69.18] in your case) is able to
>
On 19/06/20 8:28 pm, @lbutlr wrote:
On 19 Jun 2020, at 02:18, Nick Tait wrote:
1. My server was using the default MTU of 1500 bytes.
2. My connection to my ISP uses PPPoE, which adds an 8-byte header onto all
packets travelling between my home to my ISP, effectively reducing the maximum
On 19 Jun 2020, at 02:18, Nick Tait wrote:
> 1. My server was using the default MTU of 1500 bytes.
>
> 2. My connection to my ISP uses PPPoE, which adds an 8-byte header onto all
> packets travelling between my home to my ISP, effectively reducing the
> maximum packet size from 1500 bytes down
Hi David.
I think I can guess what your problem is, because I had exactly the same
symptom with a different bulk email provider...
Basically this sounds like an MTU issue: The SMTP client
(mailomta12-sa.btinternet.com[213.120.69.18] in your case) is able to
establish the TCP connection to
A big thank you to all who responded to my request for help.
I can see that I have a lot to learn about SMTP and Postfix, but I will
try to use your suggestions over the weekend.
David
On Thu, Jun 18, 2020 at 04:25:40PM +0200, wilfried.es...@essignetz.de wrote:
> Did you check your certificate?
That's clearly not the issue. Random guesses are not helpful.
> > Final-Recipient: RFC822;
> > Action: failed
> > Status: 4.4.7
The message expired after multiple retries failed to
Did you check your certificate?
We had some time ago an issue with one sender, that looked like yours in
the logs. After changing from a self signed certificate to one from
letsencrypt the sender didn't timeout in data anymore. Our certificate
where at that time about two years over end time.
On 18 Jun 2020, at 02:45, David Hartley wrote:
> 2020-06-09T12:04:00+01:00 postfix/smtpd[7356]: connect from
> mailomta12-sa.btinternet.com[213.120.69.18]
> 2020-06-09T12:04:01+01:00 postfix/smtpd[7356]: Anonymous TLS
> connection established from mailomta12-sa.btinternet.com[213.120.69.18]:
On Thu, 18 Jun 2020 at 09:46, David Hartley wrote:
>
> I am running Postfix on a Synology NAS using DSM 6.2
>
> In general I can receive emails, however I cannot receive emails
> from@ btinternet.com.
>
> An example of the sender's failure report is:
>
> Reporting-MTA: dns;
I am running Postfix on a Synology NAS using DSM 6.2
In general I can receive emails, however I cannot receive emails
from@ btinternet.com.
An example of the sender's failure report is:
Reporting-MTA: dns; sa-prd-fep-040.btmx-prd.synchronoss.net
Arrival-Date: Wed, 27 May 2020 18:31:52 +0100
14 matches
Mail list logo
