Re: empty message-ID

2020-11-23 Thread Bob Proulx
@lbutlr wrote:
> Bob Proulx wrote:
> > But so many people use Gmail these days that they have gotten used to
> > the way Gmail does things.  And Gmail de-duplicates and saves the
> > first message with any particular message-id that arrives.  And then
> > displays a "mailbox" showing a view of the current tag being
> > displayed.  It's a very different paradigm from having separate
> > mailbox folders for different topics.
> 
> I don't use Gmail much, but my primary sort criteria now is a series
> of smart searches in Mail.app.

I don't use Gmail at all.  But the people who do not use Gmail are in
the minority.  It's the world we live in now.  I have to know how
Gmail works even though I don't use it because almost everyone else
around me uses it.

Bob


Re: empty message-ID

2020-11-23 Thread Bob Proulx
@lbutlr wrote:
> On 23 Nov 2020, at 15:27, Jaroslaw Rafa  wrote:
> > Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
> >> 
> >> If someone replies to a mailing list and copies the sender then that
> >> person gets two copies.  The above recipe avoids that.
> 
> > Moreover, it breaks the continuity of threads on mailing lists, because it's
> > unpredictable which copy will arrive first, and if only the direct copy is
> > left, the reply will go only to the sender and not to the mailing list. Thus
> > some messages are missing from lists.
> 
> This is not accurate. First, the direct message almost certainly
> arrives first. Second of all, that message still has headers
> indicating it was sent to the mailing list.

That is not accurate.  The direct message never went through the
mailing list.  The direct copy is missing the mailing list headers.
For this list the direct copy is missing these headers.
 
Sender: owner-postfix-us...@postfix.org
Precedence: bulk
List-Id: Postfix users 
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 

The most important of those are List-Id and List-Post without which
the message will not be filed correctly and most mailers will not be
able to list reply correctly.  This puts the onus upon the receiver to
manually take corrective action with the message.  That is something
that I and probably most readers of this list can do.  But for most
random people today they do not understand email and most people today
do not have the skill to do this correctly.  For them it is simply
completely broken.

> >> People also send to every alias that someone has.  Example,
> >> billing@, admin@, support@, joe@, etc.
> 
> > But it's usually one message with multiple recipients, and if all these
> > recipients "resolve" to the same final destination, the receiving MTA
> > usually avoids creating duplicates. At least that was always the case for me
> > as the recipient, no matter if I was using sendmail, Exim or Postfix for my
> > mail.
> 
> We are talking about duplicated messages with the same
> message-id. That is one message with multiple recipients. If they
> were separate messages, they would have unique message-id headers.

That is not accurate.  A single message to multiple recipients will
have one Message-Id.  If you receive it by being the target of some of
those multiple recipients then you will receive multiple copies of the
message and all of the copies will have the same Message-Id.

Bob


Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 15:40, Richard Damon  wrote:
> On 11/23/20 5:27 PM, Jaroslaw Rafa wrote:
>> Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
>>> If someone replies to a mailing list and copies the sender then that
>>> person gets two copies.  The above recipe avoids that.
>> If someone gets two copies - a direct one and the mailing list one - then
>> he/she knows that the sender has replied both to author and to the list and
>> can instruct the sender not to do it. With the above recipe, the recipient
>> doesn't even know about that.
>> 
>> Moreover, it breaks the continuity of threads on mailing lists, because it's
>> unpredictable which copy will arrive first, and if only the direct copy is
>> left, the reply will go only to the sender and not to the mailing list. Thus
>> some messages are missing from lists.
> 
> You CAN still reply to the list from the private copy, you won't have a
> 'Reply-to-List' opiton, because of the lack of list headers, but
> 'Reply-All' will still work.
> 
> It just becomes a bit harder to reply back JUST to the list. Your need
> Reply-All and then editing the list of recipients.

Or you use procmail/Sieve to add a reply-to header to messages that have the 
mailing list email in the headers.


-- 
"A common mistake people make when trying to design something
completely foolproof is to underestimate the ingenuity of
complete fools.: - Douglas Adams



Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 15:27, Jaroslaw Rafa  wrote:
> Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
>> 
>> If someone replies to a mailing list and copies the sender then that
>> person gets two copies.  The above recipe avoids that.

> Moreover, it breaks the continuity of threads on mailing lists, because it's
> unpredictable which copy will arrive first, and if only the direct copy is
> left, the reply will go only to the sender and not to the mailing list. Thus
> some messages are missing from lists.

This is not accurate. First, the direct message almost certainly arrives first. 
Second of all, that message still has headers indicating it was sent to the 
mailing list. Third, whether your client gets confused about threading is a 
client issue, not an issue of the mail message. (My client does not get 
confused and the messages end up in the same virtual mailbox regardless).

>> People also send to every alias that someone has.  Example,
>> billing@, admin@, support@, joe@, etc.

