Re: New install - Temporary lookup failures when trying to send

[Matus UHLAR - fantomas]

On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas   
said:

pleaase, get a decent MUA, not applemail that tries to encode everything as
internet links (and messes up thge plaintext version of mail).


On 04.12.18 13:47, @lbutlr wrote:

What do you base this statement on?  I’ve been using Apple’s Meal.app since
around 2003 or so, and I’ve never had it encode everything as Internet
links more mess up plaintext mail.


based on sender's 


X-Mailer: Apple Mail (2.3445.102.3)

and the result I have quoted that is also visible on:

https://marc.info/?l=postfix-users&m=154380074926895&w=2

the HTML parts may be encoded properly, but the plaintext version of sent
mail contains useless crap where



is converted to:

mailto:jlbr...@bordo.com.au>>

and:

mail.bordo.com.au

is converted to:

mail.bordo.com.au 


--
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.
LSD will make your ECS screen display 16.7 million colors

Re: client incorrect greeting error, how to resolve?

[Matus UHLAR - fantomas]

On 05.12.18 23:24, Voytek wrote:

# grep connectmain.cf
smtpd_client_connection_rate_limit = 12
smtpd_client_connection_count_limit = 5



sorry.. and thank you.

another dumb question:
so if I have 25 clients on a NATed LAN, that's my connection count limit,
isn't it ?


may be and may not be. it's possible that client sends multiple mail in
parallel.


and I think I've found my problem: when they changed IP on the site, I
forgot to add IP to:
smtpd_client_event_limit_exceptions = 147.50.1.226

if I have it here I don;t need to worry about the other limits, isn't it?


smtpd_client_*_count/rate_limit restrictions, according to:

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


--
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.
2B|!2B, that's a question!

Best practice - concurrent delivery to remote sites

[Stefan Bauer]

Hi,

we're running a small relay-service and looking for best practice to
deliver mails to remote sites regarding concurrent delivery and so on.

Sometimes, we have customers that are sending several mails per second to
same recipients.

What is best practice to handle this?

We would like to avoid getting blacklisted or throttled by remote sites due
to sending too many mails or in an non compliant way. How should this be
handled/configured in postfix?

so far all settings are default in postfix.

thank you.

Cyrus SASL with httpform

[Jaco Lesch]

Hello there

Anybody out there have had any success with httpform authentication 
using Cyrus SASL? I am able to compile Cyrus SASL with the following 
mechanisms:

saslauthd 2.1.26
authentication mechanisms: getpwent pam rimap shadow httpform

And to link the SASL libraries to Postfix, but how to get the HTTP 
authentication bit to work with saslauthd is the head scratcher.


Any help, or pointers will be appreciated.

Regards

--
---
Jaco Lesch
SAIX HLS
Email: ja...@saix.net

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Stefan Bauer!

> Hi,


> we're running a small relay-service and looking for best practice to
> deliver mails to remote sites regarding concurrent delivery and so on.


> Sometimes, we have customers that are sending several mails per second to 
> same recipients.


> What is best practice to handle this?


> We would like to avoid getting blacklisted or throttled by remote sites due
> to sending too many mails or in an non compliant way. How should this be 
> handled/configured in postfix?


This has nothing to do with postfix itself.
Social issues can't be solved by technical means.

> so far all settings are default in postfix.



> thank you.


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 14:39:20

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Stefan Bauer]

Its no user issue. Its a real and legal use case that customers send
several mails / second to same recipient over a long period (software tests
whatever).

Am Do., 6. Dez. 2018 um 12:50 Uhr schrieb Andrey Repin :

> Greetings, Stefan Bauer!
>
> > Hi,
>
>
> > we're running a small relay-service and looking for best practice to
> > deliver mails to remote sites regarding concurrent delivery and so on.
>
>
> > Sometimes, we have customers that are sending several mails per second
> to same recipients.
>
>
> > What is best practice to handle this?
>
>
> > We would like to avoid getting blacklisted or throttled by remote sites
> due
> > to sending too many mails or in an non compliant way. How should this be
> handled/configured in postfix?
>
>
> This has nothing to do with postfix itself.
> Social issues can't be solved by technical means.
>
> > so far all settings are default in postfix.
>
>
>
> > thank you.
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, December 6, 2018 14:39:20
>
> Sorry for my terrible english...
>
>

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Stefan Bauer!

 >>> we're running a small relay-service and looking for best practice to
 >>> deliver mails to remote sites regarding concurrent delivery and so on.
