Re: connect from unknown[unknown]

On 2020-06-19 06:47, Fourhundred Thecat wrote: postfix/smtpd: connect from unknown[unknown] postfix/smtpd: lost connection after CONNECT from unknown[unknown] postfix/smtpd: disconnect from unknown[unknown] commands=0/0 how can postfix not see the IP address? Why does it say

connect from unknown[unknown]

Hello, I am curious, how can this happen: postfix/smtpd: connect from unknown[unknown] postfix/smtpd: lost connection after CONNECT from unknown[unknown] postfix/smtpd: disconnect from unknown[unknown] commands=0/0 how can postfix not see the IP address? Why does it say "unknown[unknown]",

valid ipv4 hostaddr?

Hello Please why appair on log this message? Jun 18 23:16:38 mail postfix/trivial-rewrite[5022]: warning: valid_ipv4_hostaddr: invalid character 110(decimal): dnsName Port 110 are close, are running only with smtps and imaps. Thanks for any update Regards Mauri

Re: valid ipv4 hostaddr?

Maurizio Caloro: > Hello > > Please why appair on log this message? > > Jun 18 23:16:38 mail postfix/trivial-rewrite[5022]: warning: > valid_ipv4_hostaddr: invalid character 110(decimal): dnsName ASCII code 110 is the letter 'n'. The function valid_ipv4_hostaddr() is called under two

Re: valid ipv4 hostaddr?

I think what it's telling you is that an invalid character occurred in a header, specifically inside of an IP4 address. code 110 (ASCII) is the letter "n". Presumably it expects IP4 addresses in "dotted quad" (xxx.xxx.xxx.xxx), I don't know if it accepts any of the more esoteric

Re: Unable to receive emails from btinternet.com

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

Re: sendmail_fix_line_length enhancement request

On Thu, 18 Jun 2020 at 15:03, Wietse Venema wrote: > > Dominic Raferd: > > I understand the reason for smtp_line_length_limit and for its default > > value of 998, which is of course good. > > It breaks DKIM signatures, it is needed only for mail that is sent > via SMTP, and worse, it breaks

Re: sendmail_fix_line_length enhancement request

On 18 Jun 2020, at 09:24, Wietse Venema wrote: > @lbutlr: >> No, wrapping header lines does not affect DKIM if it is configured = >> properly. The correct setting is c=3Drelaxed which means that white = > > smtp_line_length_limit breaks DKIM relaxed mode, because it does > not wrap lines. That

Re: Unable to receive emails from btinternet.com

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

Re: sendmail_fix_line_length enhancement request

@lbutlr: > No, wrapping header lines does not affect DKIM if it is configured = > properly. The correct setting is c=3Drelaxed which means that white = smtp_line_length_limit breaks DKIM relaxed mode, because it does not wrap lines. That would require an understanding of header or body contant

Re: Unable to receive emails from btinternet.com

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.

Re: sendmail_fix_line_length enhancement request

Dominic Raferd: > I understand the reason for smtp_line_length_limit and for its default > value of 998, which is of course good. It breaks DKIM signatures, it is needed only for mail that is sent via SMTP, and worse, it breaks lines in the middle of a multibyte character (and of course in the

Re: sendmail_fix_line_length enhancement request

On 18 Jun 2020, at 05:38, Dominic Raferd wrote: > I understand the reason for smtp_line_length_limit and for its default > value of 998, which is of course good. > > But it is an occasional problem for me that this wrapping action is > only applied at smtp stage and not earlier; in particular it

Re: SMTPUTF8 problem with Exchange servers

On Thu, 18 Jun 2020 10:20:48 +0200, Patrick Proniewski stated: >On 17 juin 2020, at 22:05, Viktor Dukhovni > wrote: >> >> On Wed, Jun 17, 2020 at 10:00:32PM +0200, Patrick Proniewski wrote: >> - disable SMTPUTF8 in Postfix. >>> >>> That means disabling it everywhere and let messages

Re: Unable to receive emails from btinternet.com

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]:

sendmail_fix_line_length enhancement request

I understand the reason for smtp_line_length_limit and for its default value of 998, which is of course good. But it is an occasional problem for me that this wrapping action is only applied at smtp stage and not earlier; in particular it is after any (open)dkim milter adds its key, because

Re: Unable to receive emails from btinternet.com

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;

Unable to receive emails from btinternet.com

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

Re: SMTPUTF8 problem with Exchange servers

On 17 juin 2020, at 22:05, Viktor Dukhovni wrote: > > On Wed, Jun 17, 2020 at 10:00:32PM +0200, Patrick Proniewski wrote: > >>> - disable SMTPUTF8 in Postfix. >> >> That means disabling it everywhere and let messages bounce on MX servers. >> Would not really change anything in the end. > >

Re: SMTPUTF8 problem with Exchange servers

Hello, > On 17 juin 2020, at 16:28, Wietse Venema wrote: > > Patrick Proniewski: >> Jun 17 12:34:20 postfix-mailgw/smtp[77347]: 57F56EB256: >> to=, orig_to=, >> relay=Exchange-VIP[Exchange-VIP]:25, delay=0.01, delays=0.01/0/0/0, >> dsn=5.6.7, status=bounced (SMTPUTF8 is required, but was not

RE: Mail being delivered to incorrect address

-Original message- > From: Dominic Raferd > You presumably have the default setting: > append_at_myorigin = yes > > Refer to http://www.postfix.org/virtual.5.html > . > Bear in mind that processing of virtual alias table is recursive. > > So:

Re: Mail being delivered to incorrect address

On Thu, 18 Jun 2020 at 08:13, David Hobley wrote: > Sorry, that got sent prior to my completing the email. I'll try again. > > /etc/postfix/main.cf > alias_maps = > append_dot_mydomain = no > compatibility_level = 2 > ... > myorigin = /etc/mailname ... > virtual_alias_domains = >

RE: Mail being delivered to incorrect address

Sorry, that got sent prior to my completing the email. I'll try again. /etc/postfix/main.cf alias_maps = append_dot_mydomain = no biff = no compatibility_level = 2 content_filter = smtp-amavis:[127.0.0.1]:10024 inet_interfaces = all inet_protocols = ipv4 mailbox_size_limit = 0 message_size_limit

Mail being delivered to incorrect address

Hello, alias_maps= virtual_transport=lmtp:unix:/kopano/dagent.sock virtual_mailbox_domains=domain1.com, domain2.com, domain3.com virtual_mailbox_maps=mysql:/etc/postfix/mysql-users.cf virtual_alias_maps=hash:/etc/postfix/virtual The virtual aliases look like: user1firstname.lastn...@domain3.com

Re: SMTPUTF8 problem with Exchange servers

Hello, > On 17 juin 2020, at 22:48, @lbutlr wrote: > > On 17 Jun 2020, at 14:00, Patrick Proniewski wrote: >> Not possible yet. A flag exists for Exchange 2019 but we are running 2016 >> now and upgrade is not scheduled for now. > > Perhaps showing the bouncing emails to whomever is in