> But it's usually one message with multiple recipients, and if all these
> recipients "resolve" to the same final destination, the receiving MTA
> usually avoids creating duplicates. At least that was always the case for me
> as the recipient, no matter if I was using sendmail, Exim or Postfix for my
> mail.

We are talking about duplicated messages with the same message-id. That is one 
message with multiple recipients. If they were separate messages, they would 
have unique message-id headers.

-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but why would anyone want a depressed tongue?"



Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 13:24, Bob Proulx  wrote:
> Jaroslaw Rafa wrote:
>> Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:
>>> After the first message was accepted all of the rest
>>> were silently dropped as duplicates due to a very standard procmail
>>> recipe:
>>> 
>>> :0 Wh: msgid.lock
>>> | formail -D 65536 $HOME/.msgid.cache
>> 
>> Who uses that? It's not normal to get email duplicates and it usually
>> means that mail system is not functioning properly. They should find the
>> cause of the duplicates and eliminate it instead of hiding symptoms...
> 
> Although I have been using procmail since the inception of it I have
> always found this type rule problematic.  Because for me it keeps the
> wrong message.  If I am sent a direct copy and a mailing list copy
> then the copy I want is the mailing list copy.

Since my list filters looked at the to and CC headers this wasn't an issue.

> But so many people use Gmail these days that they have gotten used to
> the way Gmail does things.  And Gmail de-duplicates and saves the
> first message with any particular message-id that arrives.  And then
> displays a "mailbox" showing a view of the current tag being
> displayed.  It's a very different paradigm from having separate
> mailbox folders for different topics.

I don't use Gmail much, but my primary sort criteria now is a series of smart 
searches in Mail.app.

List mail al goes into a single "List" mailbox, then a smart search shows me, 
for example, all the postfix-users messages as a virtual mailbox.

The means that I rarely see the messages sent directly to me instead of the 
list because I don't generally read the "list" mailbox directly. Every now and 
then I archive all the list messages which takes them out of the smart 
mailboxes. (I could automate that action, but I haven't for reasons).

-- 
'Witches just aren't like that,' said Magrat. 'We live in harmony
with the great cycles of Nature, and do no harm to anyone, and
it's wicked of them to say we don't. We ought to fill their bones
with hot lead.'



Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 13:34, Erwan David  wrote:
> Le 23/11/2020 à 20:16, @lbutlr a écrit :
>> I would feel comfortable rejecting messages without a Message-ID.

> Maybe on smtp, but not on submission. FOr me policy there is completeley
> different

On submission postfix adds the message ID as is proper if the MUA hasn't added 
it.

-- 
'Now what?' it said. IT'S UP TO YOU. IT'S ALWAYS UP TO YOU.
--Maskerade



Re: empty message-ID

2020-11-23 Thread Richard Damon
On 11/23/20 5:27 PM, Jaroslaw Rafa wrote:
> Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
>> If someone replies to a mailing list and copies the sender then that
>> person gets two copies.  The above recipe avoids that.
> If someone gets two copies - a direct one and the mailing list one - then
> he/she knows that the sender has replied both to author and to the list and
> can instruct the sender not to do it. With the above recipe, the recipient
> doesn't even know about that.
>
> Moreover, it breaks the continuity of threads on mailing lists, because it's
> unpredictable which copy will arrive first, and if only the direct copy is
> left, the reply will go only to the sender and not to the mailing list. Thus
> some messages are missing from lists.

You CAN still reply to the list from the private copy, you won't have a
'Reply-to-List' opiton, because of the lack of list headers, but
'Reply-All' will still work.

It just becomes a bit harder to reply back JUST to the list. Your need
Reply-All and then editing the list of recipients.



-- 
Richard Damon



Re: empty message-ID

2020-11-23 Thread Jaroslaw Rafa
Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
> 
> If someone replies to a mailing list and copies the sender then that
> person gets two copies.  The above recipe avoids that.

If someone gets two copies - a direct one and the mailing list one - then
he/she knows that the sender has replied both to author and to the list and
can instruct the sender not to do it. With the above recipe, the recipient
doesn't even know about that.

Moreover, it breaks the continuity of threads on mailing lists, because it's
unpredictable which copy will arrive first, and if only the direct copy is
left, the reply will go only to the sender and not to the mailing list. Thus
some messages are missing from lists.

> People also send to every alias that someone has.  Example,
> billing@, admin@, support@, joe@, etc.

But it's usually one message with multiple recipients, and if all these
recipients "resolve" to the same final destination, the receiving MTA
usually avoids creating duplicates. At least that was always the case for me
as the recipient, no matter if I was using sendmail, Exim or Postfix for my
mail.


Dnia 23.11.2020 o godz. 12:22:37 @lbutlr pisze:
> 
> Everyone who ever used procmail? Nearly everyone who ever used procmail?
> 
> It's even in the procmail man page.

Yes it is, but I never saw any real use case for this.


Dnia 23.11.2020 o godz. 13:24:13 Bob Proulx pisze:
> 
> Although I have been using procmail since the inception of it I have
> always found this type rule problematic.  Because for me it keeps the
> wrong message.  If I am sent a direct copy and a mailing list copy
> then the copy I want is the mailing list copy.
> 
> But so many people use Gmail these days that they have gotten used to
> the way Gmail does things.
[...]

+1 ;)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."