>>  
>>  
 >>> Sometimes, we have customers that are sending several mails per second to 
 >>> same recipients.
>>  
>>  
 >>> What is best practice to handle this?
>>  
>>  
 >>> We would like to avoid getting blacklisted or throttled by remote sites due
 >>> to sending too many mails or in an non compliant way. How should this be 
 >>> handled/configured in postfix?
>>  
>>  
>>  This has nothing to do with postfix itself.
>>  Social issues can't be solved by technical means.
>>  
 >>> so far all settings are default in postfix.
>>  
>>  
>>  
 >>> thank you.
>>  

> Its no user issue. Its a real and legal use case that customers send
> several mails / second to same recipient over a long period (software tests 
> whatever).

Did I say anything about reality or legality?
The decision of remote host to block you is 100% social, not technical or
legal.
How do they judge you is entirely up to them, as long as you conform to
standards, you can't do anything short of communicating with the owners and
solving any arising issues as they happen.


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 15:00:05

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Stefan Bauer]

ack. but i was looking for advices like e.g:

initially defer mail delivery for lets say a minute to be able to send out
a bunch of mails to same recipient in a single session instead of having
100 independant sessions.

stuff/best practice that makes the process more effective.

i'm certain that remote sites prefer one way over the other.

Stefan

Am Donnerstag, 6. Dezember 2018 schrieb Andrey Repin :
> Greetings, Stefan Bauer!
>
>  >>> we're running a small relay-service and looking for best practice to
>  >>> deliver mails to remote sites regarding concurrent delivery and so
on.
>>>
>>>
>  >>> Sometimes, we have customers that are sending several mails per
second to same recipients.
>>>
>>>
>  >>> What is best practice to handle this?
>>>
>>>
>  >>> We would like to avoid getting blacklisted or throttled by remote
sites due
>  >>> to sending too many mails or in an non compliant way. How should
this be handled/configured in postfix?
>>>
>>>
>>>  This has nothing to do with postfix itself.
>>>  Social issues can't be solved by technical means.
>>>
>  >>> so far all settings are default in postfix.
>>>
>>>
>>>
>  >>> thank you.
>>>
>
>> Its no user issue. Its a real and legal use case that customers send
>> several mails / second to same recipient over a long period (software
tests whatever).
>
> Did I say anything about reality or legality?
> The decision of remote host to block you is 100% social, not technical or
> legal.
> How do they judge you is entirely up to them, as long as you conform to
> standards, you can't do anything short of communicating with the owners
and
> solving any arising issues as they happen.
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, December 6, 2018 15:00:05
>
> Sorry for my terrible english...
>
>

Re: Cyrus SASL with httpform

[Rick van Rein]

Hi Jaco,

Although this is not exactly what you are asking, but we're working on
HTTP SASL authentication, so one level below the HTML forms that you are
talking about.

http://internetwide.org/blog/2018/11/15/somethings-cooking-4.html

There is an early Docker Demo with a plugin to add SASL to FireFox,
based on the recently standardised notion of Native Messaging,

https://github.com/arpa2/docker-demo/tree/master/demo-ffsasl

Maybe that is (a direction for) a solution.  HTML forms are not likely
to support the any-number-of-back-and-forths that SASL requires, in general.

Cheers,
 -Rick

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Stefan Bauer!

> ack. but i was looking for advices like e.g:

> initially defer mail delivery for lets say a minute to be able to send out
> a bunch of mails to same recipient in a single session instead of having 100 
> independant sessions.

For queue management, look at http://www.postfix.org/qmgr.8.html
I can't provide exact solutions, as I'm solving a similar problem myself ATM.

> stuff/best practice that makes the process more effective.

> i'm certain that remote sites prefer one way over the other.

Sure they are. To each their own.


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 15:52:37

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Wietse Venema]

Stefan Bauer:
> stuff/best practice that makes the process more effective.
> 
> i'm certain that remote sites prefer one way over the other.

I don't think that there is a 'standard' policy that 'works' for
delivery from every site to every site.

Nowadays you get a policy exception from 'big' receivers, and you
come up with transport_maps with different 'classes' of delivery
agents that are configured with different rate_delay (no concurrency),
with limited concurrency, and/or with different source IP address,
then pick the agent depending on destination.

Or you just pay a mail sending company for doing the job.

Wietse

Re: New install - Temporary lookup failures when trying to send

[Larry Stone]

