Mail being delivered to incorrect address

[David Hobley]

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 user1firstname.lastname

user2firstn...@domain2.com  user2firstname.lastname
user2firstn...@sharpblue.com.au user2firstname.lastname
user2firstname.lastn...@sharpblue.org   user2firstname.lastname

@domain3.comuser2firstname.lastname
@domain2.comuser1firstname.lastname
@domain1.comuser1firstname.lastname


In effect, I have 3 users created for domain1.com. A catchall for domain1 and 
domain2 to direct to user 1. Ignore domain3 for the time being.

For some reason though, all emails are ending up in user1’s Inbox. If I send an 
email from an external email address to us...@domain1.com it ends up in 
us...@domain1.com’s email. If I send an email to user2

Postfix logs show:
Jun 16 09:53:18 kopano postfix/smtp[8735]: 9665C6C28C5: to=us...@domain1.com, 
orig_to=us...@domain1.com, relay=127.0.0.1[127.0.0.1]:10024, delay=3.9, 
delays=2.2/0.01/0/1.6, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4DFA46C28E1)

RE: Mail being delivered to incorrect address

[David Hobley]

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 = 4096
milter_default_action = accept
milter_protocol = 6
mydestination =
myhostname = mail.domain2.com
mynetworks = 127.0.0.0/8 192.168.18.0/24 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, 
reject_unknown_helo_hostname, permit
smtpd_milters = local:/opendkim/opendkim.sock,local:/opendmarc/opendmarc.sock
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, 
reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, 
reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_rbl_client 
bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client 
dnsbl.sorbs.net, reject_unauth_destination, reject_unknown_client_hostname, 
reject_unknown_sender_domain, check_policy_service unix:private/policyd-spf, 
permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination
smtpd_tls_cert_file = /etc/kopano/ssl/cacert.pem
smtpd_tls_key_file = /etc/kopano/ssl/server.pem
smtpd_tls_security_level = may
tls_random_source = dev:/dev/urandom
virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = domain1.com, domain2.com, domain3.com
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_transport = lmtp:unix:/kopano/dagent.sock


The virtual aliases look like:
user1firstname.lastn...@domain3.com user1firstname.lastname

user2firstn...@domain2.com user2firstname.lastname
user2firstn...@domain1.com user2firstname.lastname
user2firstname.lastn...@domain2.com user2firstname.lastname

@domain3.com user2firstname.lastname
@domain2.com user1firstname.lastname
@domain1.com  user1firstname.lastname


In effect, I have 3 users created for domain1.com. A catchall for domain1 and 
domain2 to direct to user 1. Ignore domain3 for the time being.

For some reason though, all emails are ending up in user1’s Inbox. If I send an 
email from an external email address to user2firstname.lastn...@domain1.com it 
ends up in user1firstname.lastname’s email. If I send an email to 
user2firstn...@domain2.com it also ends up in user1firstname.lastname's email.

Interestingly, if I remove the @domain1.com catchall in the 
/etc/postfix/virtual file, email gets delivered correctly to 
user2firstname.lastn...@domain1.com and user2firstn...@domain2.com.

Postfix logs show (with the catchall):
Jun 16 09:53:18 kopano postfix/smtp[8735]: 9665C6C28C5: to=us...@domain1.com, 
orig_to=us...@domain1.com, relay=127.0.0.1[127.0.0.1]:10024, delay=3.9, 
delays=2.2/0.01/0/1.6, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4DFA46C28E1)

Can anyone point me in the correct direction please. I have spent a couple of 
days on this trying to work out where I have gone wrong and I am mystified. 
Happy to provide a more full-featured config if that helps.

Cheers,
David

Re: Mail being delivered to incorrect address