Re: empty message-ID

2020-11-23 Thread Richard Damon
On 11/23/20 3:34 PM, Erwan David wrote:
> Le 23/11/2020 à 20:16, @lbutlr a écrit :
>> On 23 Nov 2020, at 06:49, maciejm  wrote:
>>> "RFC 822 Message-ID is not required"
>> RFC 822 has been obsoleted several times. 
>>
>> RFC 5322 states:
>>
>>Though listed as optional in the table in section 3.6, every message
>>SHOULD have a "Message-ID:" field.  Furthermore, reply messages
>>SHOULD have "In-Reply-To:" and "References:" fields as appropriate
>>and as described below.
>>
>> And:
>>
>> RFC 2119
>> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>>  may exist valid reasons in particular circumstances to ignore a
>>  particular item, but the full implications must be understood and
>>  carefully weighed before choosing a different course.
>>
>> So SHOULD is much stronger than "it's a good idea" and much more like "You 
>> better have a really good reason for ignoring this".
>>
>> I would feel comfortable rejecting messages without a Message-ID.
>>
> Maybe on smtp, but not on submission. FOr me policy there is completeley
> different

I thought one strategy to handle this was that submission would detect
lack of the message-id header and add one with a proper message-id.

-- 
Richard Damon



Re: empty message-ID

2020-11-23 Thread Erwan David
Le 23/11/2020 à 20:16, @lbutlr a écrit :
> On 23 Nov 2020, at 06:49, maciejm  wrote:
>> "RFC 822 Message-ID is not required"
> RFC 822 has been obsoleted several times. 
>
> RFC 5322 states:
>
>Though listed as optional in the table in section 3.6, every message
>SHOULD have a "Message-ID:" field.  Furthermore, reply messages
>SHOULD have "In-Reply-To:" and "References:" fields as appropriate
>and as described below.
>
> And:
>
> RFC 2119
> SHOULDThis word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
> So SHOULD is much stronger than "it's a good idea" and much more like "You 
> better have a really good reason for ignoring this".
>
> I would feel comfortable rejecting messages without a Message-ID.
>

Maybe on smtp, but not on submission. FOr me policy there is completeley
different




Re: empty message-ID

2020-11-23 Thread Bob Proulx
Jaroslaw Rafa wrote:
> Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:
> > After the first message was accepted all of the rest
> > were silently dropped as duplicates due to a very standard procmail
> > recipe:
> > 
> > :0 Wh: msgid.lock
> > | formail -D 65536 $HOME/.msgid.cache
> 
> Who uses that? It's not normal to get email duplicates and it usually
> means that mail system is not functioning properly. They should find the
> cause of the duplicates and eliminate it instead of hiding symptoms...

Although I have been using procmail since the inception of it I have
always found this type rule problematic.  Because for me it keeps the
wrong message.  If I am sent a direct copy and a mailing list copy
then the copy I want is the mailing list copy.

But so many people use Gmail these days that they have gotten used to
the way Gmail does things.  And Gmail de-duplicates and saves the
first message with any particular message-id that arrives.  And then
displays a "mailbox" showing a view of the current tag being
displayed.  It's a very different paradigm from having separate
mailbox folders for different topics.  Gmail has one mailbox for
everything and multiple tags are possible on each message and only
displays the current display tag view of the mailbox.  And since it is
one mailbox it de-duplicates by only showing the first message-id.
And people have gotten used to that paradigm.  But it does cause some
odd behavior when dealing with mailing lists.

Bob


Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 07:44, Jaroslaw Rafa  wrote:
> Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:
>> 
>> :0 Wh: msgid.lock
>> | formail -D 65536 $HOME/.msgid.cache
> 
> Who uses that?

Everyone who ever used procmail? Nearly everyone who ever used procmail?

It's even in the procmail man page.

>If you are subscribed to several mailinglists and people cross-post to
>some of them, you usually receive several duplicate mails (one from
>every list).  The following simple recipe eliminates duplicate mails.
>It tells formail to keep an 8KB cache file in which it will store the
>Message-IDs of the most recent mails you received.  Since Message-IDs
>are guaranteed to be unique for every new mail, they are ideally suited
>to weed out duplicate mails.  Simply put the following recipe at the
>top of your rcfile, and no duplicate mail will get past it.
> 
>   :0 Wh: msgid.lock
>   | formail -D 8192 msgid.cache


-- 
All our loves are first loves



Re: empty message-ID

2020-11-23 Thread @lbutlr
On 23 Nov 2020, at 06:49, maciejm  wrote:
> "RFC 822 Message-ID is not required"

RFC 822 has been obsoleted several times. 