> On Dec 6, 2018, at 3:00 AM, Matus UHLAR - fantomas  wrote:
> 
>> On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas
>> said:
>>> pleaase, get a decent MUA, not applemail that tries to encode everything as
>>> internet links (and messes up thge plaintext version of mail).
> 
> On 04.12.18 13:47, @lbutlr wrote:
>> What do you base this statement on?  I’ve been using Apple’s Meal.app since
>> around 2003 or so, and I’ve never had it encode everything as Internet
>> links more mess up plaintext mail.
> 
> based on sender's 
> X-Mailer: Apple Mail (2.3445.102.3)
> 
> and the result I have quoted that is also visible on:
> 
> https://marc.info/?l=postfix-users&m=154380074926895&w=2
> 
> the HTML parts may be encoded properly, but the plaintext version of sent
> mail contains useless crap where
> 
> 
> 
> is converted to:
> 
> mailto:jlbr...@bordo.com.au>>
> 
> and:
> 
> mail.bordo.com.au
> 
> is converted to:
> 
> mail.bordo.com.au 

That does not appear to be the standard Apple Mail. I am running MacOS 10.14.1 
(the latest until 10.14.2 was released yesterday) and I have 
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
X-Mailer: Apple Mail (2.3445.101.1)

while jlbr...@bordo.com.au has
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
X-Mailer: Apple Mail (2.3445.102.3)

It’s possible that’s a new version included with 10.14.2 but Mr. Brown sent his 
message four days ago and 10.14.2 was released yesterday (he might have been 
running a pre-release version). It’s possible that however he pasted that into 
his message did that. It’s also possible that something downline of Mr. Brown 
at bordo.com.au is changing the message, converting it to multi-part, and 
adding that crap. I do note in the headers of his message that there are a 
bunch related to an anti-spam product called ASSP. I’ve never heard of it 
before and have no idea if it has that capability.
X-Assp-Version: 2.6.2(18328) on mail.bordo.com.au
X-Assp-ID: mail.bordo.com.au id-00682-15042
X-Assp-Session: 7FB04622FB68 (mail 1)
X-Assp-Envelope-From: jlbr...@bordo.com.au
X-Assp-Intended-For: postfix-users@postfix.org
X-Assp-Client-SSL: yes
X-Assp-Server-TLS: yes

In any event, unless I’m missing it, the version I and most everyone else has 
of Apple Mail does not do that. I’ve sent a test message to myself with HTML 
included and there was no conversion of links. And this message was sent with 
Apple Mail.

-- 
Larry Stone
lston...@stonejongleux.com

Re: Best practice - concurrent delivery to remote sites

[Stefan Bauer]

Thank you Wietse,

wouldn't default_transport_rate_delay = 15s

be a safe setting to relax the whole transport a bit?

from a receivers perspective, that's something i would like to see instead
of having ongoing delivery.

Am Do., 6. Dez. 2018 um 14:41 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:

> Stefan Bauer:
> > stuff/best practice that makes the process more effective.
> >
> > i'm certain that remote sites prefer one way over the other.
>
> I don't think that there is a 'standard' policy that 'works' for
> delivery from every site to every site.
>
> Nowadays you get a policy exception from 'big' receivers, and you
> come up with transport_maps with different 'classes' of delivery
> agents that are configured with different rate_delay (no concurrency),
> with limited concurrency, and/or with different source IP address,
> then pick the agent depending on destination.
>
> Or you just pay a mail sending company for doing the job.
>
> Wietse
>

Re: New install - Temporary lookup failures when trying to send

[Matus UHLAR - fantomas]

On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas   
said:

pleaase, get a decent MUA, not applemail that tries to encode everything as
internet links (and messes up thge plaintext version of mail).



On Dec 6, 2018, at 3:00 AM, Matus UHLAR - fantomas  wrote:
X-Mailer: Apple Mail (2.3445.102.3)


On 06.12.18 07:56, Larry Stone wrote:

That does not appear to be the standard Apple Mail.  I am running MacOS
10.14.1 (the latest until 10.14.2 was released yesterday) and I have
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
X-Mailer: Apple Mail (2.3445.101.1)

while jlbr...@bordo.com.au has
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
X-Mailer: Apple Mail (2.3445.102.3)


I see @lbutlr has the same version:

X-Mailer: Apple Mail (2.3445.102.3)

although no Mime-Version: header.


