Re: postqueue -f delayed
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 support on a product that is very complex but does damn near everything possible with mail. Ron On 2020-10-26 2:59 p.m., Viktor Dukhovni wrote: 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 the next deferred queue scan, so that if no deferred queue scan is currently in progress, it starts now, or if already in progress, the next scan will start as soon as the current one completes. Furthermore, instead of retrying just the messages whose retry time is in the past, for the next scan (and any remaining portion of the current scan) all messages will be retried. 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? As Wietse noted, without more information about what's in the queue at the time, etc. it is hard to say. One would expective to see "qmgr" log messages showing mail entering the active queue, e.g.: Oct 26 14:43:56 amnesiac postfix/qmgr[97795]: E0BFA3BC92C: from=, size=11617, nrcpt=1 (queue active) but perhaps your logging subsystem is losing messages. On Mon, Oct 26, 2020 at 04:22:21PM +, 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. 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 is not well informed on this topic, and is just guessing. Just a real example: 100 emails in deferred queue due to connection timed out (remote host was down for a while). Once the remote is up again, i run postqueue -f for quickdelivery...Sometimes it works immediatelly, and sometimes there is a delay... (with no postfix log activity at all) Your logging subsystem may be losing messages, are you seeing logging from the queue manager at all? With "postqueue -f", and deferred messages in the queue, you should be seeing "qmgr" log messages about new mail entering the queue, which would show up promptly, unless you're using a particularly sluggish transport table (slow LDAP, overloaded MySQL, ...). On Mon, Oct 26, 2020 at 04:44:11PM +, Pedro David Marco wrote: >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 the postfix attempt, am i right? but there is nothing at all in the log... Message content size does not matter in this context. Queue manager latency depends on the number of recipients in a message (up to a limit on the number brought into memory at once) not the message size. With a sufficiency low-latency transport table (none or indexed files) the queue manager activates messages "in real time". -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
Re: postqueue -f delayed
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 "long"? And what Postfix activity you consider "delayed". As other people have noted, you won't see "activity" when all delivery agents are already "busy" connecting to unreachable destinations. That is exactly what happens when you keep hitting Postfix with "postfix flush" commands. Wietse
Fwd: Verify Proper method for sender restrictions
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 youarebad.com REJCT 1.2.3.4 550 Block-I dont like you 1.5.6.0/24 550 Block I dont like any of you. -- Thanks! Joey
Re: postqueue -f delayed
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...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Accessing the sending user from a canonical(5) table
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
Re: postqueue -f delayed
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 the next deferred queue scan, so that if no deferred queue scan is currently in progress, it starts now, or if already in progress, the next scan will start as soon as the current one completes. Furthermore, instead of retrying just the messages whose retry time is in the past, for the next scan (and any remaining portion of the current scan) all messages will be retried. > 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? As Wietse noted, without more information about what's in the queue at the time, etc. it is hard to say. One would expective to see "qmgr" log messages showing mail entering the active queue, e.g.: Oct 26 14:43:56 amnesiac postfix/qmgr[97795]: E0BFA3BC92C: from=, size=11617, nrcpt=1 (queue active) but perhaps your logging subsystem is losing messages. On Mon, Oct 26, 2020 at 04:22:21PM +, 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. > > >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 is not well informed on this topic, and is just guessing. > Just a real example: 100 emails in deferred queue due to connection > timed out (remote host was down for a while). Once the remote is up > again, i run postqueue -f for quickdelivery...Sometimes it works > immediatelly, and sometimes there is a delay... (with no postfix log > activity at all) Your logging subsystem may be losing messages, are you seeing logging from the queue manager at all? With "postqueue -f", and deferred messages in the queue, you should be seeing "qmgr" log messages about new mail entering the queue, which would show up promptly, unless you're using a particularly sluggish transport table (slow LDAP, overloaded MySQL, ...). On Mon, Oct 26, 2020 at 04:44:11PM +, Pedro David Marco wrote: > >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 the postfix attempt, am i right? but > there is nothing at all in the log... Message content size does not matter in this context. Queue manager latency depends on the number of recipients in a message (up to a limit on the number brought into memory at once) not the message size. With a sufficiency low-latency transport table (none or indexed files) the queue manager activates messages "in real time". -- Viktor.
Re: postqueue -f delayed
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://www.postfix.org/QSHAPE_README.html http://www.postfix.org/TUNING_README.html The default values for all the queue controls are carefully chosen, and don't need to be changed except for unusual circumstances, such as a bulk mail server or a server that only has intermittent connection to the internet. If you feel the need to twiddle the knobs, start with small changes and test the effect. As a general rule, don't flush the queue; let postfix deal with deferred mail on its own. Frequent flushes can reduce performance. In your case, a modest change to maximal_backoff_time may help delivery to destinations that are sometimes offline. Make a small change and test. Note that reducing the backoff can delay new mail if there is a lot of deferred mail not yet deliverable. Don't flush the queue. -- Noel Jones
Re: Accessing the sending user from a canonical(5) table
> 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 postalias on files that look like aliases(5) files: $ cat /tmp/xyzzy 12345: a...@example.com $ postmap btree:/tmp/xyzzy postmap: warning: /tmp/xyzzy, line 1: record is in "key: value" format; is this an alias file? And does not complain when the key is ":12345", so the prefix form is likely better... -- Viktor.
Re: postqueue -f delayed
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. The email system has to deal with the historical world where connections where not "always on" so a successful send does not imply anything about time. All of the good tech started with "uu": uucp, uuencode, uunet :P -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
Re: postqueue -f delayed
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 successful send does not imply anything about > time. All of the good tech started with "uu": uucp, uuencode, uunet :P
Re: postqueue -f delayed
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 it a success, does not complain and moves on to the next one. 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? If I were in your situation, I would be looking to see if there is anything that could be done to make Postfix deal with the root problem of stuff getting caught in the queue and not being delivered after the remote system resumes normal operation. Having to do a manual flush is what makes the delay visible. If it went on its own, you would never know of the occasional delay. 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 successful send does not imply anything about time. Ron On 2020-10-26 12:44 p.m., Pedro David Marco wrote: >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 the postfix attempt, am i right? but there is nothing at all in the log... Pete. -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
Re: bug in debian10
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 amd64High-performance mail > transport agent > > Maybe another repo ? I don't want to install from source ... eh > > I search in google and probably bug in > -- > >
bug in debian10
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 --
Re: postqueue -f delayed
>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 the postfix attempt, am i right? but there is nothing at all in the log... Pete.
Re: postqueue -f delayed
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. >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 Thanks Ron, Just a real example: 100 emails in deferred queue due to connection timed out (remote host was down for a while). Once the remote is up again, i run postqueue -f for quick delivery... Sometimes it works inmediatelly, and sometimes there is a delay... (with no postfix log activity at all) Thanks Wietse.. please, what extra data may be needed? is the previous example enough? Thanks! Pete. -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
Re: postqueue -f delayed
>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 >time. >A broken or overloaded remote could still be slow. >Ron Thanks Ron, Just a real example: 100 emails in deferred queue due to connection timed out (remote host was down for a while). Once the remote is up again, i run postqueue -f for quickdelivery...Sometimes it works inmediatelly, and sometimes there is a delay... (with no postfix log activity at all) Thanks Wietse.. please, what extra data may be needed? is the previous example enough? Thanks! Pete.
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
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
Re: postqueue -f delayed
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., 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... just out of curiosity... why does this happen? is it qmgr daemon waiting for anything? is there any way for force it? Thanks... Pete. -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
Re: postqueue -f delayed
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 there any way for force it? > Insufficient data.
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
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, i'm atm on Fedora32 i've compared both dknewkey & openssl methods. so far, i can't see any obvious difference in generated content. results are the same in either case; rsa works, ed2519 fails I wouldn't know either. Maybe you should reach out to the developer. yep. headed for @launchpad. On a sidenote: If you want to use ansible, you might want to try this: https://github.com/sys4/dkimpy-role thx. already found it ... and used it for comparison. unless i'm missing details -- and pebkac's certainly possible! -- it _should_ be identical to my setup.
Re: Accessing the sending user from a canonical(5) table
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_-]*)$/iAE$1, $1...@example.com > > but the regex will of course be system-dependent. I say "might" > because one could reasonably argue that if a user is allowed to login > with a username containing a comma or space, something has already > gone wrong. That requires that Postfix security or system secuity are compromised: the user can manipulate the setgid postdrop process, or they modified the system library, or they modified the passsword file. Postfix does not have to defend against broken security assumptions or against a hostile super-user. Wietse
Re: Accessing the sending user from a canonical(5) table
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 suffix looks like a good solution to me. On second consideration, I think I'll go for "uid:". Wietse
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
* 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, typo. > > yep, I've one ST & 2 KTs, one each for rsa & ed25519 > > using latest available via pip, v1.2.2. can try master branch. That will suffice. > > Yes. I use it on mailop.org. > > thx! > ok. so it's local ... > > > how are you generating your ed25519 data? > > for rsa, here, _either_ 'dknewkey' or 'openssl genrsa (etc)' works fine. > > for the ed25519, i get different fails -- in error logs -- with 'dknewkey' or > 'openssl genpkey (etc)'. > > atm, with 'dknewkey' generated data, on attempted ed25519 signing I'm seeing: > "sign_dkim: The seed must be exactly 32 bytes long" I haven't had any problems either on Debian, Ubuntu or ARCH Linux using dknewkey. > i know README says "in order to generate Ed25519 keys for dkimpy-milter, > dkimpy specific tools > must be used to be compatible > " I wouldn't know either. Maybe you should reach out to the developer. On a sidenote: If you want to use ansible, you might want to try this: https://github.com/sys4/dkimpy-role p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
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, one each for rsa & ed25519 using latest available via pip, v1.2.2. can try master branch. Yes. I use it on mailop.org. thx! ok. so it's local ... how are you generating your ed25519 data? for rsa, here, _either_ 'dknewkey' or 'openssl genrsa (etc)' works fine. for the ed25519, i get different fails -- in error logs -- with 'dknewkey' or 'openssl genpkey (etc)'. atm, with 'dknewkey' generated data, on attempted ed25519 signing I'm seeing: "sign_dkim: The seed must be exactly 32 bytes long" i know README says "in order to generate Ed25519 keys for dkimpy-milter, dkimpy specific tools must be used to be compatible " tho, i don't yet know _what_ the differences actually are ...
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
* 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 nicely for rsa signing. > > support's supposedly _there_ for ed25519 signing. > but, when I deploy -- simply enabling ed25519 signingtable -- I get lots of > errors -- just starting to troubleshoot now. 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. > 1st question ... > > ... is outbound ed25519 signing with dkimpy-milter in Postfix known-to-work > for anyone here? Yes. I use it on mailop.org. > iiuc, there's no Postfix-reason that it shouldn't work; a milter's a milter. > > so, just looking for any evidence that someone's got it working at all b4 > diving in. It's worth it. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Relay access by IP
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` la prima volta che ricevi un'email da questo mittente. Attenzione: Assicurati che sia qualcuno di cui ti fidi. hey, looking at https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.postfix.org%2Fcidr_table.5.html%3A=d9b44b61=108b0d46=y=y 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 another note: why not restrict client access with 'smtpd_client_restrictions'? i have something like: smtpd_client_restrictions = [...], check_client_access hash:/etc/postfix/client_access, [...] and /etc/postfix/client_access looks like: 1.2.3.4 OK 3.4.5.6 OK but maybe this solves another problem you don't have... greetings... -- Messaggio analizzato da Libraesva ESG. Seguire il link qui sotto per segnalarlo come spam: http://mailgateway-3.netlite.it/cgi-bin/learn-msg.cgi?id=3CEFB61282.A7757 Seguire il link qui sotto per mettere in blacklist il mittente: http://mailgateway-3.netlite.it/cgi-bin/learn-msg.cgi?blacklist=1=3CEFB61282.A7757 -- Rispetta l'ambiente: se non ti è necessario, non stampare questa mail. Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento. ** Ing. Matteo Cazzador NetLite snc di Cazzador Gagliardi Corso Vittorio Emanuele II, 188 37069 Villafranca di Verona VR Tel 0454856656 Fax 0454856655 Email: mat...@netlite.it Web: http://www.netlite.it **
Re: Relay access by IP
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 another note: why not restrict client access with 'smtpd_client_restrictions'? i have something like: smtpd_client_restrictions = [...], check_client_access hash:/etc/postfix/client_access, [...] and /etc/postfix/client_access looks like: 1.2.3.4 OK 3.4.5.6 OK but maybe this solves another problem you don't have... greetings...
Re: Relay access by IP
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 to my smtp the ip format is 10.1.1.11. So external servere obtain "relay access denied". I use this configuration in main.cf "mynetworks = $config_directory/mynetworks" where mynetworks is a file that contains a list of IP. Is it possible to normalize o similar strategy? Thanks Numbers begining with 0 are often interpred in octal the 010 is 8. It might be the case, why not yuse 10.1.1.11 in your mynetworks ?
Relay access by IP
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 external servere obtain "relay access denied". I use this configuration in main.cf "mynetworks = $config_directory/mynetworks" where mynetworks is a file that contains a list of IP. Is it possible to normalize o similar strategy? Thanks -- Rispetta l'ambiente: se non ti è necessario, non stampare questa mail. Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento. ** Ing. Matteo Cazzador NetLite snc di Cazzador Gagliardi Corso Vittorio Emanuele II, 188 37069 Villafranca di Verona VR Tel 0454856656 Fax 0454856655 Email: mat...@netlite.it Web: http://www.netlite.it **
postqueue -f delayed
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? Thanks... Pete.
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
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 be able to validate it? In other words, isn't it too early? On Mon, Oct 26, 2020 at 5:04 AM PGNet Dev wrote: > 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 nicely for rsa signing. > > support's supposedly _there_ for ed25519 signing. > but, when I deploy -- simply enabling ed25519 signingtable -- I get lots > of errors -- just starting to troubleshoot now. > > 1st question ... > > ... is outbound ed25519 signing with dkimpy-milter in Postfix > known-to-work for anyone here? > > iiuc, there's no Postfix-reason that it shouldn't work; a milter's a > milter. > > so, just looking for any evidence that someone's got it working at all b4 > diving in. > >