RFC 5322 states:

   Though listed as optional in the table in section 3.6, every message
   SHOULD have a "Message-ID:" field.  Furthermore, reply messages
   SHOULD have "In-Reply-To:" and "References:" fields as appropriate
   and as described below.

And:

RFC 2119
SHOULD  This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

So SHOULD is much stronger than "it's a good idea" and much more like "You 
better have a really good reason for ignoring this".

I would feel comfortable rejecting messages without a Message-ID.

-- 
Imagine all the people Sharing all the world



Re: empty message-ID

2020-11-23 Thread Wietse Venema
Benny Pedersen:
> Wietse Venema skrev den 2020-11-23 17:10:
> 
> > Postfix 2.6 and later don't add a Message-ID header, unless the
> > message comes from a "local" source. That header is a combination
> > of a time stamp and the Postfix $myhostname value, so it is unique
> > as long as both values are unique.
> 
> okay, what if msgid miss the @ charter ?

A message-id is not an email address.

> i remember postfix have configs for when @ is not part of msgid it can 
> add @invalid.example.org so its diffrent if not sent local or remote

Postfix can be configured to 'fix' an email address.

Wietse

remote_header_rewrite_domain (default: empty)
   Don't rewrite message headers from remote  clients  at  all  when  this
   parameter  is  empty; otherwise, rewrite message headers and append the
   specified domain name to incomplete  addresses.   The  local_header_re-
   write_clients parameter controls what clients Postfix considers local.

   Examples:

   The   safe   setting:  append  "domain.invalid"  to  incomplete  header
   addresses from remote SMTP clients, so that those addresses  cannot  be
   confused with local addresses.

   remote_header_rewrite_domain = domain.invalid

   The default, purist, setting: don't rewrite headers from remote clients
   at all.

   remote_header_rewrite_domain =


Wietse


Re: adding AV scanning to working Postfix/SA system

2020-11-23 Thread michael Schumacher
Joe,

> Due to some recent malware (in attachments, obvious stuff) wanted to add AV 
> scanning.   I gather "Amavis-new" is the hot ticket these days,
> I deal with Sophos products and would like to use their linux product to do 
> the scanning.   Seems to be precious little on how to do that.

I am using amavis with clamav. Sorry, no additional commercial virus scanners, 
but I noticed that amavis.conf contains setups for a lot of commercial virus 
scanners. May be worth a look.

Michael



Re: empty message-ID

2020-11-23 Thread Benny Pedersen

Wietse Venema skrev den 2020-11-23 17:10:


Postfix 2.6 and later don't add a Message-ID header, unless the
message comes from a "local" source. That header is a combination
of a time stamp and the Postfix $myhostname value, so it is unique
as long as both values are unique.


okay, what if msgid miss the @ charter ?

i remember postfix have configs for when @ is not part of msgid it can 
add @invalid.example.org so its diffrent if not sent local or remote


Re: adding AV scanning to working Postfix/SA system

2020-11-23 Thread Dominic Raferd



On 23/11/2020 16:34, Joe Acquisto-j4 wrote:

Not to waste anyone's time, but I posted this on SA list and a Sophos site, but, came up with zip. 
Not even a "do-dah".  Beyond "experiences"
any leads to general "how to: guides that work in practice?


SOHO system, on virtual machines.   Fairly recent versions. Running openSUSE 
Leap 15.1.

Due to some recent malware (in attachments, obvious stuff) wanted to add AV scanning.   I 
gather "Amavis-new" is the hot ticket these days,

I deal with Sophos products and would like to use their linux product to do the 
scanning.   Seems to be precious little on how to do that.

Any experiences?
None with Sophos products on Linux. But I use amavis as content-filter 
and it in turns calls SA (which presumably you already know about) and 
ClamAV. ClamAV works well provided you add various 3rd-party signatures. 
I know of two tools to assist with these: 
https://github.com/extremeshok/clamav-unofficial-sigs and the newer 
https://github.com/rseichter/fangfrisch.


adding AV scanning to working Postfix/SA system

2020-11-23 Thread Joe Acquisto-j4
Not to waste anyone's time, but I posted this on SA list and a Sophos site, 
but, came up with zip. Not even a "do-dah".  Beyond "experiences"
any leads to general "how to: guides that work in practice?

>> SOHO system, on virtual machines.   Fairly recent versions. Running openSUSE 
>> Leap 15.1.

Due to some recent malware (in attachments, obvious stuff) wanted to add AV 
scanning.   I gather "Amavis-new" is the hot ticket these days,

I deal with Sophos products and would like to use their linux product to do the 
scanning.   Seems to be precious little on how to do that.

Any experiences? 



-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-


Re: empty message-ID

2020-11-23 Thread Wietse Venema
Benny Pedersen:
> D'Arcy Cain skrev den 2020-11-23 15:18:
> 
> > :0 Wh: msgid.lock
> > | formail -D 65536 $HOME/.msgid.cache
> > 
> > In other words, the message ID "" was considered a duplicate after the
> > first one.
> 
> if you use postfix there would be uniq msgid always, eq postfix ensures 
> there is always fqdn in msgid aswell, many mua's does not ensure the 
> fqdn part