[Dominic Raferd]

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 =
> virtual_alias_maps = hash:/etc/postfix/virtual
> virtual_mailbox_domains = domain1.com, domain2.com, domain3.com
> virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
> virtual_transport = lmtp:unix:/kopano/dagent.sock
>
> The virtual aliases look like:
> user1firstname.lastn...@domain3.com user1firstname.lastname
>
> user2firstn...@domain2.com user2firstname.lastname
> user2firstn...@domain1.com user2firstname.lastname
> user2firstname.lastn...@domain2.com user2firstname.lastname
>
> @domain3.com user2firstname.lastname
> @domain2.com user1firstname.lastname
> @domain1.com  user1firstname.lastname
>
>
> In effect, I have 3 users created for domain1.com. A catchall for domain1
> and domain2 to direct to user 1. Ignore domain3 for the time being.
>
> For some reason though, all emails are ending up in user1’s Inbox. If I
> send an email from an external email address to
> user2firstname.lastn...@domain1.com it ends up in
> user1firstname.lastname’s email. If I send an email to
> user2firstn...@domain2.com it also ends up in user1firstname.lastname's
> email.
>
> Interestingly, if I remove the @domain1.com catchall in the
> /etc/postfix/virtual file, email gets delivered correctly to
> user2firstname.lastn...@domain1.com and user2firstn...@domain2.com...
>
> Can anyone point me in the correct direction please. I have spent a couple
> of days on this trying to work out where I have gone wrong and I am
> mystified. Happy to provide a more full-featured config if that helps.
>

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: the first time, user2firstn...@domain2.com is rewritten to
user2firstname.lastn...@domain1.com (i.e. the 'myorigin' is appended, I am
guessing domain1.com is set in /etc/mailname)

Because a change occurred this is then passed back through the same file
and (unless you remove the @domain1.com catchall) gets rewritten to
user1firstname.lastn...@domain1.com

RE: Mail being delivered to incorrect address

[David Hobley]

-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: the first time, user2firstn...@domain2.com 
> 
> is rewritten to 
> user2firstname.lastn...@domain1.com 
> 
> (i.e. the 'myorigin' is appended, I am guessing domain1.com 
> 
> is set in /etc/mailname)
> 
> Because a change occurred this is then passed back through the same file and
> (unless you remove the @domain1.com  catchall) gets 
> rewritten
> to 
> user1firstname.lastn...@domain1.com 
> 

Ah. That makes sense; because I am using virtual users, I guess postfix doesn't 
know when to stop.
I added in:

user1firstname.lastn...@domain1.com user1firstname.lastn...@domain1.com
user2firstname.lastn...@domain1.com user2firstname.lastn...@domain1.com

which are the actual end results and that catches that final rewrite. I realise 
the first one isn't strictly necessary given the catchall; but just for 
consistency!

Thanks - that was a great help.

Cheers,
David

Re: SMTPUTF8 problem with Exchange servers

[Patrick Proniewski]

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 offered by host 
>> Exchange-VIP[Exchange-VIP])
>> 
> 
> It is required (in this case, by RFC 6531..6533). 
> 
> With "smtputf8_enable = yes" (the default) Postfix must return mail
> as undeliverable when:
> 
> - a sending SMTP client requested SMTPUTF8 in the MAIL FROM command(*),
> 
> - and a receiving SMTP server does not announce SMTPUTF8 support.
> 
> However, Postfix ignores this requirement when a message has no
> UTF8 in the header, sender, or recipient envelope address.
> 
> Options:
> 
> - SMTPUTF8 support in Microsoft Exchange Server protocol revision
>  14.0 (from 2018) or later.
>  https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8


I'll have to wait for this one, at least few months.


> - Postfix: set "smtputf8_enable = no" so that Postfix will not be
>  able to receive such email messages (i.e. they will be returned
>  to the sender before they reach Postfix).
> 
> There is no defined conversion from SMTPUTF8 mail to historical
> email, and I decided not to invent one because it would solve only
> a temporary problem.


Makes perfect sense. 
I'll go for "smtputf8_enable = no" until we can upgrade Exchange.

thanks
patpro 

Re: SMTPUTF8 problem with Exchange servers