It’s possible that’s a new version included with 10.14.2 but Mr.  Brown
sent his message four days ago and 10.14.2 was released yesterday (he
might have been running a pre-release version).  It’s possible that
however he pasted that into his message did that.  It’s also possible that
something downline of Mr.  Brown at bordo.com.au is changing the message,
converting it to multi-part, and adding that crap.  I do note in the
headers of his message that there are a bunch related to an anti-spam
product called ASSP.  I’ve never heard of it before and have no idea if it
has that capability.



X-Assp-Version: 2.6.2(18328) on mail.bordo.com.au
X-Assp-ID: mail.bordo.com.au id-00682-15042
X-Assp-Session: 7FB04622FB68 (mail 1)
X-Assp-Envelope-From: jlbr...@bordo.com.au
X-Assp-Intended-For: postfix-users@postfix.org
X-Assp-Client-SSL: yes
X-Assp-Server-TLS: yes

In any event, unless I’m missing it, the version I and most everyone else
has of Apple Mail does not do that.  I’ve sent a test message to myself
with HTML included and there was no conversion of links.  And this message
was sent with Apple Mail.


This and @lbutlr mail were plaintext-only. Maybe multipart mail has them 
encoded in plaintext versions?

Anyway, sorry for the noise.

however, my questions weren't responded and still apply:


Are those cf files properly configured? Can postfix connect to the database?
What's in the logs?


and also the comment:


Not sure where I’ve gone wrong. Copied most config details across from my 
working (older) mail server.


often not a good idea, your postfix config file has too many options where I
believe many could be left default.


--
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.
Christian Science Programming: "Let God Debug It!".

Re: Best practice - concurrent delivery to remote sites

[Wietse Venema]

Wietse:
> > I don't think that there is a 'standard' policy that 'works' for
> > delivery from every site to every site.
> >
> > Nowadays you get a policy exception from 'big' receivers, and you
> > come up with transport_maps with different 'classes' of delivery
> > agents that are configured with different rate_delay (no concurrency),
> > with limited concurrency, and/or with different source IP address,
> > then pick the agent depending on destination.
> >
> > Or you just pay a mail sending company for doing the job.

Stefan Bauer:
> Thank you Wietse,
> 
> wouldn't default_transport_rate_delay = 15s
> 
> be a safe setting to relax the whole transport a bit?

It is a big sledgehammer that allows 4 delivers per minute per
destination (or per transport). If that works for you, great.
Just keep in mind that 'postfix reload' will reset the rate
delay timers.

Wietse

Local delivery to mbox / inode issue

[Dominic Raferd]

I am using incrond to monitor an mbox file (in /var/mail) for changes, but
it is failing to trigger when postfix adds an incoming mail to the file.
(It triggers fine however if I touch the file.)

I may be barking up the wrong tree but I wonder if this is because instead
of merely appending to the existing mbox file, postfix/local rewrites the
file so that its inode changes (which I know breaks incrond's ability to
monitor a file). If so, is there a way to get postfix to append to the file
without changing the inode, and if so what are the disadvantages?

I have postfix 3.3.0, local has default settings, and /var/mail is on
filesystem ext4 (options rw,relatime,data=ordered) under Ubuntu 18.04.1
(GNU/Linux 4.15).

Finding reason for smtpd rejections

[Rich Shepard]

Today's pflogsumm report includes this rejection:

Recipient address rejected: Please see http (total: 2)
   2   rshep...@appl-ecosys.com

Since this is my address I'm curious why two incoming messages were rejected
when many more were passed. I'd appreciate advice on how I can identify
these two messages in /var/log/maillog.1 among all the logged incoming
messages to this address.

TIA,

Rich

Re: Local delivery to mbox / inode issue

[Wietse Venema]

Dominic Raferd:
> I am using incrond to monitor an mbox file (in /var/mail) for changes, but
> it is failing to trigger when postfix adds an incoming mail to the file.

Possible causes:

- Your file system does not set the file mtime when Postfix appends
to the file. Fix: don't disable mtime updates for append operations.

- There is a clock drift problem where the host with Postfix has
different time than the host with the file system. Fix: run NTP on
both hosts.

> (It triggers fine however if I touch the file.)
> 
> I may be barking up the wrong tree but I wonder if this is because instead
> of merely appending to the existing mbox file, postfix/local rewrites the
> file so that its inode changes (which I know breaks incrond's ability to
> monitor a file). If so, is there a way to get postfix to append to the file
> without changing the inode, and if so what are the disadvantages?

