Hello.
I haven't tried it yet, but DKIM with ed25519 is draft:
https://tools.ietf.org/id/draft-ietf-dcrup-dkim-crypto-11.html
and official RFC doesn't mention it: https://tools.ietf.org/html/rfc6376
Doesn't it mean that ed25519 support is optional and many MTAs over the
Internet simply wouldn't b
Hi...
flushing the queue with 'postqueue -f'' normally produces instant flush but
sometimes it takes some time to do it... it always works! but sometimes with a
long delay...
just out of curiosity... why does this happen? is it qmgr daemon waiting for
anything? is there any way for force it?
T
I i've a problem, i have a list of IP in mynetworks file
I notice that postfix treats the ip address differently in the following
two cases
010.001.001.011
from
10.1.1.11
In mynetworks i have 010.001.001.011 and when external server connect to
my smtp the ip format is 10.1.1.11.
So exter
Le 26/10/2020 à 11:11, Matteo Cazzador a écrit :
I i've a problem, i have a list of IP in mynetworks file
I notice that postfix treats the ip address differently in the following
two cases
010.001.001.011
from
10.1.1.11
In mynetworks i have 010.001.001.011 and when external server connect
hey,
looking at http://www.postfix.org/cidr_table.5.html:
ADDRESS PATTERN SYNTAX
[...]
An IPv4 network address is a sequence of four decimal octets
separated
by ".", [...]
numbers beginning with 0 are probably interpreted as octal octets, not as
decimal octets.
on anoth
Hi, thank's my problem is that i populate mynetworks file getting data
from a database.
In the DB tables i 've that format "000.000.000.000".
But i can change my backend script, I thought there was a faster resolution.
No problem
Il 26/10/2020 12:03, Michael ha scritto:
Attenzione: Questa e`
* PGNet Dev :
> i'm swapping out opendkim milter from a postfix setup.
>
> inbound verification's been replaced with fastmail's authentication_milter --
> in smtpd mode
> so far, behaving well.
>
> outbound signing on postfix sumbission has been replaced with dkimpy-milter.
> seems to work nicel
On 10/26/20 4:19 AM, Patrick Ben Koetter wrote:
There's only *one* SigningTable, but there are two KeyTables – one for rsa and
the other one for ed25519. Maybe you are using an older version of
dkimpy-milter. IIRC it had a related error in the man page.
oops, typo.
yep, I've one ST & 2 KTs, on
* PGNet Dev :
> On 10/26/20 4:19 AM, Patrick Ben Koetter wrote:
> > There's only *one* SigningTable, but there are two KeyTables – one for rsa
> > and
> > the other one for ed25519. Maybe you are using an older version of
> > dkimpy-milter. IIRC it had a related error in the man page.
>
> oops, t
Viktor Dukhovni:
> > On Oct 25, 2020, at 9:08 PM, Wietse Venema wrote:
> >
> > What about making the '#' a suffix instead? That is still unlikely
> > to clash with existing user naming schemes. BTW I realize that there
> > is no unit test for numerical UIDs; that needs to be fixed, too.
>
> A su
Demi M. Obenour:
> Nit: Given the quoted localpart TODO, it might be a good idea to
> suggest limiting the character set that will be matched. On a system
> I ran, I would use:
>
> /etc/postfix/login_senders:
> # Allow both the bare username and user@domain forms.
> /([A-Za-z][A-Za-z0-9_-
On 10/26/20 8:41 AM, Patrick Ben Koetter wrote:
using latest available via pip, v1.2.2. can try master branch.
That will suffice.
fwiw, no diff -- same problem -- with 1.2.2 or master
I haven't had any problems either on Debian, Ubuntu or ARCH Linux using
dknewkey.
tho i doubt it matters
Pedro David Marco:
> Hi...
> flushing the queue with 'postqueue -f'' normally produces instant flush but
> sometimes it takes some time to do it... it always works! but sometimes with
> a long delay...
> just out of curiosity... why does this happen? is it qmgr daemon waiting for
> anything? is
You might want to take a look at what is in the queue.
Flushing the queue means communicating with other mail servers and the
reason that mail is in the queue is that it was "too hard" to deliver it
the first time.
A broken or overloaded remote could still be slow.
Ron
On 2020-10-26 6:07 a.m
On 10/26/20 8:52 AM, PGNet Dev wrote:
headed for @launchpad.
for anyone interested,
https://bugs.launchpad.net/dkimpy-milter/+bug/1901569
thx! @ here
>On Monday, October 26, 2020, 05:09:41 PM GMT+1, Ron Wheeler
wrote:
>You might want to take a look at what is in the queue.
>Flushing the queue means communicating with other mail servers and the reason
>that mail is in the queue is that it was "too hard" to deliver it the first
>tim
Could be just that the other end was busy receiving someone else's mail.
Takes 2 to tango!
No big attachments?
On 2020-10-26 12:22 p.m., Pedro David Marco wrote:
>On Monday, October 26, 2020, 05:09:41 PM GMT+1, Ron Wheeler
wrote:
>You might want to take a look at what is in the queue.
>F
>On Monday, October 26, 2020, 05:31:05 PM GMT+1, Ron Wheeler
wrote: >
>Could be just that the other end was busy receiving someone else's mail.
Takes 2 to tango!
>No big attachments?
Thanks Ron... size no bigger than 500KB... if remote is busy... in the log at
least i should see
Hi
Probably bug in debian 10 ...
"warning: symlink leaves directory: /etc/postfix/./makedefs.out"
ii postfix 3.4.14-0+deb10u1 amd64 High-performance mail
transport agent
Maybe another repo ? I don't want to install from source ... eh
I search in google and probably bug in
--
It is just a warning, you can live with it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926331
On Mon, Oct 26, 2020 at 7:59 PM natan wrote:
> Hi
> Probably bug in debian 10 ...
> "warning: symlink leaves directory: /etc/postfix/./makedefs.out"
>
> ii postfix3.4.14-0+deb10u1 amd64
I think that you should only see the attempt as a successful send. Are
you logging successful sends?
I would not expect any error as long as the delay is not so long that
Postfix decides that it is never going to go.
As long as the attempt succeeds within the timeout delay, Postfix
considers i
At 26 October, 2020 Ron Wheeler wrote:
> If you are very old, you will remember when networking was young and e-mail
> was sent over dial-up connections that connected only once or twice a day.
> The email system has to deal with the historical world where connections
> where not "always on" so a
I came through the ARPAnet-DECnet and 2780/3780 stream.
On 2020-10-26 1:49 p.m., Peter Blair wrote:
At 26 October, 2020 Ron Wheeler wrote:
If you are very old, you will remember when networking was young and e-mail
was sent over dial-up connections that connected only once or twice a day.
Th
> On Oct 26, 2020, at 1:43 PM, Wietse Venema wrote:
>
>> A suffix looks like a good solution to me.
>
> On second consideration, I think I'll go for "uid:".
Yes, indeed ":" is the natural suffix, or prefix. But, when
used as a suffix, postmap issues a warnings about needing
to run it as postal
On 10/26/2020 12:46 PM, Ron Wheeler wrote:
I am not sure of the following:
- how many time Postfix retries before putting something in the queue?
- how often Postfix goes through the queue retrying old failed sends?
- what make Postfix give up retrying automatically?
Documentation:
http:/
On Mon, Oct 26, 2020 at 10:07:25AM +, Pedro David Marco wrote:
> Flushing the queue with 'postqueue -f' normally produces instant
> flush but sometimes it takes some time to do it... it always works!
It never produces "instant flush", what it does is reset the queue
manager's delay timer for
Viktor Dukhovni:
> > On Oct 26, 2020, at 1:43 PM, Wietse Venema wrote:
> >
> >> A suffix looks like a good solution to me.
> >
> > On second consideration, I think I'll go for "uid:".
As in uid:123345.
Wietsse
On 26 Oct 2020, at 6:07, Pedro David Marco wrote:
Hi...
flushing the queue with 'postqueue -f'' normally produces instant
flush but sometimes it takes some time to do it... it always works!
but sometimes with a long delay...
Can you be more specific about "long"?
--
Bill Cole
b...@scconsul
Hello All,
Trying to make sure I'm doing this correctly, both at the right point
within the mail communications and in the format of my has file.
smtpd_recipient_restrictions=
check_sender_access hash:name of file
And within that file have both white & blacklist like so:
youareok.com OK
you
Bill Cole:
> On 26 Oct 2020, at 6:07, Pedro David Marco wrote:
>
> > Hi...
> > flushing the queue with 'postqueue -f'' normally produces instant
> > flush but sometimes it takes some time to do it... it always works!
> > but sometimes with a long delay...
>
> Can you be more specific about "lon
You got me!!! I have only been running corporate e-mail on Postfix for a
couple of decades and still learning the basics.
It does not require a lot of expertise until something goes wrong!
I knew that you or Wietse or one of the other experts would correct my
guesses.
You guys give great supp
31 matches
Mail list logo