[Patrick Proniewski]

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.
> 
> Yes, but it is the right thing to do.  Better than generating
> backscatter.  When you don't have (end-to-end) SMTPUTF8 support for a
> non-trivial fraction of your inbound traffic, DO NOT advertise support
> for SMTPUTF8, or dedicate separate inbound MX hosts for the domains that
> need and do fully support SMTPUTF8.


I'll do that until we can upgrade Exchange to a version that supports SMTPUTF8.

thanks,
patpro

Unable to receive emails from btinternet.com

[David Hartley]

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
Received-From-MTA: dns; sa-prd-rgout-001.btmx-prd.synchronoss.net 
(10.2.38.4)


Final-Recipient: RFC822; 
Action: failed
Status: 4.4.7
Remote-MTA: dns; xxx.uk
Diagnostic-Code: smtp; 250 2.1.5 Ok

The Postfix log sees the BT mail server connect, but does not receive 
any data:


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]: 
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C: 
client=mailomta12-sa.btinternet.com[213.120.69.18]


2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after 
DATA (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]
2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect 
from mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1 
mail=1 rcpt=1 data=0/1 commands=5/6


Can anyone suggest what the problem is here please?

Is is a problem at my end, or a problem at btinternet.com?

With thanks

David

Re: Unable to receive emails from btinternet.com

[Dominic Raferd]

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; sa-prd-fep-040.btmx-prd.synchronoss.net
> Arrival-Date: Wed, 27 May 2020 18:31:52 +0100
> Received-From-MTA: dns; sa-prd-rgout-001.btmx-prd.synchronoss.net
> (10.2.38.4)
>
> Final-Recipient: RFC822; 
> Action: failed
> Status: 4.4.7
> Remote-MTA: dns; xxx.uk
> Diagnostic-Code: smtp; 250 2.1.5 Ok
>
> The Postfix log sees the BT mail server connect, but does not receive
> any data:
>
> 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]:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C:
> client=mailomta12-sa.btinternet.com[213.120.69.18]
>
> 2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after
> DATA (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]
> 2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect
> from mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1
> mail=1 rcpt=1 data=0/1 commands=5/6
>
> Can anyone suggest what the problem is here please?
>
> Is is a problem at my end, or a problem at btinternet.com?

All incoming emails from BT (mailomta[0-9]+-sa\.btinternet\.com) have
been received by our mailservers ok, the most recent was yesterday

See the accepted answer at
https://serverfault.com/questions/295409/how-to-solve-error-550-4-4-7

I suspect some firewalling action either on your mailserver or on an
intermediate router.

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.

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 smtp's wrapping means that
the key then becomes invalid.

The standard answer would be that it is the responsibility of an MUA
to ensure that emails do not break the RFC, so then smtp would not
have to fix a problem that is not of its own making.

But postfix's sendmail does not honour the RFC or the
smtp_line_length_limit value and happily submits emails with overlong
lines, and this is where my problem occasionally arises, say when
emailing output from a cron job.

I have various workarounds, and can imagine more. But the elegant
solution would be to make postfix's sendmail program honour and
enforce the smtp_line_length_limit parameter, or (better, and
backwards-compatible) to create another parameter dictating whether
sendmail would do this (e.g. sendmail_fix_line_length as
yes/no[default]). Obviously the limit should be applied after any
sendmail_fix_line_endings setting has been processed. Or an entirely
independent sendmail_line_length_limit parameter could be created (if
it is awkward to have sendmail honouring an smtp_ parameter).

Is that possible or is it a bad idea?

Re: Unable to receive emails from btinternet.com

[@lbutlr]

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]: 
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C: 
> client=mailomta12-sa.btinternet.com[213.120.69.18]
> 
> 2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after DATA 
> (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]
> 2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect from 
> mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1 mail=1 rcpt=1 
> data=0/1 commands=5/6
> 
> Can anyone suggest what the problem is here please?

Is that really all the log lines? There should be a PERMIT line in there that 
will include something like this:

Jun 18 05:39:43 mail.covisp.net postfix/smtpd[77265] 49ng2k4wjlz2s14Y: permit: 
RCPT from camomile.cloud9.net[168.100.1.3]: action=permit for Recipient 
address=krem...@kreme.com ; from= 
to= proto=ESMTP helo=