Have you verified that the inode number changes?

Postfix opens an mbox file with O_APPEND mode which is standardized
by the POSIX API. If that causes the file inode number to change,
then you need to use a different file system.

Wietse

> I have postfix 3.3.0, local has default settings, and /var/mail is on
> filesystem ext4 (options rw,relatime,data=ordered) under Ubuntu 18.04.1
> (GNU/Linux 4.15).

Re: Finding reason for smtpd rejections

[Noel Jones]

On 12/6/2018 9:59 AM, Rich Shepard wrote:
> Today's pflogsumm report includes this rejection:
> 
>     Recipient address rejected: Please see http (total: 2)
>    2   rshep...@appl-ecosys.com
> 
> Since this is my address I'm curious why two incoming messages were
> rejected
> when many more were passed. I'd appreciate advice on how I can identify
> these two messages in /var/log/maillog.1 among all the logged incoming
> messages to this address.
> 
> TIA,
> 
> Rich
> 


To see just the logged rejection (which is often enough):

grep reject: /var/log/maillog.1 | grep rshep...@appl-ecosys.com



To see more context of the connection that was rejected, open the
file with your favorite text editor and search for
   /reject: .*rshepard@appl-ecosys


Wild guess:  some spammer used your own address as sender, and the
connection was rejected by some of your spam controls, probably an rbl.




  -- Noel Jones

Re: Finding reason for smtpd rejections

[Wietse Venema]

Rich Shepard:
> Today's pflogsumm report includes this rejection:
> 
>  Recipient address rejected: Please see http (total: 2)
> 2   rshep...@appl-ecosys.com
> 
> Since this is my address I'm curious why two incoming messages were rejected
> when many more were passed. I'd appreciate advice on how I can identify
> these two messages in /var/log/maillog.1 among all the logged incoming
> messages to this address.

pflogsumm *summarizes* a detailed logfile.

You look at the *detailed* log messages that produced the above result.

Wietse

Re: Local delivery to mbox / inode issue

[Dominic Raferd]

Thanks for the swift response - see below.

On Thu, 6 Dec 2018 at 16:10, Wietse Venema  wrote:

> Dominic Raferd:
> > I am using incrond to monitor an mbox file (in /var/mail) for changes,
> but
> > it is failing to trigger when postfix adds an incoming mail to the file.
>
> Possible causes:
>
> - Your file system does not set the file mtime when Postfix appends
> to the file. Fix: don't disable mtime updates for append operations.
>

- it does set the mtime when Postfix appends to the file

- There is a clock drift problem where the host with Postfix has
> different time than the host with the file system. Fix: run NTP on
> both hosts.
>

- Postfix is on the same host as the filesystem

> > (It triggers fine however if I touch the file.)
> >
> > I may be barking up the wrong tree but I wonder if this is because
> instead
> > of merely appending to the existing mbox file, postfix/local rewrites the
> > file so that its inode changes (which I know breaks incrond's ability to
> > monitor a file). If so, is there a way to get postfix to append to the
> file
> > without changing the inode, and if so what are the disadvantages?
>
> Have you verified that the inode number changes?
>

no, I will check how to do this

Postfix opens an mbox file with O_APPEND mode which is standardized
> by the POSIX API. If that causes the file inode number to change,
> then you need to use a different file system.
>

In this case I suspect that the inode issue is not the cause of incrond's
problem.

Re: Local delivery to mbox / inode issue

[Bill Cole]

On 6 Dec 2018, at 11:15, Dominic Raferd wrote:

>> Have you verified that the inode number changes?
>>
>
>
> no, I will check how to do this


'ls -li' is your friend.

Re: Finding reason for smtpd rejections

[Rich Shepard]

On Thu, 6 Dec 2018, Noel Jones wrote:


Wild guess:  some spammer used your own address as sender, and the
connection was rejected by some of your spam controls, probably an rbl.


Noel,

  There are certainly many rejected by a couple of rbls as well as by other
postfix UCE checks. Why these two were listed separately by pflogsumm is not
obvious when I look at the list grep returned.

Thanks,

Rich

Re: Finding reason for smtpd rejections

[Noel Jones]

On 12/6/2018 10:46 AM, Rich Shepard wrote:
> On Thu, 6 Dec 2018, Noel Jones wrote:
> 
>> Wild guess:  some spammer used your own address as sender, and the
>> connection was rejected by some of your spam controls, probably an
>> rbl.
> 
> Noel,
> 
>   There are certainly many rejected by a couple of rbls as well as
> by other
> postfix UCE checks. Why these two were listed separately by
> pflogsumm is not
> obvious when I look at the list grep returned.
> 
> Thanks,
> 
> Rich