Postfix 2.6 and later don't add a Message-ID header, unless the
message comes from a "local" source. That header is a combination
of a time stamp and the Postfix $myhostname value, so it is unique
as long as both values are unique.

Wietse


Re: empty message-ID

2020-11-23 Thread Benny Pedersen

D'Arcy Cain skrev den 2020-11-23 15:18:


:0 Wh: msgid.lock
| formail -D 65536 $HOME/.msgid.cache

In other words, the message ID "" was considered a duplicate after the
first one.


if you use postfix there would be uniq msgid always, eq postfix ensures 
there is always fqdn in msgid aswell, many mua's does not ensure the 
fqdn part


Re: empty message-ID

2020-11-23 Thread D'Arcy Cain

On 11/23/20 10:44 AM, Jaroslaw Rafa wrote:

Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:


I used to have a client who was not getting emails from one of his
friends.  Turned out that the friend's client/MUA was not adding the
message ID.


Doesn't Postfix automatically add Message-Id: header upon sending a message
if none is present?


I guess they weren't using Postfix.


After the first message was accepted all of the rest
were silently dropped as duplicates due to a very standard procmail
recipe:

:0 Wh: msgid.lock
| formail -D 65536 $HOME/.msgid.cache


Who uses that? It's not normal to get email duplicates and it usually
means that mail system is not functioning properly. They should find the
cause of the duplicates and eliminate it instead of hiding symptoms...


If someone replies to a mailing list and copies the sender then that person 
gets two copies.  The above recipe avoids that.


People also send to every alias that someone has.  Example, billing@, 
admin@, support@, joe@, etc.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vybenetworks.com
VoIP: sip:da...@vex.net


Re: simple temporary redirection(s) of all mail?

2020-11-23 Thread Wietse Venema
PGNet Dev:
> On 11/23/20 6:48 AM, Wietse Venema wrote:
> > Note that smtpd does not implement the virtual alias mapping. It
> > merely determines if the recipient address should be accepted or
> > rejected.
> > 
> > The virtual alias mapping happens on the other end of the
> > smtpd_proxy_filter (presumably, another smtpd process that feeds
> > into a cleanup process that does the virtual alias expansion).
> 
> Ah, Ok.  I can move the virtual_alias_* later.
> 
> Then I _think_ I need to conditionally avoid the
> 
>-o 
> address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

The address_verify_transport_maps setting is implemented by the
trivial-rewrite service. It has no effect on postscreen or smtpd.

Wietse


Re: hostname does not resolve to address warning

2020-11-23 Thread Wietse Venema
> postfix/smtpd[24986]: warning: hostname server17-ams1.internet-census.org
> does not resolve to address 107.6.163.34: Name or service not known

This is a type 4 error (the name->address mapping does not exist).

> postfix/smtpd[24986]: connect from unknown[107.6.163.34]
> postfix/smtpd[24986]: NOQUEUE: reject: CONNECT from unknown[107.6.163.34]:
> 450 4.7.25 Client host rejected: cannot find your hostname, 107.6.163.34];

Postfix was unable to determine the remote SMTP client hostname.
This error message is sent to the remote SMTP client. Error details
are not made available to the remote SMTP client. Error details are
logged only. Then, the local system administrator can deal with it.

Wietse


Re: hostname does not resolve to address warning

2020-11-23 Thread Eugene Podshivalov
 Thanks for the reply.