What is in the helo= field might be a clue, since it looks from the NDR that 
the mail server is using a private IP address, but without more logging it is 
hard to be sure. It looks like what you have is a successful connection and the 
the other side gives up five minutes later, for no reason at all, after sending 
absolutely no data.

Either bt is expecting something your Mailserver is not doing, or there are 
other log lines, or their server is ver broken (and the latter seems highly 
unlikely).

You are receiving emails from other senders, I take it?

(Obfuscating your mail server makes checking things like your DNS records or 
what your server actually is sending impossible, we cannot assume that 
sharproad.uk is the domain in question.) If that is the right server, it's 
definitely weird (it doesn;'t accept ehlo, for one). What version of postfix 
are you running?

Connected to sharproad.uk.
Escape character is '^]'.
220 sharproad.uk ESMTP Postfix
ehlo mail.covisp.net
502 5.5.2 Error: command not recognized
helo mail.covisp.net
250 sharproad.uk
mail from:kr...@kreme.com
250 2.1.0 Ok
rcpt to:da...@sharproad.uk
250 2.1.5 Ok
data
354 End data with .
this is a test
.
250 2.0.0 Ok: queued as 52A4F8C1A0A 

quit

221 2.0.0 Bye   

This is what I see on my own server:

Connected to mail.covisp.net.   

Escape character is '^]'.   

220-mail.covisp.net ESTMP -- Please wait

220 mail.covisp.net ESMTP Postfix 3.5.3  
ehlo fake.com 
250-mail.covisp.net
250-PIPELINING
250-SIZE 26214400
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
mail from:b...@whitehouse.com
250 2.1.0 Ok
rcpt to:kr...@kreme.com
250 2.1.5 Ok
data
354 End data with .
this is a test
.
250 2.0.0 Ok: queued as 49nh4035Qgz2s14Y
quit
221 2.0.0 Bye

There are some pretty obvious differences here, and the lack of SIZE could be 
an issue. It is quite possible that btinternet is biting specifically for a 
SIZE or some other 250 code that you are not sending.

Complete logs for the message and postconf -nf would help solve this




-- 
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that
something is impossible, he is probably wrong.

Re: SMTPUTF8 problem with Exchange servers

[Gerard E. Seibert]

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 bounce on MX
>>> servers. Would not really change anything in the end.  
>> 
>> Yes, but it is the right thing to do.  Better than generating
>> backscatter.  When you don't have (end-to-end) SMTPUTF8 support for a
>> non-trivial fraction of your inbound traffic, DO NOT advertise
>> support for SMTPUTF8, or dedicate separate inbound MX hosts for the
>> domains that need and do fully support SMTPUTF8.  
>
>
>I'll do that until we can upgrade Exchange to a version that supports
>SMTPUTF8.

That would be " Microsoft Exchange Server 2019"

https://docs.microsoft.com/en-us/Exchange/new-features/new-features?view=exchserver-2019

-- 
Jerry

Re: sendmail_fix_line_length enhancement request

[@lbutlr]

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 is after
> any (open)dkim milter adds its key, because smtp's wrapping means that
> the key then becomes invalid.

No, wrapping header lines does not affect DKIM if it is configured properly. 
The correct setting is c=relaxed which means that white space changes in 
headers are ignored. Setting it to simple instead will result in breaking 
because it makes DKIM reject RFC complain folding of long headers.

I don't even know why that setting exists, honestly.

(Your own message to the list used c=relaxed)\, which makes me think that 
perhaps your DKIM breaking is caused by something other than folding the header 
line?)

> But postfix's sendmail does not honour the RFC or the
> smtp_line_length_limit value and happily submits emails with overlong
> lines,

I believe the is because that is how sendmail works?

> and this is where my problem occasionally arises, say when
> emailing output from a cron job.

There is no reason to use sendmail to do that, especially if it causes a 
problem.



-- 
Slab: Jus' say 'AarrghaarrghpleeassennononoUGH'. --Feet of Clay