Possibly there are more clues in pflogsumm's output, such as the
heading or something else.  Depending on how compact you've set the
output, it might be hard to identify with the existing information.
 The heading may give the clue about which rule or control rejected
these.

Maybe re-running pflogsumm with increasing detail will give hints
about which two rejections it's referring to.



  -- Noel Jones

Re: Local delivery to mbox / inode issue

[Dominic Raferd]

On Thu, 6 Dec 2018 at 16:37, Bill Cole <
postfixlists-070...@billmail.scconsult.com> wrote:

> On 6 Dec 2018, at 11:15, Dominic Raferd wrote:
>
> >> Have you verified that the inode number changes?
> >>
> >
> >
> > no, I will check how to do this
>
>
> 'ls -li' is your friend.
>

Thanks, I have now used this to confirm that the inode number does not
change when postfix/local updates the mbox file. So the problem with
incrond lies elsewhere.

Re: Local delivery to mbox / inode issue

[Bill Cole]

On 6 Dec 2018, at 12:13, Dominic Raferd wrote:


On Thu, 6 Dec 2018 at 16:37, Bill Cole <
postfixlists-070...@billmail.scconsult.com> wrote:


On 6 Dec 2018, at 11:15, Dominic Raferd wrote:


Have you verified that the inode number changes?




no, I will check how to do this



'ls -li' is your friend.



Thanks, I have now used this to confirm that the inode number does not
change when postfix/local updates the mbox file. So the problem with
incrond lies elsewhere.


One thing to check is the sysctl parameter 'fs.inotify.max_user_watches' 
(which is what its name implies.)  Some (EL-family, for example) 
distributions default to a low value (8K) which is a very easy limit to 
hit with a tool like incron that is designed to exploit inotify to its 
fullest.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Wietse Venema!

> Wietse:
>> > I don't think that there is a 'standard' policy that 'works' for
>> > delivery from every site to every site.
>> >
>> > Nowadays you get a policy exception from 'big' receivers, and you
>> > come up with transport_maps with different 'classes' of delivery
>> > agents that are configured with different rate_delay (no concurrency),
>> > with limited concurrency, and/or with different source IP address,
>> > then pick the agent depending on destination.
>> >
>> > Or you just pay a mail sending company for doing the job.

> Stefan Bauer:
>> Thank you Wietse,
>> 
>> wouldn't default_transport_rate_delay = 15s
>> 
>> be a safe setting to relax the whole transport a bit?

> It is a big sledgehammer that allows 4 delivers per minute per
> destination (or per transport). If that works for you, great.
> Just keep in mind that 'postfix reload' will reset the rate
> delay timers.

Assuming his use case (hundreds of mails could be generated per minute to the
same destination), this seems appropriate.
I'm considering doing the same on my relay systems, to limit the rate at which
they talk to the smarthost.
My use case is not "hundreds", but I'd rather have this level of throttling,
than leaving a wide open gap for brute force attacks.
(As I'm not a huge fan of fail2ban. I prefer more direct approaches.)


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 21:16:00

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Wietse Venema!

>> default_transport_rate_delay = 15s

I'd like to ask for clarification, as man page wording is not clear.

The original wording is

> The default amount of delay that is inserted between individual deliveries
> over the same message delivery transport, regardless of destination. If
> non-zero, all deliveries over the same message delivery transport will
> happen one at a time.

To me, it is unclear,
- what considered "individual deliveries"? Individual messages? Individual
connects to the destination?
- what "one at a time" means exactly? Will queue manager connect and
disconnect for each message in queue? Will it try to deliver multiple messages
to the same destination in parallel, over multiple connections?


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 21:23:52

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Viktor Dukhovni]

> On Dec 6, 2018, at 1:28 PM, Andrey Repin  wrote:
> 
>> The default amount of delay that is inserted between individual deliveries
>> over the same message delivery transport, regardless of destination. If
>> non-zero, all deliveries over the same message delivery transport will
>> happen one at a time.
> 
> To me, it is unclear,
> - what considered "individual deliveries"? Individual messages? Individual
> connects to the destination?

One delivery at a time.  A delivery is a handoff of a message with a set of
recipients of that message to a delivery agent for processing.