The warning says that "hostname does not resolve to address" (case #4) but
then the log says that connection is rejected because it cannot find a
hostname (case #2).
So which one is the actual rejection reason? Doesn't it feel a bit
confusing?

Regards


Без
вирусов. www.avast.ru

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

пн, 23 нояб. 2020 г. в 17:40, Wietse Venema :

> Eugene Podshivalov:
> > Hi all,
> > I have the following config
> >
> > > smtpd_client_restrictions =
> > > reject_unknown_client_hostname
> > > smtpd_helo_required = yes
> > > smtpd_helo_restrictions =
> > > reject_invalid_helo_hostname,
> > > reject_non_fqdn_helo_hostname,
> > > reject_unknown_helo_hostname
> > > smtpd_sender_restrictions =
> > > reject_non_fqdn_sender,
> > > reject_unknown_sender_domain
> >
> >
> > but still get warnings like this
> >
> > > postfix/smtpd[24986]: warning: hostname
> server17-ams1.internet-census.org
> > > does not resolve to address 107.6.163.34: Name or service not known
> > > postfix/smtpd[24986]: connect from unknown[107.6.163.34]
> > > postfix/smtpd[24986]: NOQUEUE: reject: CONNECT from
> unknown[107.6.163.34]:
> > > 450 4.7.25 Client host rejected: cannot find your hostname,
> [107.6.163.34];
> > > proto=SMTP
> > > postfix/smtpd[24986]: disconnect from unknown[107.6.163.34] ehlo=0/1
> > > quit=1 commands=1/2
>
> Postfix logs this warning, so that you can understand WHY a client
> may be rejected with reject_unknown_client_hostname, and how the
> problem may be fixed.
>
> 1 - A problem with the address->name mapping (lookup failed)
>
> 2 - A problem with the address->name mapping (the mapping does not
> exist).
>
> 3 - A problem with the name->address mapping (lookup failed)
>
> 4 - A problem with the name->address mapping (the mapping does not
> exist)
>
> 5 - A problem with the name->address mapping (the mapping does not
> match the client IP address)
>
> In your case the probkem was #4.
>
> Wietse
>


Re: simple temporary redirection(s) of all mail?

2020-11-23 Thread PGNet Dev

On 11/23/20 6:48 AM, Wietse Venema wrote:

Note that smtpd does not implement the virtual alias mapping. It
merely determines if the recipient address should be accepted or
rejected.

The virtual alias mapping happens on the other end of the
smtpd_proxy_filter (presumably, another smtpd process that feeds
into a cleanup process that does the virtual alias expansion).


Ah, Ok.  I can move the virtual_alias_* later.

Then I _think_ I need to conditionally avoid the

  -o address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

check in the 'postscreen-internal' smtpd stage.  Since I run this as an 
only-address_verify setup, when the backends are offline, that'll fail ...


Re: empty message-ID

2020-11-23 Thread Wietse Venema
Jaroslaw Rafa:
> Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:
> > 
> > I used to have a client who was not getting emails from one of his
> > friends.  Turned out that the friend's client/MUA was not adding the
> > message ID.
> 
> Doesn't Postfix automatically add Message-Id: header upon sending a message
> if none is present?

For the last 17 years, Message-ID is added to "local" email only.

http://www.postfix.org/postconf.5.html#always_add_missing_headers

> > After the first message was accepted all of the rest
> > were silently dropped as duplicates due to a very standard procmail
> > recipe:
> > 
> > :0 Wh: msgid.lock
> > | formail -D 65536 $HOME/.msgid.cache

They should skip that when email has no Message-Id: header.

Wietse


Re: empty message-ID

2020-11-23 Thread Phil Stracchino
On 11/23/20 9:18 AM, D'Arcy Cain wrote:
> On 11/23/20 9:49 AM, maciejm wrote:
>> Hi
>> Thanks for replay I found "RFC 822 Message-ID is not required"
>> Probably "problem" is in configurations in some clients.
> 
> I used to have a client who was not getting emails from one of his friends. 
>   Turned out that the friend's client/MUA was not adding the message ID. 
> After the first message was accepted all of the rest were silently dropped 
> as duplicates due to a very standard procmail recipe:
> 
> :0 Wh: msgid.lock
> | formail -D 65536 $HOME/.msgid.cache
> 
> In other words, the message ID "" was considered a duplicate after the first 
> one.


The lesson from which is, don't make message delivery dependent upon an
optional header.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958


Re: simple temporary redirection(s) of all mail?

2020-11-23 Thread Wietse Venema
PGNet Dev:
> On 11/22/20 11:58 AM, Wietse Venema wrote:
>
> > This would be good fit for virtual_alias_maps (and maybe adding
> > domains to virtual_alias_domains, see note below). virtual_alias_maps
> > replaces the envelope recipient without replacing header addresses,
> > and it works for single-recipient mail equally well as multi-recipient
> > mail.
>
> I'm trying this 'temporary redirect' approach for several configs.
>
> For one working setup/config, mail to "us...@example.com" is
> normally accepted by my postfix frontend, & flows through to my
> backend(s).
>
> Adding the intercepting virtual_alias_* redirect "early" in the
> frontend config
>
>   master.cf
>
>   [mx1.example.net]:25  inet  n  -  n  -  1  postscreen
>   -o postscreen_tls_security_level=may
>   -o 
> smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32
>   -o smtpd_service_name=postscreen-internal
>   postscreen-internal pass  -  -  n  -  -  smtpd
>   -o syslog_name=postfix/postscreen-internal
>   +   -o 
> virtual_alias_domains=lmdb:/etc/postfix/TEMP_virtual_alias_domains
>   +   -o virtual_alias_maps=lmdb:/etc/postfix/TEMP_virtual_alias_maps
>   -o smtpd_tls_ask_ccert=no
>   -o smtpd_tls_security_level=may
>   -o smtpd_tls_loglevel=1
>   -o smtpd_tls_received_header=yes
>   -o 
> address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map
>   -o 
> smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination,permit
>   -o 
> smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32
>   -o smtpd_client_connection_count_limit=25
>   -o smtpd_client_connection_rate_limit=0
>   -o anvil_rate_time_unit=60s
>   -o smtpd_proxy_timeout=300s
>   -o smtpd_proxy_options=speed_adjust
>   -o smtpd_proxy_filter=[127.0.0.1]:21030

Note that smtpd does not implement the virtual alias mapping. It
merely determines if the recipient address should be accepted or
rejected.

The virtual alias mapping happens on the other end of the
smtpd_proxy_filter (presumably, another smtpd process that feeds
into a cleanup process that does the virtual alias expansion).

Wietse


Re: empty message-ID

2020-11-23 Thread Jaroslaw Rafa
Dnia 23.11.2020 o godz. 10:18:39 D'Arcy Cain pisze:
> 
> I used to have a client who was not getting emails from one of his
> friends.  Turned out that the friend's client/MUA was not adding the
> message ID.

Doesn't Postfix automatically add Message-Id: header upon sending a message
if none is present?

> After the first message was accepted all of the rest
> were silently dropped as duplicates due to a very standard procmail
> recipe:
> 
> :0 Wh: msgid.lock
> | formail -D 65536 $HOME/.msgid.cache

Who uses that? It's not normal to get email duplicates and it usually
means that mail system is not functioning properly. They should find the
cause of the duplicates and eliminate it instead of hiding symptoms...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."


Re: hostname does not resolve to address warning

2020-11-23 Thread Wietse Venema
Eugene Podshivalov:
> Hi all,
> I have the following config
> 
> > smtpd_client_restrictions =
> > reject_unknown_client_hostname
> > smtpd_helo_required = yes
> > smtpd_helo_restrictions =
> > reject_invalid_helo_hostname,
> > reject_non_fqdn_helo_hostname,
> > reject_unknown_helo_hostname
> > smtpd_sender_restrictions =
> > reject_non_fqdn_sender,
> > reject_unknown_sender_domain
> 
> 
> but still get warnings like this
> 
> > postfix/smtpd[24986]: warning: hostname server17-ams1.internet-census.org
> > does not resolve to address 107.6.163.34: Name or service not known
> > postfix/smtpd[24986]: connect from unknown[107.6.163.34]
> > postfix/smtpd[24986]: NOQUEUE: reject: CONNECT from unknown[107.6.163.34]:
> > 450 4.7.25 Client host rejected: cannot find your hostname, [107.6.163.34];
> > proto=SMTP
> > postfix/smtpd[24986]: disconnect from unknown[107.6.163.34] ehlo=0/1
> > quit=1 commands=1/2

Postfix logs this warning, so that you can understand WHY a client
may be rejected with reject_unknown_client_hostname, and how the
problem may be fixed.

1 - A problem with the address->name mapping (lookup failed)

2 - A problem with the address->name mapping (the mapping does not
exist).

3 - A problem with the name->address mapping (lookup failed)

4 - A problem with the name->address mapping (the mapping does not
exist)

5 - A problem with the name->address mapping (the mapping does not
match the client IP address)

In your case the probkem was #4.

Wietse


Re: simple temporary redirection(s) of all mail?

2020-11-23 Thread PGNet Dev

On 11/22/20 11:58 AM, Wietse Venema wrote:


This would be good fit for virtual_alias_maps (and maybe adding



domains to virtual_alias_domains, see note below). virtual_alias_maps



replaces the envelope recipient without replacing header addresses,



and it works for single-recipient mail equally well as multi-recipient



mail.




I'm trying this 'temporary redirect' approach for several configs.



For one working setup/config, mail to "us...@example.com" is normally accepted by 
my postfix frontend, & flows through to my backend(s).



Adding the intercepting virtual_alias_* redirect "early" in the frontend config



master.cf



[mx1.example.net]:25  inet  n  -  n  -  1  postscreen

-o postscreen_tls_security_level=may

-o 
smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32

-o smtpd_service_name=postscreen-internal



postscreen-internal pass  -  -  n  -  -  smtpd

-o syslog_name=postfix/postscreen-internal

+   -o 
virtual_alias_domains=lmdb:/etc/postfix/TEMP_virtual_alias_domains

+   -o virtual_alias_maps=lmdb:/etc/postfix/TEMP_virtual_alias_maps

-o smtpd_tls_ask_ccert=no

-o smtpd_tls_security_level=may

-o smtpd_tls_loglevel=1

-o smtpd_tls_received_header=yes

-o 
address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

-o 
smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination,permit

-o 
smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32

-o smtpd_client_connection_count_limit=25

-o smtpd_client_connection_rate_limit=0

-o anvil_rate_time_unit=60s

-o smtpd_proxy_timeout=300s

-o smtpd_proxy_options=speed_adjust

-o smtpd_proxy_filter=[127.0.0.1]:21030



...



where



cat /etc/postfix/TEMP_virtual_alias_domains

example.comREDIRECT



cat /etc/postfix/TEMP_virtual_alias_maps

us...@example.comus...@someother.com





With that^, I intended for mail to



us...@example.com



to be immediately intercepted+redirected to us...@someother.com.



It does not.

Instead, it flows through as usual to my backend.



I _think_ my virtual_alias_* syntax/usage is correct.

Is the fail-to-redirect an order of execution problem?



My notes on usual exec order are:



postscreen, smtpd_mumble_restrictions, milter SMTP command inspection,

smtpd_proxy_filter, header/body_checks, milter header/body inspection, 
content_filter



Is the virtual_alias_* considered a "header/body_checks", lower in priority than the 
existing/used "smtpd_proxy_filter",

and hence is ignored?



Or is my fail to redirect due to another cause?





Re: empty message-ID

2020-11-23 Thread D'Arcy Cain

On 11/23/20 9:49 AM, maciejm wrote:

Hi
Thanks for replay I found "RFC 822 Message-ID is not required"
Probably "problem" is in configurations in some clients.


I used to have a client who was not getting emails from one of his friends. 
 Turned out that the friend's client/MUA was not adding the message ID. 
After the first message was accepted all of the rest were silently dropped 
as duplicates due to a very standard procmail recipe:


:0 Wh: msgid.lock
| formail -D 65536 $HOME/.msgid.cache

In other words, the message ID "" was considered a duplicate after the first 
one.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vybenetworks.com
VoIP: sip:da...@vex.net


Re: empty message-ID

2020-11-23 Thread maciejm
Hi
Thanks for replay I found "RFC 822 Message-ID is not required"
Probably "problem" is in configurations in some clients.

On 23.11.2020 14:39, Matus UHLAR - fantomas wrote:
> On 23.11.20 14:35, natan wrote:
>> I have probably to trivial questions about message-ID
>>
>> Why sometimes, some user have empty message-id=<>
>>
>> example:
>> Nov 23 13:13:53 smtp1 postfix/submission/smtpd[29867]: 4CfmKF1CSDz5MwK:
>> .domain.ltd[xxx.xxx.xxx.xxx], sasl_method=login,
>> sasl_username=bi...@domain2.ltd
>> Nov 23 13:13:53 smtp1 postfix/cleanup[46909]: 4CfmKF1CSDz5MwK:
>> message-id=<>
>> Nov 23 13:13:53 smtp1 postfix/qmgr[25287]: 4CfmKF1CSDz5MwK:
>> from=, size=94874, nrcpt=3 (queue active)
>> .
>
> client's MUA apparently does not generate Message-Id: header.
>



Re: empty message-ID

2020-11-23 Thread Matus UHLAR - fantomas

On 23.11.20 14:35, natan wrote:

I have probably to trivial questions about message-ID

Why sometimes, some user have empty message-id=<>

example:
Nov 23 13:13:53 smtp1 postfix/submission/smtpd[29867]: 4CfmKF1CSDz5MwK:
.domain.ltd[xxx.xxx.xxx.xxx], sasl_method=login,
sasl_username=bi...@domain2.ltd
Nov 23 13:13:53 smtp1 postfix/cleanup[46909]: 4CfmKF1CSDz5MwK: message-id=<>
Nov 23 13:13:53 smtp1 postfix/qmgr[25287]: 4CfmKF1CSDz5MwK:
from=, size=94874, nrcpt=3 (queue active)
.


client's MUA apparently does not generate Message-Id: header.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*


empty message-ID

2020-11-23 Thread natan
Hi
I have probably to trivial questions about message-ID

Why sometimes, some user have empty message-id=<>

example:
Nov 23 13:13:53 smtp1 postfix/submission/smtpd[29867]: 4CfmKF1CSDz5MwK:
.domain.ltd[xxx.xxx.xxx.xxx], sasl_method=login,
sasl_username=bi...@domain2.ltd
Nov 23 13:13:53 smtp1 postfix/cleanup[46909]: 4CfmKF1CSDz5MwK: message-id=<>
Nov 23 13:13:53 smtp1 postfix/qmgr[25287]: 4CfmKF1CSDz5MwK:
from=, size=94874, nrcpt=3 (queue active)
.



--



hostname does not resolve to address warning

2020-11-23 Thread Eugene Podshivalov
Hi all,
I have the following config

> smtpd_client_restrictions =
> reject_unknown_client_hostname
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname,
> reject_unknown_helo_hostname
> smtpd_sender_restrictions =
> reject_non_fqdn_sender,
> reject_unknown_sender_domain


but still get warnings like this

> postfix/smtpd[24986]: warning: hostname server17-ams1.internet-census.org
> does not resolve to address 107.6.163.34: Name or service not known
> postfix/smtpd[24986]: connect from unknown[107.6.163.34]
> postfix/smtpd[24986]: NOQUEUE: reject: CONNECT from unknown[107.6.163.34]:
> 450 4.7.25 Client host rejected: cannot find your hostname, [107.6.163.34];
> proto=SMTP
> postfix/smtpd[24986]: disconnect from unknown[107.6.163.34] ehlo=0/1
> quit=1 commands=1/2


My understanding is that there should be no warning because the issue is
explicitly checked by the "reject_unknown_client_hostname" directive.
Am I missing something? Is it possible to eliminate this warning?

Thanks


Без
вирусов. www.avast.ru

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>