Re: sendmail_fix_line_length enhancement request

[Wietse Venema]

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 middle of a word, in the middle of
an HTML tag, and so on). So it really shuod not be considered a
reliable solution.

The main reason smtp_line_length_limit exists is to prevent other
MTAs from breaking MIME-formatted mail, where one huge message
header could cause all message content to become exposed in the
underlying encoding (base64 or quoted-printable).

If your problem is with cron job outputs that aren't sent across
the Internet, you could just disable this behavior by setting the
limit to zero, and by configuring other MTAs similarly.

Alternatively, as these cron jobs are under local control, you could
massage their output through a program that fixes long lines.

The sendmail command is a bad place for doing this, why not the
cleanup daemon?

Wietse

-

> 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 smtp's wrapping means that
> the key then becomes invalid.
> 
> The standard answer would be that it is the responsibility of an MUA
> to ensure that emails do not break the RFC, so then smtp would not
> have to fix a problem that is not of its own making.
> 
> But postfix's sendmail does not honour the RFC or the
> smtp_line_length_limit value and happily submits emails with overlong
> lines, and this is where my problem occasionally arises, say when
> emailing output from a cron job.
> 
> I have various workarounds, and can imagine more. But the elegant
> solution would be to make postfix's sendmail program honour and
> enforce the smtp_line_length_limit parameter, or (better, and
> backwards-compatible) to create another parameter dictating whether
> sendmail would do this (e.g. sendmail_fix_line_length as
> yes/no[default]). Obviously the limit should be applied after any
> sendmail_fix_line_endings setting has been processed. Or an entirely
> independent sendmail_line_length_limit parameter could be created (if
> it is awkward to have sendmail honouring an smtp_ parameter).
> 
> Is that possible or is it a bad idea?
> 

Re: Unable to receive emails from btinternet.com