> - what "one at a time" means exactly?

Less than two or more in parallel.

> Will queue manager connect and disconnect for each message in queue?

The queue manager does not connect to remote destinations, delivery
agents make connections.  The queue manager asks delivery agents to
perform work, and collects the results.

> Will it try to deliver multiple messages
> to the same destination in parallel, over multiple connections?

One delivery at a time, with the configured delay between deliveries.
[ where one is less than two. ]

-- 
Viktor.

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Viktor Dukhovni!

>>> The default amount of delay that is inserted between individual deliveries
>>> over the same message delivery transport, regardless of destination. If
>>> non-zero, all deliveries over the same message delivery transport will
>>> happen one at a time.
>> 
>> To me, it is unclear,
>> - what considered "individual deliveries"? Individual messages? Individual
>> connects to the destination?

> One delivery at a time.  A delivery is a handoff of a message with a set of
> recipients of that message to a delivery agent for processing.

>> - what "one at a time" means exactly?

> Less than two or more in parallel.

>> Will queue manager connect and disconnect for each message in queue?

> The queue manager does not connect to remote destinations, delivery
> agents make connections.  The queue manager asks delivery agents to
> perform work, and collects the results.

>> Will it try to deliver multiple messages
>> to the same destination in parallel, over multiple connections?

> One delivery at a time, with the configured delay between deliveries.
> [ where one is less than two. ]

In other words, if I have multiple different messages to the same destination,
I can't know if they will be delivered through single connection?
And can't control it?


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 22:07:44

Sorry for my terrible english...

Re: Best practice - concurrent delivery to remote sites

[Viktor Dukhovni]

> On Dec 6, 2018, at 2:19 PM, Andrey Repin  wrote:
> 
> In other words, if I have multiple different messages to the same destination,
> I can't know if they will be delivered through single connection?
> And can't control it?

If the inter-message spacing exceeds the either of:

http://www.postfix.org/postconf.5.html#connection_cache_ttl_limit
http://www.postfix.org/postconf.5.html#smtp_connection_cache_time_limit

then any cached connections would be closed before it is time to send
another message.  Generally, with serialized deliveries, you should not
cache connections.  Keeping idle connections open is anti-social, you're
consuming remote resources.

A transport with a destination rate delay will not do demand caching,
which IIRC requires either concurrent or closely spaced deliveries
before it is enabled.

Bottom line, with rate delays, each delivery would be expected to use a new
connection.  On demand connection re-use is not compatible with rate delays.

-- 
Viktor.

Re: Best practice - concurrent delivery to remote sites

[Andrey Repin]

Greetings, Viktor Dukhovni!

>> On Dec 6, 2018, at 2:19 PM, Andrey Repin  wrote:
>> 
>> In other words, if I have multiple different messages to the same 
>> destination,
>> I can't know if they will be delivered through single connection?
>> And can't control it?

> If the inter-message spacing exceeds the either of:

> http://www.postfix.org/postconf.5.html#connection_cache_ttl_limit
>
> http://www.postfix.org/postconf.5.html#smtp_connection_cache_time_limit

> then any cached connections would be closed before it is time to send
> another message.  Generally, with serialized deliveries, you should not
> cache connections.  Keeping idle connections open is anti-social, you're
> consuming remote resources.

> A transport with a destination rate delay will not do demand caching,
> which IIRC requires either concurrent or closely spaced deliveries
> before it is enabled.

> Bottom line, with rate delays, each delivery would be expected to use a new
> connection.  On demand connection re-use is not compatible with rate delays.

Thank you for your assistance.
I see how lingering connections could be a worse problem than multiple
simultaneous connections.
I'll have to think this issue through again.
And probably start a new topic for it.


-- 
With best regards,
Andrey Repin
Friday, December 7, 2018 0:12:45

Sorry for my terrible english...

Re: New install - Temporary lookup failures when trying to send

[@lbutlr]

On 5 Dec 2018, at 07:34, Bill Cole  
wrote:
> On 2 Dec 2018, at 20:31, James Brown wrote:
> 
>> I’m trying to set up a new mail server on macOS Mojave and it almost works. 
>> Dovecot for IMAP is working.
> 
> This is a bad idea. Mojave (like High Sierra and Sierra before it) is unfit 
> for server duty due to the intentional mangling of logging by Apple. Without 
> proper logs, detecting subtle problems is difficult and troubleshooting any 
> blatant problem like this is impossible.

Apple's logging is not mangled, it is simply using a different logging method. 
All the information is there, it's just harder (well, harder for me) to get to. 
However, you can easily do some pretty complex queries against it (as I 
understand it).

But I thought we were talking about Apple Mail.app *sending* mail?

> You can get something like a proper mail log by running this command 
> persistently (i.e. using launchd or batch or whatever else works...)
> 
>   log stream --info --predicate 'senderImagePath CONTAINS "postfix"' --style 
> syslog >> /var/log/mail.log
> 
> That will give you useful information in a standard-ish format in 
> /var/log/mail.log.
> 
> Without such logging, it is infeasible to troubleshoot your problem.

Well, it is feasible because you can query the logs anytime you want (using 
collect will even generate a log file for your query across the whole logging 
system without having to go searching trough many files). That said, I don't 
use my Macs as servers. postfix runs on FreeBSD. Apache runs on FreeBSD. MySQL 
runs on FreeBSD. Etc.

# log show --info  --start "2018-12-06 16:00:00" --end "2018-12-06 16:45:00" 
--predicate 'senderImagePath CONTAINS "sshd" AND messageType=info' --style 
syslog
Filtering the log data using "senderImagePath CONTAINS "sshd" AND logType == 1"
Timestamp   (process)[PID]
2018-12-06 16:17:28.311749-0700  localhost sshd[1649]: Connection closed by 
130.162.96.208 port 18696 [preauth]
2018-12-06 16:20:14.692208-0700  localhost sshd[1822]: Did not receive 
identification string from 63.143.42.244 port 10643
2018-12-06 16:25:14.528760-0700  localhost sshd[2100]: Did not receive 
identification string from 63.143.42.244 port 17916
2018-12-06 16:30:14.586075-0700  localhost sshd[2378]: Did not receive 
identification string from 63.143.42.244 port 33134



-- 
A bartender is just a pharmacist with a limited inventory.

Re: New install - Temporary lookup failures when trying to send

[@lbutlr]

> On 6 Dec 2018, at 02:00, Matus UHLAR - fantomas  wrote:
> 
>> On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas
>> said:
>>> pleaase, get a decent MUA, not applemail that tries to encode everything as
>>> internet links (and messes up thge plaintext version of mail).
> 
> On 04.12.18 13:47, @lbutlr wrote:
>> What do you base this statement on?  I’ve been using Apple’s Meal.app since
>> around 2003 or so, and I’ve never had it encode everything as Internet
>> links more mess up plaintext mail.
> 
> based on sender's 
> X-Mailer: Apple Mail (2.3445.102.3)
> 
> and the result I have quoted that is also visible on:
> 
> https://marc.info/?l=postfix-users&m=154380074926895&w=2
> 
> the HTML parts may be encoded properly, but the plaintext version of sent
> mail contains useless crap where
> 
> 
> 
> is converted to:
> 
> mailto:jlbr...@bordo.com.au>>
> 
> and:
> 
> mail.bordo.com.au
> 
> is converted to:
> 
> mail.bordo.com.au 

But I have never seen Mail.app (neither my own nor someone else's) do that.

It is far more likely that the problem lies in something the poster has done 
than in a program used by about a billion people across macOS and iOS.

-- 
THERE WAS NO ROMAN GOD NAMED "FARTICUS" Bart chalkboard Ep. 5F06

Re: New install - Temporary lookup failures when trying to send

[James Brown]

> On 7 Dec 2018, at 1:23 am, Matus UHLAR - fantomas  wrote:
> 
> Anyway, sorry for the noise.
> 
> however, my questions weren't responded and still apply:
> 
> Are those cf files properly configured? Can postfix connect to the 
> database?
> What's in the logs?
> 
> and also the comment:
> 
>> Not sure where I’ve gone wrong. Copied most config details across from 
>> my working (older) mail server.
> often not a good idea, your postfix config file has too many options 
> where I
> believe many could be left default.


Wow, sorry to have caused such a kerfuffle with the email links!

I’m sending this one as Plain Text just to be sure. :-)

Yes, I’m using ASSP as an anti-spam mail proxy - 
https://sourceforge.net/projects/assp/

Anyway, I eventually got it working. I think the problem was that I did not 
have:

mysql_virtual_alias_maps.cf and
mysql_virtual_domains_maps.cf

In /usr/local/etc/postfix/ - once I put them it I think it worked. It’s all 
good now.

Thanks again everyone for your help.

James.