[wilfried . essig]

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. :-((


Willi

Am 18.06.20 um 10:45 schrieb David Hartley:

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
Received-From-MTA: dns; sa-prd-rgout-001.btmx-prd.synchronoss.net 
(10.2.38.4)


Final-Recipient: RFC822; 
Action: failed
Status: 4.4.7
Remote-MTA: dns; xxx.uk
Diagnostic-Code: smtp; 250 2.1.5 Ok

The Postfix log sees the BT mail server connect, but does not receive 
any data:


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]: 
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C: 
client=mailomta12-sa.btinternet.com[213.120.69.18]


2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after 
DATA (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]
2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect 
from mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1 
mail=1 rcpt=1 data=0/1 commands=5/6


Can anyone suggest what the problem is here please?

Is is a problem at my end, or a problem at btinternet.com?

With thanks

David

Re: sendmail_fix_line_length enhancement request

[Wietse Venema]

@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 that the code simply does not have.

Instead it just inserts  in the middle of a string.
That's sufficient to preserve the structure of MIME and other
headers.

Wietse

Re: Unable to receive emails from btinternet.com

[Viktor Dukhovni]

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 deliver it.

> > Remote-MTA: dns; xxx.uk
> > Diagnostic-Code: smtp; 250 2.1.5 Ok

This is only an error if it is a response to initial "DATA" command, for
which the expected response is "354 ...".  Which somewhat suggests a
PIPELINING issue.

> > 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: Anonymous TLS 
> > connection established from mailomta12-sa.btinternet.com[213.120.69.18]: 
> > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> > 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C: 
> > client=mailomta12-sa.btinternet.com[213.120.69.18]

After STARTTLS, the client sent "MAIL", "RCPT" and "DATA", with the
connection lost at that point.  Therefore, no handshake issues can
be ruled out.

> > 2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after 
> > DATA (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]

The connection timed out no data was received for 5 minutes (default
smtpd_timeout).

> > 2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect 
> > from mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1 
> > mail=1 rcpt=1 data=0/1 commands=5/6

See above.

> > Can anyone suggest what the problem is here please?

$ posttls-finger sharproad.uk
posttls-finger: Connected to sharproad.uk[88.97.109.65]:25
posttls-finger: < 220 sharproad.uk ESMTP Postfix
posttls-finger: > EHLO amnesiac.example
posttls-finger: < 250-sharproad.uk
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 10485760
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-AUTH PLAIN LOGIN
posttls-finger: < 250-AUTH=PLAIN LOGIN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: sharproad.uk[88.97.109.65]:25: Matched subjectAltName: 
sharproad.uk
posttls-finger: [...]
posttls-finger: Untrusted TLS connection established to 
sharproad.uk[88.97.109.65]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 
(256/256 bits)
posttls-finger: > EHLO amnesiac.example
posttls-finger: < 250-sharproad.uk
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 10485760
posttls-finger: < 250-ETRN
posttls-finger: < 250-AUTH PLAIN LOGIN
posttls-finger: < 250-AUTH=PLAIN LOGIN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

ESMTP and STARTTLS work.

> > Is is a problem at my end, or a problem at btinternet.com?

To get more info, try "debug_peer_list = 213.120.69.0/25", and
wait for or solicit more email from BT.

-- 
Viktor.

P.S.  Added an explicit "Bcc:" to the OP, to record a delivery in my
  logs, assuming that's the right domain/server, ...

Re: sendmail_fix_line_length enhancement request

[@lbutlr]

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 would require an understanding of header
> or body contant that the code simply does not have.

Ah. That's good to know then.




-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but couldn't the constant use of a henna rinse
lead to premature baldness?"

Re: sendmail_fix_line_length enhancement request

[Dominic Raferd]

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 lines in the middle of a multibyte
> character (and of course in the middle of a word, in the middle of
> an HTML tag, and so on). So it really shuod not be considered a
> reliable solution.
>
> The main reason smtp_line_length_limit exists is to prevent other
> MTAs from breaking MIME-formatted mail, where one huge message
> header could cause all message content to become exposed in the
> underlying encoding (base64 or quoted-printable).
>
> If your problem is with cron job outputs that aren't sent across
> the Internet, you could just disable this behavior by setting the
> limit to zero, and by configuring other MTAs similarly.
>
> Alternatively, as these cron jobs are under local control, you could
> massage their output through a program that fixes long lines.
>

Thanks for your answer and explanation.

Your second suggestion is what I do, but it is difficult to catch all
instances. I have now followed your first and set the limit to zero
(which I believe is undocumented as a way to turn off automatic
line-breaking). Actually I am relaying into Gmail so it will be
interesting to see if it copes with overlong lines.

> The sendmail command is a bad place for doing this, why not the
> cleanup daemon?

Answering that question is way above my pay grade.

Re: Unable to receive emails from btinternet.com

[David Hartley]

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: valid ipv4 hostaddr?

[Fred Morris]

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 
representations.


You need to provide the headers for the message if you need further help.

On Thu, 18 Jun 2020, Maurizio Caloro wrote:


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.


--

Fred Morris

Re: valid ipv4 hostaddr?

[Wietse Venema]

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 conditions: an IP address contains no ':'
(meaning it must be dotted-q1uad form), or an IPv6 address contains
'.' (which must be followed by a dotted quad).

>From the surrounding logs, you may be able to distinguish
which form it was.

Either way, when I call valid_ipv4_hostaddr with 'dnsNane'
the warning I see is:

warning: valid_ipv4_hostaddr: invalid character 100(decimal): dnsName

I see no code path in valid_ipv4_hostaddr() that would allow 'd'
in 'dnsName' and then reject the 'n' after the 'd'. Maybe some
clever person improved the code.

Wietse

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

 

Port 110 are close, are running only with smtps and imaps.

Thanks for any update

Regards

Mauri

connect from unknown[unknown]

[Fourhundred Thecat]

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]", instead if unknown[1.2.3.4]?

Re: connect from unknown[unknown]

[Pau Amma]

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 "unknown[unknown]", instead if unknown[1.2.3.4]?


IIRC, when this last came up, the answer was along the lines of "because 
the connection was closed before Postfix could find out the IP address".