Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 20 Jan 2023 21:30:22 +0100
Sven Joachim  wrote:

> Wow.  Looking into the BTS, I found bug #895089[1], changed "c_rehash"
> to "openssl rehash" in /usr/lib/postfix/configure-instance.sh as
> recommended there, and now "systemctl restart postfix.service"
> completes in two seconds!

A similar major improvement for me.

root@white:~# time systemctl restart postfix.service

real0m18.389s
user0m0.081s
sys 0m0.059s
root@white:~# 

vs.

root@white:~# time systemctl restart postfix.service

real4m10.833s
user0m0.081s
sys 0m0.062s
root@white:~# 

Thank you, Sven, for pursuing this.

The patch has been committed, and should be in the pipeline.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Max Nikulin]

On 21/01/2023 01:55, Charles Curley wrote:


root@white:~# ps aux | grep -i openssl
root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
--colour=auto -i openssl
root  4587  150  2.1     4720 ?R11:48   0:00 
/usr/bin/openssl x509 -subject_hash_old -fingerprint -noout -in 
QuoVadis_Root_CA_2.pem

...> I have no idea what that's about. Maybe someone with SSL experience can

chime in here?


Delays related to cryptography may be caused by lack of entropy. You may 
try to check


cat /proc/sys/kernel/random/entropy_avail

and

ls -l /proc//fs

when such delay happens. Some network activity may increase entropy 
enough to unblock reading random bytes. If my guess is correct then the 
issue may be alleviated by installing the haveged package. VMs are 
affected more than hosts.

Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 20 Jan 2023 21:30:22 +0100
Sven Joachim  wrote:

> Wow.  Looking into the BTS, I found bug #895089[1], changed "c_rehash"
> to "openssl rehash" in /usr/lib/postfix/configure-instance.sh as
> recommended there, and now "systemctl restart postfix.service"
> completes in two seconds!
> 
> Will follow up on the bug ASAP, if nobody beats me to it.

Fix and everything. Nice! Good work, thank you.

I'll apply the fix later and see what it does on my sclerotic anemic
686 box.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 21:11 +0100, Sven Joachim wrote:

> On 2023-01-20 20:45 +0100, Sven Joachim wrote:
>
>> My hunch is that postfix recomputes all the hashes in
>> /var/spool/postfix/etc/ssl/certs, rather than copying the files from the
>> host system into the chroot which would be a lot faster.
>
> For those who want to dig deeper, /usr/lib/postfix/configure-instance.sh
> is the (Debian-specific) script which sets up the chroot.  Surely it
> should not recompute all the hashes every time postfix is restarted, but
> apparently it does so at least on Charles' and my system.

Wow.  Looking into the BTS, I found bug #895089[1], changed "c_rehash"
to "openssl rehash" in /usr/lib/postfix/configure-instance.sh as
recommended there, and now "systemctl restart postfix.service" completes
in two seconds!

Will follow up on the bug ASAP, if nobody beats me to it.

Cheers,
   Sven


1. https://bugs.debian.org/895089

Re: Postfix fails after upgrade from bullseye to bookworm

[Christoph Brinkhaus]

Am Fri, Jan 20, 2023 at 08:28:10PM +0100 schrieb Sven Joachim:
> On 2023-01-20 13:39 -0500, Greg Wooledge wrote:
> 
> > On Fri, Jan 20, 2023 at 07:17:37PM +0100, Sven Joachim wrote:

Hello Community,

> >> It seems that postfix's startup time has greatly regressed, on my laptop
> >> there are very long delays both at boot:
> >>
> >> ,
> >> | $ systemd-analyze blame | head -n1
> >> | 33.340s postfix@-.service
> >> `
> >
> > A delay that's a multiple of 30 seconds is very often a DNS lookup
> > failure.  I would imagine your postfix configuration is trying to
> > perform a DNS lookup on some hostname or other, and that this is
> > happening before you're actually "online", for whatever definition of
> > "online" is relevant here.
> 
> That should be NetworkManager-wait-online.service.  In the logs I see
> that systemd starts the postfix service directly after reaching
> network-online.target, as it is supposed to do.  The mystery is why it
> takes another 30+ seconds before any messages from postfix itself appear
> in the logs.
> 
> > That's a total guess, though.  Find your logfiles and read them to see
> > what's actually going on.
> 
> Here is what I see in the journal when I restart postfix.service:
> 
> ,
> | Jan 20 20:16:06 myhost postfix/postfix-script[1470]: stopping the Postfix 
> mail system
> | Jan 20 20:16:06 myhost postfix/master[1307]: terminating on signal 15
> | Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Deactivated 
> successfully.
> | Jan 20 20:16:06 myhost systemd[1]: Stopped Postfix Mail Transport Agent 
> (instance -).
> | Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Consumed 36.372s CPU 
> time.
> | Jan 20 20:16:06 myhost systemd[1]: Starting Postfix Mail Transport Agent 
> (instance -)...
> | Jan 20 20:16:41 myhost postfix[1800]: Postfix is using backwards-compatible 
> default settings
> | Jan 20 20:16:41 myhost postfix[1800]: See 
> http://www.postfix.org/COMPATIBILITY_README.html for details
> | Jan 20 20:16:41 myhost postfix[1800]: To disable backwards compatibility 
> use "postconf compatibility_level=3.6" and "pos\
> | tfix reload"
> | Jan 20 20:16:42 myhost postfix/postfix-script[2026]: starting the Postfix 
> mail system
> | Jan 20 20:16:42 myhost postfix/master[2028]: daemon started -- version 
> 3.7.3, configuration /etc/postfix
> | Jan 20 20:16:42 myhost systemd[1]: Started Postfix Mail Transport Agent 
> (instance -).
> | Jan 20 20:16:42 myhost systemd[1]: Starting Postfix Mail Transport Agent...
> | Jan 20 20:16:42 myhost systemd[1]: Finished Postfix Mail Transport Agent.
> `

I have observed something comparable, but with fetchmail for email 
and unbound as a dns resover. Both are started by systemd at almost
the same time. But it takes some time for unbound to fetch keys and so
on. Before unbound is really ready fetchmail has started its first
poll, but without success because the mail servers ip could not be
resolved.

I am only a hobbyist. But may be something similar is happening in the
discussed issue. May be it is worth to have a look how the dns lookup
is set up and how it is starting.

Please just ignore be if this proposal makes no sense.
At work I am no admin :-).

> I have left nothing out, so WTH is postfix waiting for in these 35
> seconds?
> 
> Cheers,
>Sven

BTW: I have resolved my issue by starting fetchmail via systemd by a
wrapper script which probes the dns resolution of the mail server
before starting fetchmail.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 20:45 +0100, Sven Joachim wrote:

> On 2023-01-20 11:55 -0700, Charles Curley wrote:
>
>> On Fri, 20 Jan 2023 19:17:37 +0100
>> Sven Joachim  wrote:
>>
>>> Clearly something fishy is going on here.
>>
>> I concur. What I saw with htop was a slew of calls to SSL. Here's
>> a sample of what it was doing. It is a processor hog.
>>
>> root@white:~# ps aux | grep -i openssl
>> root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
>> --colour=auto -i openssl
>> root 4587 150 2.1  4720 ?  R 11:48 0:00 /usr/bin/openssl x509
>> -subject_hash_old -fingerprint -noout -in QuoVadis_Root_CA_2.pem
>
> Indeed I see many calls to openssl in top, apparently they are children
> of a single c_rehash process.  CPU load is low here, though (2-3 %).
>
>> I have no idea what that's about. Maybe someone with SSL experience can
>> chime in here?
>
> My hunch is that postfix recomputes all the hashes in
> /var/spool/postfix/etc/ssl/certs, rather than copying the files from the
> host system into the chroot which would be a lot faster.

For those who want to dig deeper, /usr/lib/postfix/configure-instance.sh
is the (Debian-specific) script which sets up the chroot.  Surely it
should not recompute all the hashes every time postfix is restarted, but
apparently it does so at least on Charles' and my system.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Jeffrey Walton]

On Fri, Jan 13, 2023 at 11:37 AM Charles Curley
 wrote:
>
> I upgraded an i386 machine from bullseye to bookworm. Postfix now
> refuses to run.
>
> root@white:/var/spool# systemctl start postfix@-.service
> Job for postfix@-.service failed because a timeout was exceeded.
> See "systemctl status postfix@-.service" and "journalctl -xeu 
> postfix@-.service" for details.
> root@white:/var/spool# systemctl status postfix@-.service
> × postfix@-.service - Postfix Mail Transport Agent (instance -)
>  Loaded: loaded (/lib/systemd/system/postfix@.service; enabled-runtime; 
> preset: enabled)
>  Active: failed (Result: timeout) since Fri 2023-01-13 07:55:51 MST; 17s 
> ago
>Docs: man:postfix(1)
> Process: 5170 ExecStartPre=/usr/lib/postfix/configure-instance.sh - 
> (code=killed, signal=TERM)
> CPU: 1min 29.456s
>
> Jan 13 07:54:21 white systemd[1]: Starting Postfix Mail Transport Agent 
> (instance -)...
> Jan 13 07:55:51 white systemd[1]: postfix@-.service: start-pre operation 
> timed out. Terminating.
> Jan 13 07:55:51 white systemd[1]: postfix@-.service: Control process exited, 
> code=killed, status=15/TERM
> Jan 13 07:55:51 white systemd[1]: postfix@-.service: Failed with result 
> 'timeout'.
> Jan 13 07:55:51 white systemd[1]: Failed to start Postfix Mail Transport 
> Agent (instance -).
> Jan 13 07:55:51 white systemd[1]: postfix@-.service: Consumed 1min 29.456s 
> CPU time.
> root@white:/var/spool# postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> compatibility_level = 3.6
> inet_interfaces = all
> inet_protocols = ipv4
> mailbox_size_limit = 0
> mydestination = white.localdomain, white.localdomain, white, 
> localhost.localdomain, localhost
> myhostname = white.localdomain
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> myorigin = /etc/mailname
> readme_directory = no
> recipient_delimiter = +
> relayhost = smtp.localdomain
> smtp_tls_CApath = /etc/ssl/certs
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
> defer_unauth_destination
> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> smtpd_tls_security_level = may
> root@white:/var/spool#

You should provide the output of journalctl. That usually has the
details that are useful in diagnosing a problem.

> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/

I try to skip them. There's no point in wasting time on them.

Jeff

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 11:55 -0700, Charles Curley wrote:

> On Fri, 20 Jan 2023 19:17:37 +0100
> Sven Joachim  wrote:
>
>> Clearly something fishy is going on here.
>
> I concur. What I saw with htop was a slew of calls to SSL. Here's
> a sample of what it was doing. It is a processor hog.
>
> root@white:~# ps aux | grep -i openssl
> root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
> --colour=auto -i openssl
> root 4587 150 2.1  4720 ?  R 11:48 0:00 /usr/bin/openssl x509
> -subject_hash_old -fingerprint -noout -in QuoVadis_Root_CA_2.pem

Indeed I see many calls to openssl in top, apparently they are children
of a single c_rehash process.  CPU load is low here, though (2-3 %).

> I have no idea what that's about. Maybe someone with SSL experience can
> chime in here?

My hunch is that postfix recomputes all the hashes in
/var/spool/postfix/etc/ssl/certs, rather than copying the files from the
host system into the chroot which would be a lot faster.

It is probably time for me to revisit my postfix configuration.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 20 Jan 2023 14:28:22 -0500
Greg Wooledge  wrote:

> More multiples of 30 seconds.  I'm still thinking "DNS issue".

In this case, laziness. The default timeout is 60 seconds. I added 30
to that. Then doubled it. Etc. That doesn't mean you are wrong. I'd
like to know what that ssl command is up to.

The problem is not for lack of network. I executed all the commands I
showed in my recent emails via ssh over Ethernet, and that machine has
full access to the Internet.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Greg Wooledge]

On Fri, Jan 20, 2023 at 11:55:35AM -0700, Charles Curley wrote:
> My previous timeout vale was 180 seconds, which wasn't enough. So my
> ancient anemic box needed between 180 and 360 seconds to start postfix.
> (But see below.)

More multiples of 30 seconds.  I'm still thinking "DNS issue".

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 13:39 -0500, Greg Wooledge wrote:

> On Fri, Jan 20, 2023 at 07:17:37PM +0100, Sven Joachim wrote:
>> It seems that postfix's startup time has greatly regressed, on my laptop
>> there are very long delays both at boot:
>>
>> ,
>> | $ systemd-analyze blame | head -n1
>> | 33.340s postfix@-.service
>> `
>
> A delay that's a multiple of 30 seconds is very often a DNS lookup
> failure.  I would imagine your postfix configuration is trying to
> perform a DNS lookup on some hostname or other, and that this is
> happening before you're actually "online", for whatever definition of
> "online" is relevant here.

That should be NetworkManager-wait-online.service.  In the logs I see
that systemd starts the postfix service directly after reaching
network-online.target, as it is supposed to do.  The mystery is why it
takes another 30+ seconds before any messages from postfix itself appear
in the logs.

> That's a total guess, though.  Find your logfiles and read them to see
> what's actually going on.

Here is what I see in the journal when I restart postfix.service:

,
| Jan 20 20:16:06 myhost postfix/postfix-script[1470]: stopping the Postfix 
mail system
| Jan 20 20:16:06 myhost postfix/master[1307]: terminating on signal 15
| Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Deactivated 
successfully.
| Jan 20 20:16:06 myhost systemd[1]: Stopped Postfix Mail Transport Agent 
(instance -).
| Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Consumed 36.372s CPU 
time.
| Jan 20 20:16:06 myhost systemd[1]: Starting Postfix Mail Transport Agent 
(instance -)...
| Jan 20 20:16:41 myhost postfix[1800]: Postfix is using backwards-compatible 
default settings
| Jan 20 20:16:41 myhost postfix[1800]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
| Jan 20 20:16:41 myhost postfix[1800]: To disable backwards compatibility use 
"postconf compatibility_level=3.6" and "pos\
| tfix reload"
| Jan 20 20:16:42 myhost postfix/postfix-script[2026]: starting the Postfix 
mail system
| Jan 20 20:16:42 myhost postfix/master[2028]: daemon started -- version 3.7.3, 
configuration /etc/postfix
| Jan 20 20:16:42 myhost systemd[1]: Started Postfix Mail Transport Agent 
(instance -).
| Jan 20 20:16:42 myhost systemd[1]: Starting Postfix Mail Transport Agent...
| Jan 20 20:16:42 myhost systemd[1]: Finished Postfix Mail Transport Agent.
`

I have left nothing out, so WTH is postfix waiting for in these 35
seconds?

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 20 Jan 2023 19:17:37 +0100
Sven Joachim  wrote:

> Clearly something fishy is going on here.

I concur. What I saw with htop was a slew of calls to SSL. Here's
a sample of what it was doing. It is a processor hog.

root@white:~# ps aux | grep -i openssl
root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
--colour=auto -i openssl
root  4587  150  2.1     4720 ?R11:48   0:00 
/usr/bin/openssl x509 -subject_hash_old -fingerprint -noout -in 
QuoVadis_Root_CA_2.pem
root@white:~#

I have no idea what that's about. Maybe someone with SSL experience can
chime in here?

My previous timeout vale was 180 seconds, which wasn't enough. So my
ancient anemic box needed between 180 and 360 seconds to start postfix.
(But see below.)

To repeat your commands:

root@white:~# systemd-analyze blame | grep postfix
4min 24.559s postfix@-.service
35ms postfix.service
root@white:~# time systemctl restart postfix.service

real4m10.833s
user0m0.081s
sys 0m0.062s
root@white:~# 

Meanwhile simply running "postfix start" took much less time.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Greg Wooledge]

On Fri, Jan 20, 2023 at 07:17:37PM +0100, Sven Joachim wrote:
> It seems that postfix's startup time has greatly regressed, on my laptop
> there are very long delays both at boot:
> 
> ,
> | $ systemd-analyze blame | head -n1
> | 33.340s postfix@-.service
> `

A delay that's a multiple of 30 seconds is very often a DNS lookup
failure.  I would imagine your postfix configuration is trying to
perform a DNS lookup on some hostname or other, and that this is
happening before you're actually "online", for whatever definition of
"online" is relevant here.

That's a total guess, though.  Find your logfiles and read them to see
what's actually going on.

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 09:34 -0700, Charles Curley wrote:

> On Fri, 13 Jan 2023 11:52:29 -0700
> Charles Curley  wrote:
>
>> That suggests there's something wrong with
>> the way systemd is starting postfix. I will look into that later
>> today.
>
> Not quite "later today", but:
>
> A bit of thinking about it, and I realized that the computer in
> question is an ancient 686 with very limited RAM, physical and swap. So
> I experimented with watching the startup using htop. That got me
> thinking that maybe the start timeout was too short.
>
> I edited postfix@-.service, like so:
>
> systemctl edit postfix@-.service
>
> and added a line to the end of the [service] stanza:
>
> TimeoutSec=360

It seems that postfix's startup time has greatly regressed, on my laptop
there are very long delays both at boot:

,
| $ systemd-analyze blame | head -n1
| 33.340s postfix@-.service
`

as well when restarting postfix:

,
| $ time sudo systemctl restart postfix.service
| sudo systemctl restart postfix.service  0,06s user 0,03s system 0% cpu 38,611 
total
`

Clearly something fishy is going on here.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 13 Jan 2023 11:52:29 -0700
Charles Curley  wrote:

> That suggests there's something wrong with
> the way systemd is starting postfix. I will look into that later
> today.

Not quite "later today", but:

A bit of thinking about it, and I realized that the computer in
question is an ancient 686 with very limited RAM, physical and swap. So
I experimented with watching the startup using htop. That got me
thinking that maybe the start timeout was too short.

I edited postfix@-.service, like so:

systemctl edit postfix@-.service

and added a line to the end of the [service] stanza:

TimeoutSec=360

So:

root@white:/etc# diff systemd/system/postfix@-.service 
/lib/systemd/system/postfix@.service 
17d16
< TimeoutSec=360
20c19
< WantedBy=multi-user.target
\ No newline at end of file
---
> WantedBy=multi-user.target
root@white:/etc# 


That seems to have fixed the problem. We'll see, said the zen master.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Charles Curley]

On Fri, 13 Jan 2023 12:00:31 -0500
Dan Ritter  wrote:

> Run the postfix executable by hand as root, and look for error
> messages and  log entries in /var/log/mail.log among other locations.

Well, that was interesting. Thanks.

In mail.log I found the following from an earlier run:

2023-01-13T06:00:11.188254-07:00 white postfix/postfix-script[3068]: warning: 
/var/spool/postfix/etc/localtime and /etc/localtime differ
2023-01-13T06:00:11.303294-07:00 white postfix/postfix-script[3073]: warning: 
/var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and 
/lib/i386-linux-gnu/libnss_systemd.so.2 differ
2023-01-13T06:00:11.479941-07:00 white postfix/postfix-script[3080]: warning: 
/var/spool/postfix/lib/i386-linux-gnu/libgcc_s.so.1 and 
/lib/i386-linux-gnu/libgcc_s.so.1 differ

(I've pasted these in unwrapped, but they may get mangled in transit or
by your mail reader.)

The message isn't quite correct: the three files under /var/spool/…
were missing. I copied the originals into place.

From a run just now:

root@white:~# postfix start
postfix: Postfix is using backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf 
compatibility_level=3.6" and "postfix reload"
postfix/postfix-script: starting the Postfix mail system
root@white:~#

and ps indicates a slew of postfix jobs running, and a whole bunch of
test emails were delivered. That suggests there's something wrong with
the way systemd is starting postfix. I will look into that later today.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postfix fails after upgrade from bullseye to bookworm

[Dan Ritter]

Charles Curley wrote: 
> I upgraded an i386 machine from bullseye to bookworm. Postfix now
> refuses to run.


Run the postfix executable by hand as root, and look for error messages
and  log entries in /var/log/mail.log among other locations.

-dsr-

Re: Postfix rejeter from et to en même temps

[Daniel Caillibaud]

Le 06/09/22 à 11:44, Erwan David  a écrit :

> Le 06/09/2022 à 11:33, Wallace a écrit :
> > Du coup je voudrais bloquer ce from vers ce to 
> > spécifiquement tout en laissant passer les autres mails vers le même 
> > to et les autres mails avec le from problématique vers d'autres to.

> Il va falloir regarder du côté des policy-filter. Car le filtrage 
> interne à postfix ne travaille que sur un seul en-tête à la fois.

Plus simple, et moins risqué, un filtre sieve dans la boite du to, si c'est tel 
from alors
tel traitement (ça peut être suppression pure et simple, mais c'est risqué et 
très limite
d'un point de vu gestion des traitements si tu n'es pas le to en question, il 
vaut mieux
le mettre dans un dossier spécifique, ou le dossier spam générique)

-- 
Daniel

Il  est impossible de faire 1 000 pompes par jour... 
sauf si vous êtes un  enfant chinois dans une usine Nike.

Re: Postfix rejeter from et to en même temps

[Wallace]

Le 06/09/2022 à 11:44, Erwan David a écrit :
Il va falloir regarder du côté des policy-filter. Car le filtrage 
interne à postfix ne travaille que sur un seul en-tête à la fois.



Tu aurais des noms d'éléments externes pour s'intégrer en policy filter?

J'ai épluché pas mal de projets github je ne vois pas ce qui pourrait 
correspondre.

Re: Postfix rejeter from et to en même temps

[Erwan David]

Le 06/09/2022 à 11:33, Wallace a écrit :


Bonjour,

Sur Postfix j'arrive bien à filtrer les from et les to en fonction de 
différents critères mais je n'arrive pas à trouver comment filtrer en 
from et to en même temps.


Exemple en to j'ai une boite d'une personne valide donc je ne peux pas 
la bloquer en filtre to mais certaines adresses en from vers ce to est 
refusé pour raison d'encodage des headers et l'éditeur ne semble pas 
vouloir corriger. Du coup je voudrais bloquer ce from vers ce to 
spécifiquement tout en laissant passer les autres mails vers le même 
to et les autres mails avec le from problématique vers d'autres to.


Une idée de quelles options sont nécessaires pour cela?

Sinon je regarde aussi un filtre milter spécifique mais je n'ai pas 
trouvé grand chose de pertinent.


Merci par avance pour vos avis.

Bonne journée

Il va falloir regarder du côté des policy-filter. Car le filtrage 
interne à postfix ne travaille que sur un seul en-tête à la fois.

Re: Postfix comme MX2 d'un Sendmail

[Roberto C . Sánchez]

On Mon, Jun 20, 2022 at 05:25:39PM +0200, BERTRAND Joël wrote:
>   Je viens de couper le MX1 durant une petite demi-heure. Le MX2 récupère
> tous les mails en synchronisant les listes grises entre MX1 et 2 et
> renvoie le tout au MX1 dès qu'il réapparaît.
> 
>   Je finasserai la configuration plus tard.
> 
>   Une question résiduelle que je viens de me poser. Lorsqu'un utilisateur
> envoie un mail, il utilise le SMTP (sur le MX1) sur le port 587.
> sendmail demande une authentification. Si pas d'authentification, le
> mail est refusé. Mais sur le port 25, quel est le mécanisme qui fait
> qu'un utilisateur ne peut pas envoyer directement un mail (que ce soit
> avec Postfix ou sendmail) ?
> 
Peut-être ajouter "reject_unauth_destination" au paramètre
smtpd_recipient_restrictions ?

https://wiki.auf.org/wikiteki/Postfix/Authentification

Salut,

-Roberto

-- 
Roberto C. Sánchez

Re: Postfix comme MX2 d'un Sendmail

[BERTRAND Joël]

Je viens de couper le MX1 durant une petite demi-heure. Le MX2 récupère
tous les mails en synchronisant les listes grises entre MX1 et 2 et
renvoie le tout au MX1 dès qu'il réapparaît.

Je finasserai la configuration plus tard.

Une question résiduelle que je viens de me poser. Lorsqu'un utilisateur
envoie un mail, il utilise le SMTP (sur le MX1) sur le port 587.
sendmail demande une authentification. Si pas d'authentification, le
mail est refusé. Mais sur le port 25, quel est le mécanisme qui fait
qu'un utilisateur ne peut pas envoyer directement un mail (que ce soit
avec Postfix ou sendmail) ?

Bien cordialement,

JKB

Re: Postfix comme MX2 d'un Sendmail

[BERTRAND Joël]

Roberto C. Sánchez a écrit :
> Bonjour Joël,

Bonjour Roberto.

> On Mon, Jun 20, 2022 at 02:14:11PM +0200, BERTRAND Joël wrote:
>>
>>  Pour l'instant, j'ai écrit dans /etc/mail/main.cf la chose suivante :
>>
>> command_directory = /usr/sbin
>> daemon_directory = /usr/libexec/postfix
>> data_directory = /var/db/postfix
>> debug_peer_level = 2
>> debugger_command =
>> disable_vrfy_command = yes
>> html_directory = /usr/share/doc/html/postfix
>> inet_interfaces = all
>> inet_protocols = all
>> mail_owner = postfix
>> mailq_path = /usr/bin/mailq
>> manpage_directory = /usr/share/man
>> maximal_queue_lifetime = 10d
>> milter_default_action = accept
>> mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.1/8
>> newaliases_path = /usr/bin/newaliases
>> non_smtpd_milters = unix:/var/clamav/clamav-milter.sock
>> postscreen_access_list = permit_mynetworks
>> proxy_interfaces = 192.168.15.14
>> queue_directory = /var/spool/postfix
>> readme_directory = /usr/share/examples/postfix
>> relay_domains = $mydestination, systella.fr
>> relay_recipient_maps =
>> sample_directory = /usr/share/examples/postfix
>> sendmail_path = /usr/sbin/sendmail
>> setgid_group = maildrop
>> smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock
>> smtpd_recipient_restrictions = permit_sasl_authenticated,
>> permit_mynetworks, check_relay_domains, reject_unauth_destination
>> unknown_local_recipient_reject_code = 550
>>
> J'utilise Postfix comme primaire et comme secondaire, alors je ne sais
> rien concernant Sendmail.  Mais, ma configuration Postfix comprend les
> adresses IP des autres serveurs Postfix dans le paramètre mynetworks et
> le secondaire aussi le paramètre relayhost de cette manière:
> 
> relayhost = [mx1.example.com]
> 
> Je pense que parce que relayhost manque de ta configuration, ton Postfix
> ne sait pas qu'il doive envoyer le message au MX1 sans essayer résoudre
> l'adresse se c'est du domaine @systella.fr en ce cas.

Il y a effectivement du mieux :

Root rayleigh:[/etc/mail] > telnet  62.212.98.88 25
Trying 62.212.98.88...
Connected to 62.212.98.88.
Escape character is '^]'.
220 legendre.systella.fr ESMTP Postfix
EHLO rayleigh
250-legendre.systella.fr
250-PIPELINING
250-SIZE 1024
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:
250 2.1.0 Ok
RCPT TO:
554 5.5.4 SPF test failed

Je ne me prends plus le même coup de pied aux fesses ;-)

Dans les logs de postfix, je trouve :

Jun 20 15:32:21 legendre postfix/smtpd[16414]: warning: support for
restriction "check_relay_domains" will be removed from Postfix; use
"reject_unauth_destination" instead
Jun 20 15:32:21 legendre postfix/smtpd[16414]: warning: restriction
`reject_unauth_destination' after `check_relay_domains' is ignored
Jun 20 15:32:21 legendre milter-greylist: (unknown id): addr
213.41.150.218 flushed, removed 0 grey and autowhite (ACL 90)
Jun 20 15:32:21 legendre milter-greylist: (unknown id): addr
[213.41.150.218][213.41.150.218] from  to
 blacklisted (ACL 90)
Jun 20 15:32:21 legendre postfix/smtpd[16414]: NOQUEUE: milter-reject:
RCPT from unknown[213.41.150.218]: 554 5.5.4 SPF test failed;
from= to= proto=ESMTP
helo=

J'ai donc changé la configuration pour la suivante (avec le même
résultat final, à savoir un échec du test SPF) :

command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command =
disable_vrfy_command = yes
html_directory = /usr/share/doc/html/postfix
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 10d
milter_default_action = accept
mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = unix:/var/clamav/clamav-milter.sock
postscreen_access_list = permit_mynetworks
proxy_interfaces = 192.168.15.14
queue_directory = /var/spool/postfix
readme_directory = /usr/share/examples/postfix
relay_domains = $mydestination, systella.fr
relay_recipient_maps =
relayhost = [rayleigh.systella.fr]
sample_directory = /usr/share/examples/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination
unknown_local_recipient_reject_code = 550

(j'ai trié le fichier de conf en retirant les commentaires, ça
n'apparaît peut-être pas dans un ordre logique).

Et là, j'ai un gros doute concernant le DNS. Le champ SPFv1 est le
suivant (récupéré depuis le serveur faisant tourner PostFix) :

legendre# host -t TXT systella.fr
systella.fr descriptive text "v=spf1 a:rayleigh.systella.fr
a:newton.systella.fr a:newton-ipv6.systella.fr
ip6:2001:7a8:a8ed:253::1/64 -all"
legendre# host 213.41.150.218
218.150.41.213.in-addr.ARPA domain name pointer 

Re: Postfix comme MX2 d'un Sendmail

[Roberto C . Sánchez]

Bonjour Joël,

On Mon, Jun 20, 2022 at 02:14:11PM +0200, BERTRAND Joël wrote:
> 
>   Pour l'instant, j'ai écrit dans /etc/mail/main.cf la chose suivante :
> 
> command_directory = /usr/sbin
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/db/postfix
> debug_peer_level = 2
> debugger_command =
> disable_vrfy_command = yes
> html_directory = /usr/share/doc/html/postfix
> inet_interfaces = all
> inet_protocols = all
> mail_owner = postfix
> mailq_path = /usr/bin/mailq
> manpage_directory = /usr/share/man
> maximal_queue_lifetime = 10d
> milter_default_action = accept
> mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.1/8
> newaliases_path = /usr/bin/newaliases
> non_smtpd_milters = unix:/var/clamav/clamav-milter.sock
> postscreen_access_list = permit_mynetworks
> proxy_interfaces = 192.168.15.14
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/examples/postfix
> relay_domains = $mydestination, systella.fr
> relay_recipient_maps =
> sample_directory = /usr/share/examples/postfix
> sendmail_path = /usr/sbin/sendmail
> setgid_group = maildrop
> smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> permit_mynetworks, check_relay_domains, reject_unauth_destination
> unknown_local_recipient_reject_code = 550
> 
J'utilise Postfix comme primaire et comme secondaire, alors je ne sais
rien concernant Sendmail.  Mais, ma configuration Postfix comprend les
adresses IP des autres serveurs Postfix dans le paramètre mynetworks et
le secondaire aussi le paramètre relayhost de cette manière:

relayhost = [mx1.example.com]

Je pense que parce que relayhost manque de ta configuration, ton Postfix
ne sait pas qu'il doive envoyer le message au MX1 sans essayer résoudre
l'adresse se c'est du domaine @systella.fr en ce cas.

>   Mais à chaque fois que je tente un envoi, postfix me renvoie la chose
> suivante :
> 
> Root rayleigh:[/etc/mail] > telnet  62.212.98.88 25
> Trying 62.212.98.88...
> Connected to 62.212.98.88.
> Escape character is '^]'.
> 220 legendre.systella.fr ESMTP Postfix
> EHLO rayleigh
> 250-legendre.systella.fr
> 250-PIPELINING
> 250-SIZE 1024
> 250-ETRN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> MAIL FROM:
> 250 2.1.0 Ok
> RCPT TO:
> 451 4.3.0 : Temporary lookup failure
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
> Root rayleigh:[/etc/mail] >
> 
>   Un RCPT TO: renvoie la même erreur alors
> que ce compte existe sur le serveur en question.
> 
>   Et là, je ne comprends plus... Tous les howto que l'on trouve sur
> internet proposent d'autres solutions qui ne donnent pas de meilleurs
> résultats.
> 
>   Une idée ?
> 
Il m'intéressera savoir si c'est le même après avoir ajouté relayhost à
la configuration.

Salut,

-Roberto

-- 
Roberto C. Sánchez

[SOLVED] Re: postfix + gmail

[D. R. Evans]

And, of course, half an hour after giving up and asking for help, I discovered 
what I needed to change.


I did a "journalctl | grep smtp" and noticed that, when my machine was 
connecting to gmail, it seemed to be doing so on port 25. Aha!


So I changed my transport file explicitly to use port 587 when connecting to 
smtp.googlemail.com, reloaded everything and now it works.


(Slightly in my defence, I had briefly pondered the question of port number 
earlier this morning, but, since I hadn't seem any mention of it in my reading 
of solutions to this problem, I figured that the fact that I had enabled auth 
in the main.cf file must mean that postfix was automagically going to use port 
587 instead of port 25. Now I know better.)


  Doc

--
Web:  http://enginehousebooks.com/drevans

Re: postfix + gmail

[IL Ka]

Hello.
Do you have "relayhost" set to gmail SMTP server?
https://www.postfix.org/postconf.5.html#relayhost

Did you call postmap(1) to build password file?
http://www.postfix.org/postmap.1.html


Here are a couple of tutorials:
http://postfix.cs.utah.edu/SOHO_README.html#client_sasl_enable
https://stafwag.github.io/blog/blog/2018/03/04/postfix-smarthost-with-authentication/

The best place to ask postfix questions is postfix mail list:
https://www.postfix.org/lists.html
Postfix developers answer there.

You can try to debug and increase logging :
https://www.postfix.org/DEBUG_README.html





On Fri, Jun 3, 2022 at 10:19 PM D. R. Evans  wrote:

> I am trying to configure postfix correctly to send e-mail to a gmail.com
> account, using my gmail credentials.
>
> 1. It all works fine if I use Thunderbird, with the following
> configuration:
>server name: smtp.googlemail.com
>port:587
>Connection security: STARTTLS
>Authentication method: normal password
>username: doc.ev...@gmail.com
> and the password set to my gmail password.
>
> That, in fact, is the method that I am using to post this e-mail to the
> reflector.
>
> 2. But when I try to duplicate that with postfix, I receive the following
> error:
>
> > : host smtp.googlemail.com[142.250.138.16] said:
> 530-5.7.0
> > Authentication Required. Learn more at 530 5.7.0
> > https://support.google.com/mail/?p=WantAuthError
> > e12-20020a9d490c00b0060b6facd5e4sm4170514otf.29 - gsmtp (in
> reply to
> > MAIL FROM command)
>
> I have spent most of the morning following various Internet threads
> related to
> this error, and making many variations to my postfix configuration, but
> without success.
>
> FWIW, here are the relevant parts of my current postfix configuration, and
> it
> generates the error message quoted above (I am running debian stable):
>
> in main.cf:
>
>smtp_sasl_auth_enable = yes
>smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
>smtp_sasl_security_options =
>smtp_sasl_type = cyrus
>smtp_use_tls = yes
>smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
>
> in sasl_passwd:
>
>[smtp.googlemail.com]:587 doc.ev...@gmail.com:
>
> I did check that the password matches exactly the password in Thunderbird.
>
> So if some postfix guru could enlighten me as to what I need to change,
> I'd be
> very grateful.
>
>Doc
>
> --
> Web:  http://enginehousebooks.com/drevans
>
>

Re: Postfix: configurer l'email de root [RESOLU]

[Olivier]

Le mar. 22 juin 2021 à 19:37, NoSpam  a écrit :

> Bonsoir
> Le 22/06/2021 à 18:21, Olivier a écrit :
>
> Merci à tous pour vos réponses.
>
> Dans /etc/aliases, j'ai:
> postmaster:  root
> root:f...@exemple.fr
> foo: f...@exemple.fr
>
> root: foo
> foo: f...@exemple.fr
>
> En appliquant dans /etc/aliases:
root: foo
foo: f...@exemple.fr

Alors:
echo Foo3 | mail -s Essai3 root   ne marche pas
echo Foo4 | mail -s Essai4 foomarche

Par contre, après modification du fichier /etc/postfix/canonical, les 2
commandes ci-dessus ont marché.

Contenu initial de /etc/postfix/canonical:
root:f...@sandbox123456.mailgun.org

Contenu modifié de /etc/postfix/canonical:
#root:f...@sandbox123456.mailgun.org

Merci infiniment à tous fpour votre aide.

Re: Postfix: configurer l'email de root

[NoSpam]

Bonsoir

Le 22/06/2021 à 18:21, Olivier a écrit :

Merci à tous pour vos réponses.

Dans /etc/aliases, j'ai:
postmaster:  root
root: f...@exemple.fr 
foo: f...@exemple.fr 


root: foo
foo: f...@exemple.fr



Ensuite:
# newaliases
# service postfix restart

# echo Test1 | mail -s Essai1 foo
# echo Test2 | mail -s Essai2 root

Le test Test1 fonctionne mais pas le test Test2.
Une piste ? Une explication ?


Le mar. 22 juin 2021 à 15:36, didier gaumet > a écrit :


Le mardi 22 juin 2021 à 15:10:03 UTC+2, Frédéric MASSOT a écrit :

> Je me permet de compléter
[...]

Merci à toi :-)

Re: Postfix: configurer l'email de root

[Frédéric MASSOT]

Le 22/06/2021 à 18:21, Olivier a écrit :

Merci à tous pour vos réponses.

Dans /etc/aliases, j'ai:
postmaster:  root
root: f...@exemple.fr 
foo: f...@exemple.fr 

Ensuite:
# newaliases
# service postfix restart


Tu n'as pas besoin de redémarrer Postfix, il détecte que le fichier a 
été modifié et le recharge.





# echo Test1 | mail -s Essai1 foo
# echo Test2 | mail -s Essai2 root

Le test Test1 fonctionne mais pas le test Test2.
Une piste ? Une explication ?


Il faut que tu regardes dans les logs : /var/log/mail.log




--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Postfix: configurer l'email de root

[Olivier]

Merci à tous pour vos réponses.

Dans /etc/aliases, j'ai:
postmaster:  root
root:f...@exemple.fr
foo: f...@exemple.fr

Ensuite:
# newaliases
# service postfix restart

# echo Test1 | mail -s Essai1 foo
# echo Test2 | mail -s Essai2 root

Le test Test1 fonctionne mais pas le test Test2.
Une piste ? Une explication ?


Le mar. 22 juin 2021 à 15:36, didier gaumet  a
écrit :

> Le mardi 22 juin 2021 à 15:10:03 UTC+2, Frédéric MASSOT a écrit :
>
> > Je me permet de compléter
> [...]
>
> Merci à toi :-)
>
>

Re: Postfix: configurer l'email de root

[didier gaumet]

Le mardi 22 juin 2021 à 15:10:03 UTC+2, Frédéric MASSOT a écrit :

> Je me permet de compléter
[...]

Merci à toi :-)

Re: Postfix: configurer l'email de root

[Frédéric MASSOT]

Le 22/06/2021 à 13:44, didier gaumet a écrit :

Bonjour,

/etc/aliases répond à ce besoin



Je me permet de compléter, après avoir édité le fichier "/etc/aliases" 
il faut utiliser la commande :


sudo newaliases

pour reconstruire la table utilisée par Postfix

--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Postfix: configurer l'email de root

[didier gaumet]

Bonjour,

/etc/aliases répond à ce besoin

Re: Postfix configuration on Bullseye

[Charles Curley]

On Tue, 20 Apr 2021 08:51:29 +0100
Darac Marjal  wrote:

> On the upside, though, this is an allowlist of domains postfix will
> accept mail for. If there are duplicates, it shouldn't REALLY make
> much difference.

Thanks for the analysis.

I don't mind the duplicates, and the spurious comma is probably
harmless. However, what this list would leave out is the hostname only,
e.g. boojum@grissom would, I am guessing, fail. Unless postfix adds the
domain to the hostname before testing it against this list.

As you say, it's a "nice to fix".

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/


pgpt89yzyiW0q.pgp
Description: OpenPGP digital signature

Re: Postfix configuration on Bullseye

[Darac Marjal]

On 20/04/2021 00:08, Charles Curley wrote:
> On installing on Bullseye, I usually install postfix, then configure it
> with "dpkg-reconfigure postfix".
>
> I use postfix here only for logwatch and other system emails, so the
> setup isn't concerned with the Internet at large.
>
> The default list of systems to accept mail for doesn't look right to me:
>
> grissom.localdomain, grissom.localdomain, localhost.localdomain, , localhost
>
> * Why is the fully qualified host name in there twice, but not the
>   hostname alone ("grissom")? (localdomain is my local TLD on a private
>   network.)
>
> * What with the two commas toward the end?
>
> Shouldn't that be
>
> grissom.localdomain, grissom, localhost.localdomain, localhost

This looks to come from the debian/postfix.config file, and is thus part
of the Debian packaging of postfix, rather than an upstream thing. In
that file, at line 228, we see: 

if ($mailertype eq "Internet Site") { if ($mailname eq $hostname) {
$destinations = join ", ",("\$myhostname", $mailname, "localhost." .
$domain, ", localhost"); } else { $destinations = join ",
",("\$myhostname", $mailname, $hostname, "localhost." . $domain . ",
localhost"); } } else { # don't accept mail for $mailname by default if
we have a relayhost or local only mail, # unless the mailname bears no
resemblance to $myorigin. $destinations = join ", ",("\$myhostname",
$hostname, "localhost." . $domain . ", localhost" ); unless ( $hostname
=~ m/(^|[\.])$mailname$/ ) { $destinations = $mailname . ", " .
$destinations; } }

[ Taken from
https://sources.debian.org/src/postfix/3.5.6-1/debian/postfix.config/#L228,
which might be easier to read if that wraps ]

This is perl, so the join() function takes a string and an array and
delimits the array with the string. So, if we take the first one as an
example, the literal string "$myhostname" is followed by a comma-space,
then the value in the "mailname" variable, then the literal string
"localhost." with the "domain" variable appended, then another
comma-space. Finally, the last element to be added to the list is ",
localhost". I don't know why this was written this way, but it means
that in every case, the "destinations" variable will end with ", ,
localhost"

Sadly, the earliest revision I can find of this file on salsa.debian.org
(https://salsa.debian.org/postfix-team/postfix-dev/-/commit/a0577ca96dda9c4e5e5bc9dd0c5b7cfc545c5804#ac03215119d5f2efaeb830653c7f84124ceed640_0_192)
already has the ", localhost" code in it, so I can't say why it was
written like that.

On the upside, though, this is an allowlist of domains postfix will
accept mail for. If there are duplicates, it shouldn't REALLY make much
difference. It's a nice to fix (just because, if you can't explain why
the code is doing something weird, you can't adequately say whether it's
a problem or not).






OpenPGP_signature
Description: OpenPGP digital signature

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[JUPIN Alain]

Bonjour,

Tout d'abord merci à vous, à force de lire des docs, je me suis un peu
mélangé les pinceaux entre les restrictions sender, domaine et helo etc.
Au final j'en suis arrivé à ceci (c'est juste un extrait, pas le main.cf
complet) :

smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client
zen.spamhaus.org, check_recipient_access
hash:/etc/postfix/protected_destinations
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_invalid_hostname, reject_non_fqdn_hostname,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
reject_unknown_helo_hostname, check_helo_access
regexp:/etc/postfix/blacklist_helo
smtpd_sender_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname, reject_unverified_sender,
reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_client_restrictions = reject_unknown_client_hostname,
reject_unknown_reverse_client_hostname

Et je parle bien des restrictions de type smtpd, pour la réception des
mails (en schématisant) et pas l'envoi (qui sont associées aux
smtp_x_restrictions) ;)

En l'état, çà l'air d'être assez efficace, à confirmer dans le temps.

Merci encore à vous.

Alain JUPIN

Le 17/11/2020 à 16:53, JUPIN Alain a écrit :
> Bonjour,
>
> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
> un nombre relativement important de messages qui viennent d'adresse IP
> "inconnues"
> Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])
>
> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
> J'ai la directive suivante dans le main.cf :
> smtpd_sender_restrictions = reject_non_fqdn_sender,
> reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks
>
> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
> autant tous les bloquer !
>
> Merci par avance
>

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Jérémy Prego]

Le 17/11/2020 à 17:21, Roger Price a écrit :
> On Tue, 17 Nov 2020, JUPIN Alain wrote:
>
>> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
>> un nombre relativement important de messages qui viennent d'adresse IP
>> "inconnues"
>> Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])
>>
>> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
>> J'ai la directive suivante dans le main.cf :
>> smtpd_sender_restrictions = reject_non_fqdn_sender,
>> reject_unknown_sender_domain, permit_sasl_authenticated,
>> permit_mynetworks
>>
>> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
>> autant tous les bloquer !
>
> Y compris ceci ?
>
> Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown
> [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])
>     (Authenticated sender: ajupin)
>     by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
>     for ; Tue, 17 Nov 2020
> 15:53:21 + (UTC)
> From: JUPIN Alain 
>
il ne faut pas tout confondre.

là, tu as collé une ip d'un client qui se connecte au smtp de free pour
envoyé le mail par ce dernier. le smtp de free lui a un reverse correct.
du coup le mail passse. ce n'est pas l'ip collé précédemment qui se
connecte directement au smtp distant. :)
> Roger

Jerem

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Roger Price]

On Tue, 17 Nov 2020, JUPIN Alain wrote:


Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
un nombre relativement important de messages qui viennent d'adresse IP
"inconnues"
Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])

On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
J'ai la directive suivante dans le main.cf :
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks

PS : La plupart de ces messages passent en SPAM mais pas tous, mais
autant tous les bloquer !


Y compris ceci ?

Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown 
[IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])

(Authenticated sender: ajupin)
by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
for ; Tue, 17 Nov 2020 15:53:21 + 
(UTC)

From: JUPIN Alain 

Roger

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Cyrille Bollu]

Apparement, il s'agit de l'option "reject_unknown_reverse_client_hostname"
que tu dois ajouter à ta liste de smtpd_sender_restriction

 

Bàt,

 

Cyrille

 

"JUPIN Alain" aju...@jupin.net – 17 novembre 2020 16:53
 

> Bonjour,
>
> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
> un nombre relativement important de messages qui viennent d'adresse IP
> "inconnues"
> Exemple : Received: from [149.27.181.246[1]] (unknown
[149.27.181.246[1]])
>
> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
> J'ai la directive suivante dans le main.cf[2] :
> smtpd_sender_restrictions = reject_non_fqdn_sender,
> reject_unknown_sender_domain, permit_sasl_authenticated,
permit_mynetworks
>
> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
> autant tous les bloquer !
>
> Merci par avance
>
>  



Links:
--
[1] http://149.27.181.246
[2] http://main.cf

Re: postfix is dead

[Pòl Hallen]

myhostname = myhost.local

  really?


I changed the name of mail server :)


1) uid of postfix user
  id postfix


119


Are there any issues in the log?
journalctl _UID=


output of journalctl _UID=199 it's normal

thanks
--
Pol

Re: postfix is dead

[Henning Follmann]

On Mon, Jul 13, 2020 at 09:12:28PM +0200, Pòl Hallen wrote:
> Hi folks :-)
> suddenly postfix is dead. Sometime after 1/2mins goes down... sometime
> doesn't start...
> 
> I already tried to reinstall with purge, delete config files, etc. but same
> problem...
> 
> help me please :)

We are here to help you help yourself.

For that we need more information.

> 
> here /etc/postfix/main.cf and above logs
> 
> compatibility_level = 2
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
> myhostname = myhost.local
     really?

> alias_maps = hash:/etc/aliases
> alias_database = hash:/etc/aliases
> mydestination = $myhostname, myhost, myhost.local, localhost.myhost.local,
> localhost
> relayhost =
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> mailbox_command = procmail -a "$EXTENSION"
> mailbox_size_limit = 0
> recipient_delimiter = +
> inet_interfaces = all
> inet_protocols = all
> 
> 
> dpkg -l| grep postfix 3.1.14-0+deb9u1
> 
> 
> Jul 13 21:07:21 asia systemd[1]: Accepted new private connection.
> Jul 13 21:07:21 asia systemd[1]: Got message type=method_call sender=n/a
> destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: postfix.service: Trying to enqueue job
> postfix.service/start/replace
> Jul 13 21:07:21 asia systemd[1]: postfix.service: Installed new job
> postfix.service/start as 85531
> Jul 13 21:07:21 asia systemd[1]: postfix.service: Enqueued job
> postfix.service/start as 85531
> Jul 13 21:07:21 asia systemd[1]: Sent message type=method_return sender=n/a
> destination=n/a object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1
> error=n/a
> Jul 13 21:07:21 asia systemd[1]: Sent message type=signal sender=n/a
> destination=n/a object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=JobNew cookie=2
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: Sent message type=signal sender=n/a
> destination=n/a object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=JobNew cookie=29554
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: Got message type=method_call sender=n/a
> destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=GetUnit cookie=2
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: Sent message type=method_return sender=n/a
> destination=n/a object=n/a interface=n/a member=n/a cookie=3 reply_cookie=2
> error=n/a
> Jul 13 21:07:21 asia systemd[1]: postfix.service: Job postfix.service/start
> finished, result=done
> Jul 13 21:07:21 asia systemd[1]: Sent message type=signal sender=n/a
> destination=n/a object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=4
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: Sent message type=signal sender=n/a
> destination=n/a object=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=29555
> reply_cookie=0 error=n/a
> Jul 13 21:07:21 asia systemd[1]: Got message type=method_call sender=n/a
> destination=org.freedesktop.systemd1
> object=/org/freedesktop/systemd1/unit/postfix_2eservice
> interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0
> error=n/a
> Jul 13 21:07:21 asia systemd[1]: Sent message type=method_return sender=n/a
> destination=n/a object=n/a interface=n/a member=n/a cookie=5 reply_cookie=3
> error=n/a
> Jul 13 21:07:21 asia systemd[1]: Got disconnect on private connection.
>

These are not helpful at all.
Please gather a few information

1) uid of postfix user
 id postfix

2) now stop and start postfix
systemctl stop postfix
systemctl start postfix

Are there any issues in the log?
journalctl _UID=

Same thing for the cases when it went down.
Do the logs show anything?



-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Postfix - Dovecot

[Frederic Robert]

On 5/18/20 7:49 AM, Frédéric MASSOT wrote:


Tu as regardé sur le wiki de Dovecot :

https://wiki.dovecot.org

et son moteur de recherche :

https://wiki.dovecot.org/FrontPage?action=fullsearch=180=postfix=Titres




Bonsoir Frédéric et à la liste,

Merci pour l'information. Oui, j'ai déjà regardé. A la base, j'utilise 
des comptes locaux et je lisais les messages avec mutt en local sur le 
serveur. Mais je voulais un système d'identification avec sasl et tls 
pour le chiffrement. Si je dis des erreurs, merci de me le dire. Comme 
dit dans le message d'origine, j'avais regardé le support d'ubuntu et 
cela semblait fonctionné mais je ne sais pas vraiment ce que j'ai fait


Très bonne soirée,

--
Frédéric ROBERT

Re: Postfix - Dovecot

[Frédéric MASSOT]

Le 17/05/2020 à 20:58, Frederic Robert a écrit :
> Bonsoir à la liste,
> 
> Comment allez-vous? Qu'avez-vous utilisé cmme tutoriel pour configurer
> votre serveur mail postfix avec dovecot avec Debian Stretch et Debian
> Buster. Il y a différents tutoriels sur internet et je ne sais pas
> lequel choisir. J'ai utilisé celui ci
> https://help.ubuntu.com/18.04/serverguide/postfix.html mais je ne sais
> pas si mon serveur est vraiment fonctionnel ou fonctionne sur une jambe
> dit-on

Tu as regardé sur le wiki de Dovecot :

https://wiki.dovecot.org

et son moteur de recherche :

https://wiki.dovecot.org/FrontPage?action=fullsearch=180=postfix=Titres


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Postfix - Dovecot

[Frederic Robert]

On 5/17/20 8:35 PM, s...@mailox.eu wrote:


L’ergonomie du site n’est en effet pas des plus claire dans un premier
temps.

Il s’agit d’un tuto global postfix/dovecot/rspamd/opendkim/fail2ban avec
les explications nécessaires pour configurer les entrées DNS, la base de
donnée, phpmyadmin, etc. On peut y piocher facilement ce qui nous
intéresse.



Merci quand même sub0 pour le site :)

--
Frédéric ROBERT

Re: Postfix - Dovecot

[Frederic Robert]

On 5/17/20 8:35 PM, s...@mailox.eu wrote:


L’ergonomie du site n’est en effet pas des plus claire dans un premier
temps.

Il s’agit d’un tuto global postfix/dovecot/rspamd/opendkim/fail2ban avec
les explications nécessaires pour configurer les entrées DNS, la base de
donnée, phpmyadmin, etc. On peut y piocher facilement ce qui nous
intéresse.



Vraiment pas facile à suivre ce site. Je regarderai un autre jour quand 
l'esprit sera plus clair :)


--
Frédéric ROBERT

Re: Postfix - Dovecot

[sub0]

Le 17/05/2020 à 20:25:38 (+), Frederic Robert a écrit :
> On 5/17/20 8:15 PM, s...@mailox.eu wrote:
> 
> > Ce tuto (en anglais) a très bien fonctionné pour moi. J’ai appris avec
> > ce tuto et mon serveur se porte bien depuis plusieurs années maintenant.
> > Il semble que le guide est tenu à jour (il y a une version stretch et
> > une version buster). Les commentaires sont également instructifs.
> > 
> > https://workaround.org/ispmail
> 
> Bonsoir,
> 
> J'ai du mal à comprendre ce tutoriel. Est-ce bien pour postfix et dovecot ?
> 
> Très bonne soirée,
> 
> -- 
> Frédéric ROBERT

L’ergonomie du site n’est en effet pas des plus claire dans un premier
temps.

Il s’agit d’un tuto global postfix/dovecot/rspamd/opendkim/fail2ban avec
les explications nécessaires pour configurer les entrées DNS, la base de
donnée, phpmyadmin, etc. On peut y piocher facilement ce qui nous
intéresse.

Re: Postfix - Dovecot

[Frederic Robert]

On 5/17/20 8:15 PM, s...@mailox.eu wrote:


Ce tuto (en anglais) a très bien fonctionné pour moi. J’ai appris avec
ce tuto et mon serveur se porte bien depuis plusieurs années maintenant.
Il semble que le guide est tenu à jour (il y a une version stretch et
une version buster). Les commentaires sont également instructifs.

https://workaround.org/ispmail


Bonsoir,

J'ai du mal à comprendre ce tutoriel. Est-ce bien pour postfix et dovecot ?

Très bonne soirée,

--
Frédéric ROBERT

Re: Postfix - Dovecot

[sub0]

Le 17/05/2020 à 18:58:51 (+), Frederic Robert a écrit :
> Bonsoir à la liste,
> 
> Comment allez-vous? Qu'avez-vous utilisé cmme tutoriel pour configurer votre
> serveur mail postfix avec dovecot avec Debian Stretch et Debian Buster. Il y
> a différents tutoriels sur internet et je ne sais pas lequel choisir. J'ai
> utilisé celui ci https://help.ubuntu.com/18.04/serverguide/postfix.html mais
> je ne sais pas si mon serveur est vraiment fonctionnel ou fonctionne sur une
> jambe dit-on
> 
> D'avance merci pour votre aide & très bonne soirée
> 
> -- 
> Frédéric ROBERT

Mes excuses Frédéric, j’ai répondu directement plutôt qu’à la liste (et
en plus je n’ai pas mis le lien !)


Ce tuto (en anglais) a très bien fonctionné pour moi. J’ai appris avec
ce tuto et mon serveur se porte bien depuis plusieurs années maintenant.
Il semble que le guide est tenu à jour (il y a une version stretch et
une version buster). Les commentaires sont également instructifs.

https://workaround.org/ispmail

Bonne soirée

Re: postfix y correo

[miguel angel gonzalez]

Hola,
Claro, he generado los que me daban pegas como google, tiene una
herramienta propia llamada Postmasters Tools.
Además, estoy mirando para generar el SPF para el resto. Dejo información
por si a alguien le viene bien:
https://geeks.ms/enterprise/2014/09/22/asegura-la-legitimidad-de-tu-email-con-los-registros-spf/
Gracias, y saludos.

El jue., 27 jun. 2019 a las 18:02, Paynalton ()
escribió:

>
> Si un ave no rompe su huevo morirá antes de nacer.
> Nosotros somos el ave y el mundo es nuestro huevo.
> POR LA REVOLUCIÓN DEL MUNDO
>
> Ciudad de México
>
>
> El jue., 27 jun. 2019 a las 10:39, miguel angel gonzalez (<
> mangelgonza...@gmail.com>) escribió:
>
>> Gracias, ya lo revisé. Parece que lo he solucionado, no es necesario
>> poner el correo de salida.
>> Simplemente diciendo a Office365 la ip del servidor ellos la quitan de la
>> lista negra.
>> Esto se hace desde:
>> https://sender.office.com
>> Por si alguien lo necesita.
>> Un saludo.
>>
>>
> Tan importante como que te retiren de las listas negras es no volver a
> entrar. busca guías de buenas práctias. cosas como declarar el servidor en
> el registro spf, colocar links para desuscribir, usar encriptación, etc.
>
> En tu caso puedes firmar los mensajes con SSL para validar la autenticidad
> de los correos.
>
>
>>
>> El jue., 27 jun. 2019 a las 14:12, Romero, Fernando (<
>> fernando.rom...@trenesargentinos.gob.ar>) escribió:
>>
>>>
>>>
>>>
>>>
>>> *De:* miguel angel gonzalez [mailto:mangelgonza...@gmail.com]
>>> *Enviado el:* jueves, 27 de junio de 2019 5:43 a. m.
>>> *Para:* Debian ayuda 
>>> *Asunto:* postfix y correo
>>>
>>>
>>>
>>> Buenas días,
>>>
>>> Hacemos envío desde nuestro aplicativo a empresas asociadas con nostros,
>>> es decir, no es spam.
>>>
>>> Es correo necesario de reporte de actividad, el caso es que postfix lo
>>> envía no da problemas,
>>>
>>> pero el cliente nos remite este correo.
>>>
>>> Parece que Office365 lo tiene baneado, el caso es que sigo los pasos que
>>> especifican en su correo
>>>
>>> para quitar de la lista de baneo nuestra dirección de correo y ellos
>>> envían un correo con un link al servidor
>>>
>>> de postfix, hay que pinchar en el enlace.
>>>
>>> ¿Dónde puedo ver el correo entrante en postfix?
>>>
>>>
>>>
>>> El mensaje:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *said: 550 5.7.606 Access denied, banned sending IP [1.XXX.XXX.XXX].
>>> To request removal from this list please visit
>>> https://sender.office.com/  and follow the
>>> directions. For more information please go to
>>> http://go.microsoft.com/fwlink/?LinkID=526655
>>>  (AS16012609) (in reply to
>>>   RCPT TO command) *
>>>
>>>
>>>
>>> Gracias a todos.
>>>
>>> --
>>>
>>> /m.a.
>>>
>>>
>>>
>>> Podes ver en el /var/log/mail.log
>>> “El contenido del presente mensaje (y sus anexos) es privado,
>>> confidencial y de exclusivo uso para el destinatario referenciado; es de
>>> público conocimiento que las comunicaciones por medio de Internet no
>>> permiten asegurar ni garantizar la confidencialidad de los mensajes
>>> transmitidos, así como tampoco su integridad o su correcta recepción; es
>>> por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de
>>> la captura, incorporaciones de virus o cualquier otra manipulación
>>> efectuada por terceros. Las opiniones expresadas en este mensaje y en los
>>> archivos adjuntos son propias del remitente y no representan la opinión o
>>> políticas de SOFSE, salvo que se diga expresamente y el remitente se
>>> encuentre autorizado para ello”
>>>
>>
>>
>> --
>> /m.a.
>>
>

-- 
/m.a.

Re: postfix y correo

[Paynalton]

Si un ave no rompe su huevo morirá antes de nacer.
Nosotros somos el ave y el mundo es nuestro huevo.
POR LA REVOLUCIÓN DEL MUNDO

Ciudad de México


El jue., 27 jun. 2019 a las 10:39, miguel angel gonzalez (<
mangelgonza...@gmail.com>) escribió:

> Gracias, ya lo revisé. Parece que lo he solucionado, no es necesario poner
> el correo de salida.
> Simplemente diciendo a Office365 la ip del servidor ellos la quitan de la
> lista negra.
> Esto se hace desde:
> https://sender.office.com
> Por si alguien lo necesita.
> Un saludo.
>
>
Tan importante como que te retiren de las listas negras es no volver a
entrar. busca guías de buenas práctias. cosas como declarar el servidor en
el registro spf, colocar links para desuscribir, usar encriptación, etc.

En tu caso puedes firmar los mensajes con SSL para validar la autenticidad
de los correos.


>
> El jue., 27 jun. 2019 a las 14:12, Romero, Fernando (<
> fernando.rom...@trenesargentinos.gob.ar>) escribió:
>
>>
>>
>>
>>
>> *De:* miguel angel gonzalez [mailto:mangelgonza...@gmail.com]
>> *Enviado el:* jueves, 27 de junio de 2019 5:43 a. m.
>> *Para:* Debian ayuda 
>> *Asunto:* postfix y correo
>>
>>
>>
>> Buenas días,
>>
>> Hacemos envío desde nuestro aplicativo a empresas asociadas con nostros,
>> es decir, no es spam.
>>
>> Es correo necesario de reporte de actividad, el caso es que postfix lo
>> envía no da problemas,
>>
>> pero el cliente nos remite este correo.
>>
>> Parece que Office365 lo tiene baneado, el caso es que sigo los pasos que
>> especifican en su correo
>>
>> para quitar de la lista de baneo nuestra dirección de correo y ellos
>> envían un correo con un link al servidor
>>
>> de postfix, hay que pinchar en el enlace.
>>
>> ¿Dónde puedo ver el correo entrante en postfix?
>>
>>
>>
>> El mensaje:
>>
>>
>>
>>
>>
>>
>>
>>
>> *said: 550 5.7.606 Access denied, banned sending IP [1.XXX.XXX.XXX].
>> To request removal from this list please visit
>> https://sender.office.com/  and follow the
>> directions. For more information please go to
>> http://go.microsoft.com/fwlink/?LinkID=526655
>>  (AS16012609) (in reply to
>>   RCPT TO command) *
>>
>>
>>
>> Gracias a todos.
>>
>> --
>>
>> /m.a.
>>
>>
>>
>> Podes ver en el /var/log/mail.log
>> “El contenido del presente mensaje (y sus anexos) es privado,
>> confidencial y de exclusivo uso para el destinatario referenciado; es de
>> público conocimiento que las comunicaciones por medio de Internet no
>> permiten asegurar ni garantizar la confidencialidad de los mensajes
>> transmitidos, así como tampoco su integridad o su correcta recepción; es
>> por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de
>> la captura, incorporaciones de virus o cualquier otra manipulación
>> efectuada por terceros. Las opiniones expresadas en este mensaje y en los
>> archivos adjuntos son propias del remitente y no representan la opinión o
>> políticas de SOFSE, salvo que se diga expresamente y el remitente se
>> encuentre autorizado para ello”
>>
>
>
> --
> /m.a.
>

Re: postfix y correo

[miguel angel gonzalez]

Gracias, ya lo revisé. Parece que lo he solucionado, no es necesario poner
el correo de salida.
Simplemente diciendo a Office365 la ip del servidor ellos la quitan de la
lista negra.
Esto se hace desde:
https://sender.office.com
Por si alguien lo necesita.
Un saludo.


El jue., 27 jun. 2019 a las 14:12, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:

>
>
>
>
> *De:* miguel angel gonzalez [mailto:mangelgonza...@gmail.com]
> *Enviado el:* jueves, 27 de junio de 2019 5:43 a. m.
> *Para:* Debian ayuda 
> *Asunto:* postfix y correo
>
>
>
> Buenas días,
>
> Hacemos envío desde nuestro aplicativo a empresas asociadas con nostros,
> es decir, no es spam.
>
> Es correo necesario de reporte de actividad, el caso es que postfix lo
> envía no da problemas,
>
> pero el cliente nos remite este correo.
>
> Parece que Office365 lo tiene baneado, el caso es que sigo los pasos que
> especifican en su correo
>
> para quitar de la lista de baneo nuestra dirección de correo y ellos
> envían un correo con un link al servidor
>
> de postfix, hay que pinchar en el enlace.
>
> ¿Dónde puedo ver el correo entrante en postfix?
>
>
>
> El mensaje:
>
>
>
>
>
>
>
>
> *said: 550 5.7.606 Access denied, banned sending IP [1.XXX.XXX.XXX].
> To request removal from this list please visit
> https://sender.office.com/  and follow the
> directions. For more information please go to
> http://go.microsoft.com/fwlink/?LinkID=526655
>  (AS16012609) (in reply to
>   RCPT TO command) *
>
>
>
> Gracias a todos.
>
> --
>
> /m.a.
>
>
>
> Podes ver en el /var/log/mail.log
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>


-- 
/m.a.

RE: postfix y correo

[Romero, Fernando]

De: miguel angel gonzalez [mailto:mangelgonza...@gmail.com]
Enviado el: jueves, 27 de junio de 2019 5:43 a. m.
Para: Debian ayuda 
Asunto: postfix y correo

Buenas días,
Hacemos envío desde nuestro aplicativo a empresas asociadas con nostros, es 
decir, no es spam.
Es correo necesario de reporte de actividad, el caso es que postfix lo envía no 
da problemas,
pero el cliente nos remite este correo.
Parece que Office365 lo tiene baneado, el caso es que sigo los pasos que 
especifican en su correo
para quitar de la lista de baneo nuestra dirección de correo y ellos envían un 
correo con un link al servidor
de postfix, hay que pinchar en el enlace.
¿Dónde puedo ver el correo entrante en postfix?

El mensaje:

said: 550
5.7.606 Access denied, banned sending IP [1.XXX.XXX.XXX]. To request removal
from this list please visit https://sender.office.com/ and follow the
directions. For more information please go to
http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) (in reply to
RCPT TO command)

Gracias a todos.
--
/m.a.

Podes ver en el /var/log/mail.log
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Vincent Lefevre]

On 2018-10-12 12:22:39 +0200, JUPIN Alain wrote:
> Bonjour,
> 
> Sur une install postfix, j'ai une adresse purement interne dédié aux
> mail de retours technique de certaines (ex backup, cron etc...)
> 
> Sauf que cette adresse qui n'a jamais été diffusée vient d'être
> "découverte" ... comment j'avoue que j'en sais rien, mais je n'ai pas
> approfondi la chose.
> 
> Bref, sur cette adresse là particulièrement, je voudrais rejeter (par
> erreur de distribution) tous les mails dont l'expéditeur n'est pas une
> adresse mail bien précise !

J'utilise smtpd_restriction_classes pour avoir des règles propres
à des destinataires précis. Cf

  http://www.postfix.org/RESTRICTION_CLASS_README.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[ajh-valmer]

On Friday 12 October 2018 12:22:39 JUPIN Alain wrote:
> Sur une install postfix, j'ai une adresse purement interne dédié aux
> mail de retours technique de certaines (ex backup, cron etc...)
> Sauf que cette adresse qui n'a jamais été diffusée vient d'être
> "découverte" ... comment j'avoue que j'en sais rien, mais je n'ai pas
> approfondi la chose.
> Bref, sur cette adresse là particulièrement, je voudrais rejeter (par
> erreur de distribution) tous les mails dont l'expéditeur n'est pas une
> adresse mail bien précise...

Supposons que le nom de domaine du serveur de mails (postfix)
soit "rezo.net".
On créé par exemple un seul mail technique "ad...@rezo.net".
Même si on arrive à bloquer via un serveur pop3/imap (tel dovecot),
tous autres mails, rien n'empêche une personne ou des robots
d'envoyer des mails "???@rezo.net", et postfix et/ou dovecot, 
risque de couiner, sinon dans les logs de postfix.
Côté MUA, non, car seul le mail "ad...@rezo.net" sera configuré.

Bonne soirée.

ajh Valmer

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Pierre Malard]

Effectivement,

Tout ce boulot de filtrage final est le boulot du système de distribution des 
mails (MDA), pas celui du serveur de transmission (MTA). En plus si tu gère le 
service de courrier sur ton serveur, tu peux configurer des outils comme 
Procmail ou Dovecot au niveau du système de messagerie et pas seulement pour un 
utilisateur.

> Le 14 oct. 2018 à 23:03, Yves Rutschle  a 
> écrit :
> 
> On Sat, Oct 13, 2018 at 12:26:43PM +0200, Ph. Gras wrote:
>> Je changerais plutôt d'adresse ou regarderais comment la discriminer avec
>> iptables et/ou fail2ban.
> 
> Faire du filtrage de mail, ça me parait plutôt être le
> boulot de procmail: tu ajoutes un .procmmailrc dans le
> répertoire de l'utilisateur qui reçoit les notifications,
> avec une règle du genre:
> 
> :0
> * !^From: email_autor...@example.org
> /dev/null
> 
> 
> Y.
> 

--
Pierre Malard

   « Je n'ai jamais séparé la République des idées de justice sociale,
 sans laquelle elle n'est qu'un mot »
  Jean Jaures - 
1887
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Yves Rutschle]

On Sat, Oct 13, 2018 at 12:26:43PM +0200, Ph. Gras wrote:
> Je changerais plutôt d'adresse ou regarderais comment la discriminer avec
> iptables et/ou fail2ban.

Faire du filtrage de mail, ça me parait plutôt être le
boulot de procmail: tu ajoutes un .procmmailrc dans le
répertoire de l'utilisateur qui reçoit les notifications,
avec une règle du genre:

:0
* !^From: email_autor...@example.org
/dev/null


Y.

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Frédéric MASSOT]

Le 12/10/2018 à 12:22, JUPIN Alain a écrit :

Bonjour,

Sur une install postfix, j'ai une adresse purement interne dédié aux
mail de retours technique de certaines (ex backup, cron etc...)

Sauf que cette adresse qui n'a jamais été diffusée vient d'être
"découverte" ... comment j'avoue que j'en sais rien, mais je n'ai pas
approfondi la chose.

Bref, sur cette adresse là particulièrement, je voudrais rejeter (par
erreur de distribution) tous les mails dont l'expéditeur n'est pas une
adresse mail bien précise !
J'ai tenté, mais du coup çà s'applique à toutes les boites mails or je
ne le souhaite que pour une seule adresse !
Peut etre via mail drop ?

Donc je vois pas trop quelle directive utiliser pour cela.


Je crois que Postfix ne dispose pas de table où tu peux filtrer à la 
fois sur l'adresse expéditeur et destinataire.


Il faut utiliser plusieurs tables, une première table transport pour 
filtrer les mails sur l'adresse destinataire et ensuite des règles de 
restriction sur l'adresse émetteur.


Tu peux t'inspirer des règles transports "slow" qu'on utilise avec 
Postfix pour diminuer les connexions sortantes vers certains ISP comme 
Orange ou Free.


Fichier master :
slow   unix  -   -  n   -  -  smtp

Fichier transport :
orange.fr slow:
free.fr slow:

Fichier main :
slow_initial_destination_concurrency = 1
slow_destination_concurrency_limit = 4
slow_destination_recipient_limit = 20
slow_destination_rate_delay = 2s








--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Ph. Gras]

Oki :-(

>> smtpd_sender_restrictions = permit_mynetworks,
>>  reject
> Oui, mais du coup cela s'applique à toutes les boites mails de tous les
> domaines hébergés sur le serveur.
> Or ce filtrage je veux le faire pour une seule et unique boite mail !

du coup, je doute fort que Postfix soit capable d'exercer une discrimination
sur une adresse en particulier.

Je changerais plutôt d'adresse ou regarderais comment la discriminer avec
iptables et/ou fail2ban.

Bon courage,

Ph. Gras

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[JUPIN Alain]

Le 12/10/2018 à 12:46, Ph. Gras a écrit :
>
> il me semble que ça se fait avec la commande smtpd_sender_restrictions
>
> smtpd_sender_restrictions = permit_mynetworks,
>   reject
Oui, mais du coup cela s'applique à toutes les boites mails de tous les
domaines hébergés sur le serveur.
Or ce filtrage je veux le faire pour une seule et unique boite mail !

> À vue de nez avec un doigt mouillé ;-)
>
> Sinon, tu peux en essayer d'autres ici :
> https://postfix.traduc.org/index.php/postconf.5.html#smtpd_sender_restrictions
>
> Bonne pioche,
>
> Ph. Gras
>

Alain JUPIN

Re: [Postfix] Rejeter tous les mails sauf pour un expéditeurs précis

[Ph. Gras]

Salut,

> Bref, sur cette adresse là particulièrement, je voudrais rejeter (par
> erreur de distribution) tous les mails dont l'expéditeur n'est pas une
> adresse mail bien précise !
> J'ai tenté, mais du coup çà s'applique à toutes les boites mails or je
> ne le souhaite que pour une seule adresse !
> Peut etre via mail drop ?
> 
> Donc je vois pas trop quelle directive utiliser pour cela.

il me semble que ça se fait avec la commande smtpd_sender_restrictions

smtpd_sender_restrictions = permit_mynetworks,
reject

À vue de nez avec un doigt mouillé ;-)

Sinon, tu peux en essayer d'autres ici :
https://postfix.traduc.org/index.php/postconf.5.html#smtpd_sender_restrictions

Bonne pioche,

Ph. Gras

Re: postfix "delivery-date" - how to?

[Kamil Jońca]

Dan Ritter  writes:

[...]
> but I think you want in-message headers. So you need a filter
> that can insert one cleanly. 

My conclusions are the same (and another solution: lmtp, because it
would be put into dovecot accessed mailboxes)



> I'm not sure why you want to do all this, though, because the
1. Exim can do this, so why not postfix ;) I was simply curious.

> standard set of Received: headers should give you a series of
> timestamps that show the time it took for the message to make
> its way across the Internet and to your mail server, Once it's
> on your mail server, delivery should happen within a second or
> two, maybe 3 for a very heavily loaded system.
It is generally true, unless strange things happen. 

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Wilner's Observation:
All conversations with a potato should be conducted in private.

Re: postfix "delivery-date" - how to?

[Dan Ritter]

On Tue, Apr 24, 2018 at 08:38:39PM +0200, Kamil Jońca wrote:
> 
> Exim has a nice feature: it puts "Delivery-date" header when terminates
> delivery to pipe/mailbox.
> 
> Is it posible with postfix?

It is possible, not necessarily convenient.

Here's how Postfix delivers mail:

http://www.postfix.org/OVERVIEW.html#delivering

See the items on the far right side? Those are transports,
which are configured in master.cf

You can see that local(8) is generally responsible for
writing messages to local users in their
mailbox/maildir/whatever.

You need to insert your timestamp header at that stage.

If you deliver to mailbox, you almost get that for free:

   In the case of UNIX-style mailbox delivery, the local(8) daemon
   prepends a "From sender time_stamp" envelope header to each message,


but I think you want in-message headers. So you need a filter
that can insert one cleanly. 

In Debian's maildrop package, there is a nice filter called
formail. You can use some shell scripting to rig up a local
delivery alternative that postfix calls in master.cf, adds
a header with formail, and then writes to your output file
format of choice.

I'm not sure why you want to do all this, though, because the
standard set of Received: headers should give you a series of
timestamps that show the time it took for the message to make
its way across the Internet and to your mail server, Once it's
on your mail server, delivery should happen within a second or
two, maybe 3 for a very heavily loaded system.

And if you only want this for one or a few users, you could
insert your formail manipulation in their ~/.forward files
instead.

-dsr-

Re: postfix eliminar correos en los buzones por antiguedad

[Itzcoalt Alvarez]

un scrpt deberia hacerlo sin mayor problema.



El 12 de febrero de 2018, 12:26, Ariel Alvarez 
escribió:

> Hola lista existe alguna forma de eliminar los correos contenidos en los
> buzones pasado un tiempo, es decir eliminar los correos mas aniguos de dos
> meses por ejemplo, en este caso uso postfix y la variante para los buzones
> es maildir
>
> gracias de antemano
>
> -
> Consejo Nacional de Casas de Cultura
> http://www.casasdecultura.cult.cu
>
>


--

Re: postfix eliminar correos en los buzones por antiguedad

[Cristian Mitchell]

El 12 de febrero de 2018, 20:18, Cristian Mitchell
escribió:

>
>
> El 12 de febrero de 2018, 15:26, Ariel Alvarez
> escribió:
>
>> Hola lista existe alguna forma de eliminar los correos contenidos en los
>> buzones pasado un tiempo, es decir eliminar los correos mas aniguos de dos
>> meses por ejemplo, en este caso uso postfix y la variante para los buzones
>> es maildir
>>
>> gracias de antemano
>>
>> -
>> Consejo Nacional de Casas de Cultura
>> http://www.casasdecultura.cult.cu
>>
>>
>
>
> --
> MrIX
> Linux user number 412793.
> http://counter.li.org/
>
> las grandes obras,
> las sueñan los santos locos,
> las realizan los luchadores natos,
> las aprovechan los felices cuerdo,
> y las critican los inútiles crónicos,
>
>
Lo que se me ocurre es un cron haciendo un find búsqueda con fechas menores
a x dias y borrar

Ejemplo para buscar archivos más antiguos de 30 días

 find / -mtime +30

Borrar archivos mediante find, más antiguos de 30 días

find /root/* -mtime +30 -exec rm {} \;

-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: postfix eliminar correos en los buzones por antiguedad

[Cristian Mitchell]

El 12 de febrero de 2018, 15:26, Ariel Alvarez escribió:

> Hola lista existe alguna forma de eliminar los correos contenidos en los
> buzones pasado un tiempo, es decir eliminar los correos mas aniguos de dos
> meses por ejemplo, en este caso uso postfix y la variante para los buzones
> es maildir
>
> gracias de antemano
>
> -
> Consejo Nacional de Casas de Cultura
> http://www.casasdecultura.cult.cu
>
>


-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Pierre L.]

La sortie de veille par exemple...



Le 06/10/2017 à 14:07, Marc Chantreux a écrit :
>> De toute manière tout ce qui a un rapport avec des interfaces
>> chaise-clavier ne peut que devenir très compliqué avec le temps.
> +1 
>





signature.asc
Description: OpenPGP digital signature

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Marc Chantreux]

> J'ai du mal a voir ce qui est drôle. Ce qui est compliqué dans le cas
> de Postfix et associé, ce n'est pas le protocole. 

attention: c'était un troll  et faut pas marcher dedans .. mais oui:
c'est facile de critiquer un protocole qui est né dans les années 80,
qui gere des problématiques de decentralisation, de routage, de
communication asynchrones ...

smtp est encore la pour de bonnes raisons et sa popularité diminue pour
de très mauvaises raisons.

et sinon: pour résoudre une partie du problème posée par smtp (à savoir
les confs de serveur imbittables)

sudo aptitude install opensmtpd $(
aptitude search '~i ~Pmail-transport-agent' -F%p
)-

> De toute manière tout ce qui a un rapport avec des interfaces
> chaise-clavier ne peut que devenir très compliqué avec le temps.

+1 

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Haricophile]

Le Fri, 6 Oct 2017 07:57:35 +0200,
"Ph. Gras"  a écrit :

> Hello les gens !
> 
> Saviez-vous ce que signifie SMTP ?
> 
> Simple Mail Transfert Protocol
> 
> MDR -D
> 
> Ph. Gras
> 

P.S. En plus on vois bien que tu es un petit jeune qui n'a jamais
entendu parler de X.400 que SMTP a supplanté !

-- 
haricoph...@aranha.fr 

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Haricophile]

Le Fri, 6 Oct 2017 07:57:35 +0200,
"Ph. Gras"  a écrit :

> Hello les gens !
> 
> Saviez-vous ce que signifie SMTP ?
> 
> Simple Mail Transfert Protocol
> 
> MDR -D
> 
> Ph. Gras

J'ai du mal a voir ce qui est drôle. Ce qui est compliqué dans le cas
de Postfix et associé, ce n'est pas le protocole.

De toute manière tout ce qui a un rapport avec des interfaces
chaise-clavier ne peut que devenir très compliqué avec le temps.


-- 
haricoph...@aranha.fr 

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Eric Degenetais]

Le 6 octobre 2017 à 06:54, BERTRAND Joel  a
écrit :
> Ph. Gras a écrit :
>
>> Hello les gens !
>>
>> Saviez-vous ce que signifie SMTP ?
>>
>> Simple Mail Transfert Protocol
>>
>> MDR -D
>>
>> Ph. Gras
>
>
> Ehoh ! Il y a longtemps qu'on est passé à ESMTP.Et sais-tu ce que
> signifie le E ? ;-)
>
> JKB
>
Emetic ?
Enterocolic ?

__
Éric Dégenètais
Henix

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[BERTRAND Joel]

Ph. Gras a écrit :

Hello les gens !

Saviez-vous ce que signifie SMTP ?

Simple Mail Transfert Protocol

MDR -D

Ph. Gras


	Ehoh ! Il y a longtemps qu'on est passé à ESMTP.Et sais-tu ce que 
signifie le E ? ;-)


JKB

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Marc Chantreux]

On Fri, Oct 06, 2017 at 07:57:35AM +0200, Ph. Gras wrote:
> Saviez-vous ce que signifie SMTP ?
> Simple Mail Transfert Protocol

"la messagerie c'était pire avant" :)

tu sais ce que signifie HTTP ?

vu les multiples détournements, c'est bien risible aussi et 
encore une fois, si on a pas le contexte et le besoin d'origine.

bon troll
marc

Re: Postfix/batch: configurer l'adresse d'émission et renvoyer des messages en arrivée vers un tiers

[Olivier]

Bonjour,

1. Je viens à l'instant de tester la solution de Sébastien avec le fichier
canonical.
Elle fonctionne parfaitement avec n'importe quelle combinaison des deux
lignes ci-après.
Par contre, chez le destinataire, l'adresse de l'émetteur s'affiche en
"root " là ou j'aurai peut-être préféré
quelque chose ressemblant à "Exemple ".

root t...@exemple.fr
r...@mamachine.dedibox.fr t...@exemple.fr

Peut-être qu'en ajoutant une ligne comme "root   "Exemple ",
je parviendrai à mes fins.


Par ailleurs, la solution de Daniel me parait aussi intéressante car je
risque d'avoir besoin d'émettre avec plusieurs identités différentes.
Je vais l'étudier de plus près et étudier les autres points.


À suivre

Le 3 juillet 2017 à 10:16, Daniel Caillibaud  a écrit :

> Le 30/06/17 à 13:54, Olivier  a écrit :
> O> $ mail -s Essai15 mondestinataire.fr
> O> le corps de mon message
> O> CC:
> O>
> O> Dans ce cas, j'observe dans /var/log/syslog que Postfix n'émets pas
> avec la
> O> bonne adresse :
> O> Jun 30 13:41:35 mamachine postfix/qmgr[23481]: 59D953160331: from=<
> O> r...@mamachine.dedibox.fr>, size=379, nrcpt=1 (queue active)
>
> parce que tu as lancé cette commande en root…
>
> O> Mes questions sont:
> O> 1. Comment pouvoir émettre depuis un programme batch sur un serveur, en
> O> utilisant les identifiants de mon compte t...@exemple.fr ?
>
> Utiliser les identifiants ? Tu veux que ton script se connecte au smtp de
> t...@exemple.fr ?
>
> Si tu veux simplement que le From soit t...@exemple.fr, amha le plus
> simple est de créer un
> user local toto, et de dire à postfix que son adresse d'expéditeur est
> t...@exemple.fr, par ex
> via smtp_generic_maps (cf la doc postfix).
>
> Après ce smtp_generic_maps, les mails envoyés par le user local toto en
> ligne de commande (ou
> via un script exécuté par toto) auront un from t...@exemple.fr
>
> Pour que les mails locaux envoyés au user toto aillent vers
> t...@exemple.fr, faut ajouter
>   toto: t...@exemple.fr
> à /etc/aliases
> (et lancer postalias après chaque modif)
>
> Après cette modif de/etc/aliases , toutes tes commandes
>   mail -s "sujet" toto < fichier
> enverront le contenu de fichier à t...@exemple.fr (avec le from de celui
> qui lance la commande)
>
> O> 2. J'imagine possible de reconfigurer chez 1and1, ma boîte
> t...@exemple.fr
> O> de telle sorte que chaque email qu'elle recoive soit renvoyé vers une
> boîte
> O> tierce (p...@tagada.com) puis supprimé.
>
> Quel intérêt d'écrire à t...@exemple.fr si ça doit être redirigé vers
> ailleurs ? écrit
> directement ailleurs.
>
> O> Pour la beauté du geste, est-il possible et pas trop compliqué de
> O> configurer ce renvoi sur ma propre machine, en filtrant selon l'adresse
> O> d'émission.
> O> ("Si le courriel vient de @important.fr, renvoyer vers
> p...@tagada.com,
> O> sinon poubelle).
>
> Ça tu peux le faire avec procmail sur le serveur mail de réception
> (peut-être aussi avec sieve).
>
> --
> Daniel
>
> Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent
> obscurément ont des commentateurs.
> Albert Camus
>
>

Re: Postfix/batch: configurer l'adresse d'émission et renvoyer des messages en arrivée vers un tiers

[Daniel Caillibaud]

Le 30/06/17 à 13:54, Olivier  a écrit :
O> $ mail -s Essai15 mondestinataire.fr
O> le corps de mon message
O> CC:
O> 
O> Dans ce cas, j'observe dans /var/log/syslog que Postfix n'émets pas avec la
O> bonne adresse :
O> Jun 30 13:41:35 mamachine postfix/qmgr[23481]: 59D953160331: from=<
O> r...@mamachine.dedibox.fr>, size=379, nrcpt=1 (queue active)

parce que tu as lancé cette commande en root…

O> Mes questions sont:
O> 1. Comment pouvoir émettre depuis un programme batch sur un serveur, en
O> utilisant les identifiants de mon compte t...@exemple.fr ?

Utiliser les identifiants ? Tu veux que ton script se connecte au smtp de 
t...@exemple.fr ?

Si tu veux simplement que le From soit t...@exemple.fr, amha le plus simple est 
de créer un
user local toto, et de dire à postfix que son adresse d'expéditeur est 
t...@exemple.fr, par ex
via smtp_generic_maps (cf la doc postfix).

Après ce smtp_generic_maps, les mails envoyés par le user local toto en ligne 
de commande (ou
via un script exécuté par toto) auront un from t...@exemple.fr

Pour que les mails locaux envoyés au user toto aillent vers t...@exemple.fr, 
faut ajouter
  toto: t...@exemple.fr
à /etc/aliases
(et lancer postalias après chaque modif)

Après cette modif de/etc/aliases , toutes tes commandes
  mail -s "sujet" toto < fichier
enverront le contenu de fichier à t...@exemple.fr (avec le from de celui qui 
lance la commande)

O> 2. J'imagine possible de reconfigurer chez 1and1, ma boîte t...@exemple.fr
O> de telle sorte que chaque email qu'elle recoive soit renvoyé vers une boîte
O> tierce (p...@tagada.com) puis supprimé.

Quel intérêt d'écrire à t...@exemple.fr si ça doit être redirigé vers ailleurs 
? écrit
directement ailleurs.

O> Pour la beauté du geste, est-il possible et pas trop compliqué de
O> configurer ce renvoi sur ma propre machine, en filtrant selon l'adresse
O> d'émission.
O> ("Si le courriel vient de @important.fr, renvoyer vers p...@tagada.com,
O> sinon poubelle).

Ça tu peux le faire avec procmail sur le serveur mail de réception (peut-être 
aussi avec sieve).

-- 
Daniel

Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent
obscurément ont des commentateurs.
Albert Camus 

Re: Postfix/batch: configurer l'adresse d'émission et renvoyer des messages en arrivée vers un tiers

[Sébastien NOBILI]

Bonjour,

Sous réserve que j’aie bien compris ce que tu veux faire…

Le vendredi 30 juin 2017 à 13:54, Olivier a écrit :
> 1. Comment pouvoir émettre depuis un programme batch sur un serveur, en
> utilisant les identifiants de mon compte t...@exemple.fr ?

Chez moi je fais ça avec « canonical » [1].

1: http://www.postfix.org/canonical.5.html

Dans main.cf :

canonical_maps = hash:/etc/postfix/canonical

Dans « /etc/postfix/canonical » :

root t...@exemple.fr
r...@mamachine.dedibox.fr t...@exemple.fr

(Pas sûr que la deuxième ligne soit vraiment nécessaire…)

Puis :

postmap /etc/postfix/canonical

> 2. J'imagine possible de reconfigurer chez 1and1, ma boîte t...@exemple.fr
> de telle sorte que chaque email qu'elle recoive soit renvoyé vers une boîte
> tierce (p...@tagada.com) puis supprimé.
> Pour la beauté du geste, est-il possible et pas trop compliqué de
> configurer ce renvoi sur ma propre machine, en filtrant selon l'adresse
> d'émission.
> ("Si le courriel vient de @important.fr, renvoyer vers p...@tagada.com,
> sinon poubelle).

Quand tu parles de ta « propre machine », tu veux parler du serveur Postfix ?
Si oui, alors, tu dois pouvoir y arriver avec « sender_bcc » [2].

2: http://www.postfix.org/postconf.5.html#sender_bcc_maps

Dans « main.cf » :

sender_bcc_maps = hash:/etc/postfix/sender_bcc

Dans « /etc/postfix/sender_bcc » :

@important.fr p...@tagada.com

Puis :

postmap /etc/postfix/sender_bcc

Sébastien

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

Bonsoir
J'en suis à la configuration du TLS sur SMTP
Voilà la configuration que j'ai pour le moment, et qui n'autorise que
TLS 1.2
La configuration é été vérifiée successivement avec le site suivant htt
ps://ssl-tools.net/mailservers
Il considère une configuration fiable si TLS 1.0 ou  1.1 sont permis,
mais je compte bien les bannir, sauf si quelque chose m'oblige à
revenir en arrière.
C'est un extrait de mon  /etc/postfix/main.cf ;
smtpd_tls_security_level = encryptsmtpd_tls_received_header =
nosmtpd_tls_auth_only = yessmtpd_tls_loglevel = 1smtpd_tls_cert_file =
/path/to/cert.pemsmtpd_tls_key_file = /path/to/priv.keysmtpd_use_tls =
yessmtp_tls_note_starttls_offer = yessmtpd_tls_session_cache_timeout =
3600ssmtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, DES-CBC3-SHA,
RC4-SHA, AES256-SHA, AES128-SHAtls_high_cipherlist =
ECDH+aRSA+AES256:ECDH+aRSA+AES128:AES256-SHA:DES-CBC3-
SHAsmtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1,
!TLSv1.1smtpd_tls_mandatory_protocols = TLSv1.2
Le vendredi 14 avril 2017 à 22:32 +0200, andre_deb...@numericable.fr a
écrit :
> On Tuesday 04 April 2017 10:43:15 Thierry Bugier Pineau wrote:
> > le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
> > silence.  J'ai préparé postfix, je continue avec Dovecot dans les
> jours
> > à venir et ensuite je m'attaque au TLS pour atteindre le même
> niveau de
> > progression et donner un coup de main.
> > J'essaie aussi de créer un script shell (très sommaire) pour rendre
> la
> > configuration maintenable et reproductible (que je partagerai
> > volontiers sur github).
> 
> On Tuesday 04 April 2017 14:12:45 andre_deb...@numericable.fr wrote:
> > Je l'attends avec plaisir, merci d'avance.
> > Ça fait longtemps que dovecot + certificats me posent soucis... :-)
> > Bonne journée,  André
> 
> Je n'ai pas reçu de réponse à cette promesse ci-dessus... :-)
> 
> André
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

J'y pense ; il faut juste que je me dégage un peu de temps. Je ne n ai pas 
vraiment eu pour l'instant.

En passant j'ai trouvé sur le wiki de Dovecot un script shell qui permet 
d'éditer sa configuration via la ligne de commande ou un autre script. C'est 
partiellement expérimental. On n'a pas d'équivalent à postconf ? Cet outil 
facilite énormément le travail d'automatisation.

Le 14 avril 2017 22:32:21 GMT+02:00, andre_deb...@numericable.fr a écrit :
>On Tuesday 04 April 2017 10:43:15 Thierry Bugier Pineau wrote:
>> le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
>> silence.  J'ai préparé postfix, je continue avec Dovecot dans les
>jours
>> à venir et ensuite je m'attaque au TLS pour atteindre le même niveau
>de
>> progression et donner un coup de main.
>> J'essaie aussi de créer un script shell (très sommaire) pour rendre
>la
>> configuration maintenable et reproductible (que je partagerai
>> volontiers sur github).
>
>On Tuesday 04 April 2017 14:12:45 andre_deb...@numericable.fr wrote:
>> Je l'attends avec plaisir, merci d'avance.
>> Ça fait longtemps que dovecot + certificats me posent soucis... :-)
>> Bonne journée,  André
>
>Je n'ai pas reçu de réponse à cette promesse ci-dessus... :-)
>
>André

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Tuesday 04 April 2017 10:43:15 Thierry Bugier Pineau wrote:
> le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
> silence.  J'ai préparé postfix, je continue avec Dovecot dans les jours
> à venir et ensuite je m'attaque au TLS pour atteindre le même niveau de
> progression et donner un coup de main.
> J'essaie aussi de créer un script shell (très sommaire) pour rendre la
> configuration maintenable et reproductible (que je partagerai
> volontiers sur github).

On Tuesday 04 April 2017 14:12:45 andre_deb...@numericable.fr wrote:
> Je l'attends avec plaisir, merci d'avance.
> Ça fait longtemps que dovecot + certificats me posent soucis... :-)
> Bonne journée,  André

Je n'ai pas reçu de réponse à cette promesse ci-dessus... :-)

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Tuesday 04 April 2017 10:43:15 Thierry Bugier Pineau wrote:
> le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
> silence.  J'ai préparé postfix, je continue avec Dovecot dans les jours
> à venir et ensuite je m'attaque au TLS pour atteindre le même niveau de
> progression et donner un coup de main.
> J'essaie aussi de créer un script shell (très sommaire) pour rendre la
> configuration maintenable et reproductible (que je partagerai
> volontiers sur github).

Je l'attends avec plaisir, merci d'avance.

Ça fait longtemps que dovecot + certificats me posent soucis... :-)

Bonne journée,

André

> Le mardi 04 avril 2017 à 10:24 +0200, andre_debian a écrit :
> > J'avais déclaré le sujet "résolu" un peu vite, désolé.
> > Ça ne fonctionne pas avec "imap",
> > voici ce que Kmail me répond (port 143 ou 993) :
> > =
> > "impossible de se connecter à « imap.mon_domaine »
> > Le serveur n'a pas répondu correctement :
> > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
> > IDLE 
> > STARTTLS AUTH=PLAIN] Dovecot ready"
> > =
> > Avec le port 110, ça fonctionne mais je dois confirmer le certificat.
> > André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

Bonjour
le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
silence.  J'ai préparé postfix, je continue avec Dovecot dans les jours
à venir et ensuite je m'attaque au TLS pour atteindre le même niveau de
progression et donner un coup de main.
J'essaie aussi de créer un script shell (très sommaire) pour rendre la
configuration maintenable et reproductible (que je partagerai
volontiers sur github).


Le mardi 04 avril 2017 à 10:24 +0200, andre_deb...@numericable.fr a
écrit :
> J'avais déclaré le sujet "résolu" un peu vite, désolé.
> Ça ne fonctionne pas avec "imap",
> 
> voici ce que Kmail me répond (port 143 ou 993) :
> =
> "impossible de se connecter à « imap.mon_domaine »
> Le serveur n'a pas répondu correctement :
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
> IDLE 
> STARTTLS AUTH=PLAIN] Dovecot ready"
> =
> 
> Avec le port 110, ça fonctionne mais je dois confirmer le certificat.
> 
> Bonne journée,
> 
> André
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

J'avais déclaré le sujet "résolu" un peu vite, désolé.
Ça ne fonctionne pas avec "imap",

voici ce que Kmail me répond (port 143 ou 993) :
=
"impossible de se connecter à « imap.mon_domaine »
Le serveur n'a pas répondu correctement :
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
STARTTLS AUTH=PLAIN] Dovecot ready"
=

Avec le port 110, ça fonctionne mais je dois confirmer le certificat.

Bonne journée,

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[andre_debian]

On Friday 31 March 2017 22:11:31 Thierry Bugier Pineau wrote:
> Voilà ce que j'ai pour mon serveur web dans la cipher suite 
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
> CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-
> SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-
> AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Merci.

Dans le serveur Web, mais mon souci est dans Postfix-Dovecot-SSL/TLS.

> Ca ne liste que des méthodes de chiffrement, le protocole est dans un
> paramétrage à part, contrairement à ce que j'avais dans mon souvenir. 
> En cherchant activement il semble que !SSLv3 !TLSv1.0 et !TLSv1.1
> auraient mieux leur place dans ssl_protocols (qui devrait être sur la
> ligne précédant ssl_cipher_list)

ssl_protocols = ...  dans le fichier "dovecot.conf" ?
Si oui, cette ligne n'a pas été créée lors de l'installation de dovecot.

> je pense que vous pouvez essayer d'ajouter !SSLv3 puis !TLSv1.0 et
> !TLSv1.1 successivement en testant à chaque fois, et voir si des
> problèmes apparaissent. Du moment que vous gardez une configuration qui
> fonctionne au chaud, il n'y a pas de risque particulier.

Ou et comment ajouter "!SSLv3 puis !TLSv1.0 !TLSv1.1" ?

> En réponse à votre dernier message :
> - Je remets le lien vers la page wikipédia : l'accent a été altéréhttps
> ://fr.wikipedia.org/wiki/Confidentialité_persistante

Ok, ça fonctionne, page instructive.

> - un exemple de connection client avec openssl en forçant tls1 (testé
> sur imap.gmail.com)openssl s_client -connect imap.server.com:993 -tls1
> Je suis sous Debian Sid, et -ssl2 et -ssl3 ne sont apparemment plus
> reconnus (bien qu'encore présents dans la documentation).  

Bonne journée,

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[Thierry Bugier Pineau]

Voilà ce que j'ai pour mon serveur web dans la cipher suite 
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-
SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-
AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Ca ne liste que des méthodes de chiffrement, le protocole est dans un
paramétrage à part, contrairement à ce que j'avais dans mon souvenir. 
En cherchant activement il semble que !SSLv3 !TLSv1.0 et !TLSv1.1
auraient mieux leur place dans ssl_protocols (qui devrait être sur la
ligne précédant ssl_cipher_list)
je pense que vous pouvez essayer d'ajouter !SSLv3 puis !TLSv1.0 et
!TLSv1.1 successivement en testant à chaque fois, et voir si des
problèmes apparaissent. Du moment que vous gardez une configuration qui
fonctionne au chaud, il n'y a pas de risque particulier.
En réponse à votre dernier mesage :
- Je remets le lien vers la page wikipédia : l'accent a été altéréhttps
://fr.wikipedia.org/wiki/Confidentialité_persistante
- un exemple de connection client avec openssl en forçant tls1 (testé
sur imap.gmail.com)openssl s_client -connect imap.server.com:993 -tls1
Je suis sous Debian Sid, et -ssl2 et -ssl3 ne sont apparemment plus
reconnus (bien qu'encore présents dans la documentation).  
Le vendredi 31 mars 2017 à 19:00 +0200, andre_deb...@numericable.fr a
écrit :
> On Friday 31 March 2017 14:22:31 Thierry Bugier Pineau wrote:
> > Ce serait intéressant de savoir ce que contenant la liste
> > ssl_cipher_list avant modification, et ce qu'elle contient
> maintenant.
> 
> Avant :
> ssl_cipher_list =
> ALL:!LOW:!SSLv2:!SSLv3:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:
> +HIGH:+MEDIUM
> 
> Maintenant :
> ssl_cipher_list = TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES
> @STRENGTH
> 
> > Je vous invite à utiliser un outil de test SSL / TLS en ligne : 
> 
> SSL/TLS est bien activé et l'outil de test est positif,
> openssl, testssl etc...
> 
> > pour affiner la configuration maintenant, car il y a un paquet 
> > de  choses à faire pour avoir un chiffrement pas trop fragile.
> 
> "Affiner et un paquet de  choses à faire" :
> que peut-on faire ?  Là je suis dépassé...
> 
> André
> 
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[andre_debian]

On Friday 31 March 2017 20:07:37 Thierry Bugier Pineau wrote:
> De ce que je vois la nouvelle liste n'exclut pas explicitement SSLv3,
> TLSv1.0 et TLSv1.1. Ces trois méthodes de chiffrement sont désormais
> vulnérables.
> Je pense que vous devez inventorier les clients mail qui seront
> utilisés et rechercher pour chacun si ils supportent TLSv1.2. Si c'est
> le cas (ce qui est très probable) alors il faut a jouter !SSLv3,
> !TLSv1.0 et !TLSv1.1 . Je devine que vous avez pris votre liste quelque
> part sur une vieille source non maintenue (elles pulullent et ce mail
> sera obsolète dans quelques mois ou années). 
> En gros, SSL est complètement obsolète et seul TLSv1.2+ reste encore
> valable (de ce que je sais à ce jour).
> Pour tester si SSLv2, v2 et TLS v1.0, 1.1 sont permis, réutilisez la
> commande openssl s_client que j'ai donnée il y a quelques jours et
> ajoutez un argument qui force l'usage d'une méthode de chiffrement.
> Essayez successivement les arguments suivants:

> -ssl2-ssl3-tls1-tls1_1-tls1_2 :
Ou place t-on ces arguments ?

> (https://www.openssl.org/docs/man1.0.1/apps/s_client.html)
> Une bonne configuration fera en sorte que seul -tls1_2 aboutira à une
> connection réussie. Les autres doivent échouer.
> Après il y a le perfect forward secrecy à vérifier, je n'ai pas encore
> la connaissance suffisante à ce sujet mais c'est encore uen question de
> réglage sur le SSL/TLS. (introduction ici :

> https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante :
Erreur 404...

> Peut être que la cipher suite préférée pour mon serveur web sera
> intéressante; je la partage tout à l'heure :

Oui, je veux bien.

@+

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[Thierry Bugier Pineau]

Bonsoir
De ce que je vois la nouvelle liste n'exclut pas explicitement SSLv3,
TLSv1.0 et TLSv1.1. Ces trois méthodes de chiffrement sont désormais
vulnérables.
Je pense que vous devez inventorier les clients mail qui seront
utilisés et rechercher pour chacun si ils supportent TLSv1.2. Si c'est
le cas (ce qui est très probable) alors il faut a jouter !SSLv3,
!TLSv1.0 et !TLSv1.1 . Je devine que vous avez pris votre liste quelque
part sur une vieille source non maintenue (elles pulullent et ce mail
sera obsolète dans quelques mois ou années). 
En gros, SSL est complètement obsolète et seul TLSv1.2+ reste encore
valable (de ce que je sais à ce jour).
Pour tester si SSLv2, v2 et TLS v1.0, 1.1 sont permis, réutilisez la
commande openssl s_client que j'ai donnée il y a quelques jours et
ajoutez un argument qui force l'usage d'une méthode de chiffrement.
Essayez successivement les arguments suivants:
-ssl2-ssl3-tls1-tls1_1-tls1_2
(plus de détail ici https://www.openssl.org/docs/man1.0.1/apps/s_client
.html)
Une bonne configuration fera en sorte que seul -tls1_2 aboutira à une
connection réussie. Les autres doivent échouer.
Après il y a le perfect forward secrecy à vérifier, je n'ai pas encore
la connaissance suffisante à ce sujet mais c'est encore uen question de
réglage sur le SSL/TLS. (introduction ici https://fr.wikipedia.org/wiki
/Confidentialit%C3%A9_persistante)
Peut être que la cipher suite préférée pour mon serveur web sera
intéressante; je la partage tout à l'heure.
Le vendredi 31 mars 2017 à 19:00 +0200, andre_deb...@numericable.fr a
écrit :
> On Friday 31 March 2017 14:22:31 Thierry Bugier Pineau wrote:
> > Ce serait intéressant de savoir ce que contenant la liste
> > ssl_cipher_list avant modification, et ce qu'elle contient
> maintenant.
> 
> Avant :
> ssl_cipher_list =
> ALL:!LOW:!SSLv2:!SSLv3:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:
> +HIGH:+MEDIUM
> 
> Maintenant :
> ssl_cipher_list = TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES
> @STRENGTH
> 
> > Je vous invite à utiliser un outil de test SSL / TLS en ligne : 
> 
> SSL/TLS est bien activé et l'outil de test est positif,
> openssl, testssl etc...
> 
> > pour affiner la configuration maintenant, car il y a un paquet 
> > de  choses à faire pour avoir un chiffrement pas trop fragile.
> 
> "Affiner et un paquet de  choses à faire" :
> que peut-on faire ?  Là je suis dépassé...
> 
> André
> 
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[andre_debian]

On Friday 31 March 2017 14:22:31 Thierry Bugier Pineau wrote:
> Ce serait intéressant de savoir ce que contenant la liste
> ssl_cipher_list avant modification, et ce qu'elle contient maintenant.

Avant :
ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:
+HIGH:+MEDIUM

Maintenant :
ssl_cipher_list = TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES @STRENGTH

> Je vous invite à utiliser un outil de test SSL / TLS en ligne : 

SSL/TLS est bien activé et l'outil de test est positif,
openssl, testssl etc...

> pour affiner la configuration maintenant, car il y a un paquet 
> de  choses à faire pour avoir un chiffrement pas trop fragile.

"Affiner et un paquet de  choses à faire" :
que peut-on faire ?  Là je suis dépassé...

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[Thierry Bugier Pineau]

Bonjour
Ce serait intéressant de savoir ce que contenant la lishe
ssl_cipher_list avant modification, et ce qu'elle contient maintenant.
A propos de /etc/hosts, il est clair que c'était pas le souci, mais
dans les essais fait il y a quelques jours, le serveur ne pouvait pas
résoudre son propre nom. Modifier /etc/hosts résout ce petit détail.
Je vous invite à utilsier un outil de test SSL / TLS en ligne pour
affiner la configuration maintenant, car il y a un paquet de choses à
faire pour avoir un chiffrement pas trop fragile.


Le vendredi 31 mars 2017 à 12:20 +0200, andre_deb...@numericable.fr a
écrit :
> On Thursday 30 March 2017 16:00:40 andre_deb...@numericable.fr wrote:
> > ça semble remarcher.
> 
> > # tail /var/log/mail.err
> > n'affiche plus d'erreur : "SSL23: unknown protocol",
> > mais toujours l'erreur :
> > "pop3-login : Error : ssl3_get_client_hello : no shared cipher"
> 
> Je n'ai plus de message d'erreur dans :
> /var/log/mail.err, ni /var/log/mail.log
> 
> Le problème venait de "cipher",
> /etc/dovecot/conf.d/10-ssl.conf" => ligne "ssl_cipher_list = "
> à adapter.
> 
> Bonne journée à tous,
> 
> André
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol : RÉSOLU

[andre_debian]

On Thursday 30 March 2017 16:00:40 andre_deb...@numericable.fr wrote:
> ça semble remarcher.

> # tail /var/log/mail.err
> n'affiche plus d'erreur : "SSL23: unknown protocol",
> mais toujours l'erreur :
> "pop3-login : Error : ssl3_get_client_hello : no shared cipher"

Je n'ai plus de message d'erreur dans :
/var/log/mail.err, ni /var/log/mail.log

Le problème venait de "cipher",
/etc/dovecot/conf.d/10-ssl.conf" => ligne "ssl_cipher_list = "
à adapter.

Bonne journée à tous,

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Tuesday 28 March 2017 13:57:29 Thierry Bugier Pineau wrote:
> Dans mes diverses notes j'ai retenu ceci pour /etc/hosts
> 127.0.0.1 localhost127.0.1.1  nom-serveur.domaine 
> domaine  pop.domaine  smtp.domaine :

Je pense pas que ces lignes de "/etc/hosts" soient la cause du problème :-)

> Pour ces erreurs je n'ai pas encore pu fouiller mes notes; mais un coup
> d'oeil sur google m'a montré que ce n'est pas spécifique à dovecot,
> donc il y a potentiellement un réel souci sur le SSL ou bien sur
> l'utilisation de SSL par Dovecot :

En modifiant la ligne "/etc/dovecot/conf.d/10-ssl.conf" :
ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:
+HIGH:+MEDIUM
ça semble remarcher.

La détection auto de Kmail me met :
TLS, port 110, méthode d'identification PLAIN,
OK
En mettant le port 995 à la mano = OK aussi.

# tail /var/log/mail.err
n'affiche plus d'erreur : "SSL23: unknown protocol",
mais toujours l'erreur :
"pop3-login : Error : ssl3_get_client_hello : no shared cipher"

Bonne journée,

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

Le mardi 28 mars 2017 à 11:02 +0200, andre_deb...@numericable.fr a
écrit :
> On Monday 27 March 2017 09:05:21 Thierry Bugier Pineau wrote:
> > Apparemment 2 essais sur 3 sont bons, et celui qui échoue doit
> venir du
> > fait que la résolution DNS sur le serveur n'est pas configurée pour
> > résoudre son propre nom. Au plus simple, il faudrait mettre à jour
> > /etc/hosts. C'est quand même mieux que le serveur sache comment il
> > s'appelle :
> 
> Le fichier "/etc/hosts" sur le serveur :
>  nom-serveur.domaine  domaine  pop.domaine  smtp.domaine
> C'est bon ?

Dans mes diverses notes j'ai retenu ceci pour /etc/hosts
127.0.0.1   localhost127.0.1.1  nom-serveur.domaine 
domaine  pop.domaine  smtp.domaine
D'ailleurs si quelqu'un sait m'expliquer pourquoi attribuer les noms
"personnalisés" sur 127.0.1.1 au lieu de 127.0.0.1, je suis preneur.
J'ai remarqué que si on ne remplit pas le fichier correctement la
commande hostname peut s'en trouver perturbée. Je conseille donc de
vérifier après le changement que hostname -d, hostname -s et hostname
-f donnent un résultat cohérent, sans lenteur. 
> > Dans les cas où la connection réussit, il faudrait vérifier qu'un
> > chiffrement est bien mis en place. La seule ligne "+OK Dovecot
> ready"
> > ne l'indique pas mais il doit y avoir une bonne quantité d'infos
> avant
> > elle; notamment au début :
> 
> Oui, avant "+OK Dovecot ready" il y a des tas d'infos sur le
> certificat,
> sans message d'erreur.
> 
> > A propos de l'erreur dans /var/log/mail.err, je chercherai tout à
> > l'heure dans mes notes si j'ai des infos à ce sujet :
> 
> Elles sont toujours d'actualité, je les rappelle :
> 
> dovecot: pop3-login: Error: SSL: Stacked error: error:140760FC:SSL 
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> 
> dovecot: pop3-login: Error: SSL: Stacked error: error:1408A0C1:SSL 
> routines:ssl3_get_client_hello:no shared cipher

Pour ces erreurs je n'ai pas encore pu fouiller mes notes; mais un coup
d'oeil sur google m'a montré que ce n'est pas spécifique à dovecot,
donc il y a potentiellement un réel souci sur le SSL ou bien sur
l'utilisation de SSL par Dovecot.

> Merci,
> 
> André
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Monday 27 March 2017 09:05:21 Thierry Bugier Pineau wrote:
> Apparemment 2 essais sur 3 sont bons, et celui qui échoue doit venir du
> fait que la résolution DNS sur le serveur n'est pas configurée pour
> résoudre son propre nom. Au plus simple, il faudrait mettre à jour
> /etc/hosts. C'est quand même mieux que le serveur sache comment il
> s'appelle :

Le fichier "/etc/hosts" sur le serveur :
 nom-serveur.domaine  domaine  pop.domaine  smtp.domaine
C'est bon ?

> Dans les cas où la connection réussit, il faudrait vérifier qu'un
> chiffrement est bien mis en place. La seule ligne "+OK Dovecot ready"
> ne l'indique pas mais il doit y avoir une bonne quantité d'infos avant
> elle; notamment au début :

Oui, avant "+OK Dovecot ready" il y a des tas d'infos sur le certificat,
sans message d'erreur.

> A propos de l'erreur dans /var/log/mail.err, je chercherai tout à
> l'heure dans mes notes si j'ai des infos à ce sujet :

Elles sont toujours d'actualité, je les rappelle :

dovecot: pop3-login: Error: SSL: Stacked error: error:140760FC:SSL 
routines:SSL23_GET_CLIENT_HELLO:unknown protocol

dovecot: pop3-login: Error: SSL: Stacked error: error:1408A0C1:SSL 
routines:ssl3_get_client_hello:no shared cipher

Merci,

André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

Bonjour
Apparemment 2 essais sur 3 sont bons, et celui qui échoue doit venir du
fait que la résolution DNS sur le serveur n'est pas configurée pour
résoudre son propre nom. Au plus simple, il faudrait mettre à jour
/etc/hosts. C'est quand même mieux que le serveur sache comment il
s'appelle.
Dans les cas où la connection réussit, il faudrait vérifier qu'un
chiffrement est bien mis en place. La seule ligne "+OK Dovecot ready"
ne l'indique pas mais il doit y avoir une bonne quantité d'infos avant
elle; notamment au début.
A propos de l'erreur dans /var/log/mail.err, je chercherai tout à
l'heure dans mes notes si j'ai des infos à ce sujet. 
Le dimanche 26 mars 2017 à 23:23 +0200, andre_deb...@numericable.fr a
écrit :
> On Sunday 26 March 2017 22:27:06 you wrote:
> > J'ai fait un test avec le serveur SMTP de gmail :
> > openssl s_client -connect smtp.gmail.com:995 -debug
> > et ça a fonctionné. Il y aura une quantité importante
> d'informations :
> 
> Depuis mon serveur :
> openssl s_client -connect localhost:995 -debug :
> les d'infos...
> +OK Dovecot ready.
> 
> openssl s_client -connect :995 -debug :
> aucune réponse... ou
> gethostbyname failure
> connect:errno=0
> 
> Depuis un poste client :
> openssl s_client -connect :995 -debug :
> les d'infos...
> +OK Dovecot ready.
> 
> tail /var/log/mail.err :
> ssl3_get_client_hello:no shared cipher
> SSL23_GET_CLIENT_HELLO:unknown protocol
> 
> Voilà le topo,
> 
> bonne fin de soirée,
> 
> André
> 
> > > > Le 26 mars 2017 19:45:28 GMT+02:00, andré a écrit :
> > > > >J'ai un serveur postfix + dovecot + ssl.
> > > > >Il marche parfaitement avec le port POP 110,
> > > > >mais pas du tout en mode SSL port 995.
> > > > >Voici ce que me dit "tail /var/log/mail.err" :
> > > > >dovecot: pop3-login: Error: SSL: Stacked error:
> > > error:140760FC:SSL 
> > > > >routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> > > > >Mes certifs crt et key semblent bons.
> > > > >J'en ai créés d'autres mais idem.
> > > > >J'ai fouillé via Google, ce message m'apporte des centaines
> > > > >de liens mais aucun ne m'aide.
> > > > >Merci d'une piste...  André
> 
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Sunday 26 March 2017 22:27:06 you wrote:
> J'ai fait un test avec le serveur SMTP de gmail :
> openssl s_client -connect smtp.gmail.com:995 -debug
> et ça a fonctionné. Il y aura une quantité importante d'informations :

Depuis mon serveur :
openssl s_client -connect localhost:995 -debug :
les d'infos...
+OK Dovecot ready.

openssl s_client -connect :995 -debug :
aucune réponse... ou
gethostbyname failure
connect:errno=0

Depuis un poste client :
openssl s_client -connect :995 -debug :
les d'infos...
+OK Dovecot ready.

tail /var/log/mail.err :
ssl3_get_client_hello:no shared cipher
SSL23_GET_CLIENT_HELLO:unknown protocol

Voilà le topo,

bonne fin de soirée,

André

> > > Le 26 mars 2017 19:45:28 GMT+02:00, andré a écrit :
> > > >J'ai un serveur postfix + dovecot + ssl.
> > > >Il marche parfaitement avec le port POP 110,
> > > >mais pas du tout en mode SSL port 995.
> > > >Voici ce que me dit "tail /var/log/mail.err" :
> > > >dovecot: pop3-login: Error: SSL: Stacked error:
> > error:140760FC:SSL 
> > > >routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> > > >Mes certifs crt et key semblent bons.
> > > >J'en ai créés d'autres mais idem.
> > > >J'ai fouillé via Google, ce message m'apporte des centaines
> > > >de liens mais aucun ne m'aide.
> > > >Merci d'une piste...  André

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

J'ai fait un test avec le serveur SMTP de gmail :
openssl s_client -connect smtp.gmail.com:995 -debug
et ç a fonctionné. Il y aura une quantité importante d'informations, y
compris des dumps d'échanges entre le serveur et le client; l'argument
-debug est probablement exagéré pour l'instant. 
Ce qui est intéressant avec cette commande est qu'une fois la liaison
chiffrée établie, vous aurez l'équivalent d'un telnet sur une liaison
"en clair", vous permettant de tester manuellement votre serveur.
En ce qui concerne la désactivation de SSLv3 TLSv1.0 et TLSv1.1, j'ai
trouvé cecihttp://www.postfix.org/announcements/postfix-2.9.2.htmlhttps
://www.skyminds.net/serveur-dedie-configurer-postfix-et-courier-pour-
utiliser-tls-ssl-en-perfect-forward-secrecy/
Attention : le second lien date de 2014 et ne déconseille pas TLS 1.0
et 1.1, il faut adapter les exemples. Je garde ces liens pour mes
propres notes, car j'ai moi aussi dégrossi postfix + dovecot il y a
quelques temps. J'ai encore mes notes de brouillon d'ailleurs, que je
pourrais ressortir pour l'occasion :).
La raison de cette restriction est d'empêcher un client un peu trop
vieux de se connecter en négociant un protocole de chiffrement devenu
vulnérable, par incapacité à utiliser un protocole encore fiable. Cela
dit, c'est un peu hors du sujet. Je pense qu'il faut garder cela pour
la touche finale du chiffrement. La openssl s_client aidera de nouveau,
pour vérifier l'échec de connection avec des protocoles bannis.
Le dimanche 26 mars 2017 à 20:38 +0200, andre_deb...@numericable.fr a
écrit :
> On Sunday 26 March 2017 19:58:05 Thierry Bugier Pineau wrote:
> 
> Merci de me répondre.
> 
> > Essayez de diagnostiquer avec openssl
> > openssl s_client -connect serveur.org -debug :
> 
> La commande me renvoie sur le help de openssl...
> 
> > Plus de détail ici à propos de la commande; car il vous faudra peut
> être 
> ajouter quelques arguments selon votre cas :
> > https://wiki.openssl.org/index.php/Manual:S_client(1) :
> 
> Pas trop d'infos pour la syntaxe de la commande proposée... :-)
> 
> > En passant, veillez à bien interdire sslv3 et tls < 1.2 côté
> serveur :
> 
> Comment interdire sslv3 ?
> Sinon, j'ai adopté TLS (STARTTLS) et idem, comment interdire  tls <
> 1.2 ?
> 
> Merci,
> 
> André
>  
> > Le 26 mars 2017 19:45:28 GMT+02:00, andre_deb...@numericable.fr a
> écrit :
> > >J'ai un serveur postfix + dovecot + ssl.
> > >Il marche parfaitement avec le port POP 110,
> > >mais pas du tout en mode SSL port 995.
> > >Voici ce que me dit "tail /var/log/mail.err" :
> > >dovecot: pop3-login: Error: SSL: Stacked error:
> error:140760FC:SSL 
> > >routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> > >Mes certifs crt et key semblent bons.
> > >J'en ai créés d'autres mais idem.
> > >J'ai fouillé via Google, ce message m'apporte des centaines
> > >de liens mais aucun ne m'aide.
> > >Merci d'une piste...  André
> > 
> 
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Sunday 26 March 2017 19:58:05 Thierry Bugier Pineau wrote:

Merci de me répondre.

> Essayez de diagnostiquer avec openssl
> openssl s_client -connect serveur.org -debug :

La commande me renvoie sur le help de openssl...

> Plus de détail ici à propos de la commande; car il vous faudra peut être 
ajouter quelques arguments selon votre cas :
> https://wiki.openssl.org/index.php/Manual:S_client(1) :

Pas trop d'infos pour la syntaxe de la commande proposée... :-)

> En passant, veillez à bien interdire sslv3 et tls < 1.2 côté serveur :

Comment interdire sslv3 ?
Sinon, j'ai adopté TLS (STARTTLS) et idem, comment interdire  tls < 1.2 ?

Merci,

André
 
> Le 26 mars 2017 19:45:28 GMT+02:00, andre_deb...@numericable.fr a écrit :
> >J'ai un serveur postfix + dovecot + ssl.
> >Il marche parfaitement avec le port POP 110,
> >mais pas du tout en mode SSL port 995.
> >Voici ce que me dit "tail /var/log/mail.err" :
> >dovecot: pop3-login: Error: SSL: Stacked error: error:140760FC:SSL 
> >routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> >Mes certifs crt et key semblent bons.
> >J'en ai créés d'autres mais idem.
> >J'ai fouillé via Google, ce message m'apporte des centaines
> >de liens mais aucun ne m'aide.
> >Merci d'une piste...  André
> 

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[Thierry Bugier Pineau]

Bonjour

Essayez de diagnostiquer avec openssl

openssl s_client -connect serveur.org -debug

Plus de détail ici à propos de la commande; car il vous faudra peut être 
ajouter quelques arguments selon votre cas :
https://wiki.openssl.org/index.php/Manual:S_client(1)

En passant, veillez à bien interdire sslv3 et tls < 1.2 côté serveur.

Le 26 mars 2017 19:45:28 GMT+02:00, andre_deb...@numericable.fr a écrit :
>Encore moi, désolé :-)
>
>J'ai un serveur postfix + dovecot + ssl.
>
>Il marche parfaitement avec le port POP 110,
>mais pas du tout en mode SSL port 995.
>
>Voici ce que me dit "tail /var/log/mail.err" :
>dovecot: pop3-login: Error: SSL: Stacked error: error:140760FC:SSL 
>routines:SSL23_GET_CLIENT_HELLO:unknown protocol
>
>Mes certifs crt et key semblent bons.
>J'en ai créés d'autres mais idem.
>
>J'ai fouillé via Google, ce message m'apporte des centaines
>de liens mais aucun ne m'aide.
>
>Merci d'une piste...
>
>André

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Postfix Problema consulta

[Epsilon Minus]

>
> On Tuesday 14 February 2017 15:30:17 Epsilon Minus wrote:
>> El día 14 de febrero de 2017, 15:13, Matias Mucciolo
>>  escribió:
>> >
>> > respondo arriba asi no se mezcla tanto..
>> >
>> > por eso te pido algun log.
>> > porque a donde probate enviar con el telnet??
>> >
>> > si probastes con:
>> > sender = u...@cualquierdominio.tld
>> > rcpt to = u...@tudominio.tld
>>
>>
>> Probe así. sin usar ninguna contraseña desde un equipo fuera de las
>> redes conocidas por mi servidor de postfix
>>
>> > siempre te va a dejar pasar el correo.
>> > fijate que te sale con ese openrelay test
>> > y avisanos.
>>
>>
>>
>> El Test de Openrelay que hice dio excelente. "All tested completed! No
>> relays accepted by remote host!"
>>
>>
>>
>> > para mi que algun spamer tiene alguna user/pass
>> > y lo esta usando para mandar correos.
>>
>> Acá diste con el clavo a ver si se comprende. Me deja enviar sin usar
>> user/pass desde cualquier origen.   Quiero restringir el uso sin
>> usuario y contraseña (y no se porque paso esto, antes no dejaba enviar
>> si no validaba usuario y contraseña)
>>
>> PD. Voy  a hacerte caso con el lo de HOLD para no manchar la IP.
>>
>> Gracias Matias
>>
>
> si el test te dio ok entonces quiere decir que esta ok no esta ABIERTO(open 
> relay).
> Es obvio que tenes que fijarte que usuario estan usando para enviar correos
> y cambiarle la clave urgentemente. y en muchas ocasiones bloquear la ip
> del spammer..que deben ser varias ips...i
>
>
>
> ahora por otro lado es obvio que si el mensaje ES de CUALQUIER dominio
> y VA para tu dominio lo deja pasar sin auth...
> imaginate que si te envio un mail a tu dominio no tengo que autentificar
> con un user de tu dominio.(que no tengo)..
>
> ahora SI el mail va PARA un dominio FUERA(relay) de tu correo ejemplo
> un correo a u...@gmail.com si DEBERIA autentificar con un usuario/clave.
> sino seria open relay.
>
> en tu caso es un robo de contraseña o por bruta fuerza..
> que es bastante normal que pase...
> Como te dije enfocate en buscar que user usan para enviar spam
> y cambiale la pass.
>
> algo asi deberias ver:
> AC65A4CECD17: client=unknown[190.172.xx.xx], sasl_method=PLAIN, 
> sasl_username=u...@domain.tld


Muchas Gracias! la verdad que no encontraba por donde podía venir el
problema hasta esta explicación. Voy a rastrear esto a ver si lo
encuentro.

Como lo herede tengo todos los logs mezclados el cyrus y el postfix me
tiran los mails en el mismo archivo, tengo que cambiar eso primero.


> tambien hay forma de que un user solo pueda enviar mails desde su casilla.
> es decir si el user es us...@domain.tld no pueda usar el FROM: 
> cualqui...@cualquiera.tld
> cuando tengas tiempo mira esta doc:
>
> http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch

Paso esta pequeña tormenta y leo lo que me pasaste.

> saludos.
> Matias.-

Gracias!

Re: Postfix Problema consulta

[Matias Mucciolo]

On Tuesday 14 February 2017 15:30:17 Epsilon Minus wrote:
> El día 14 de febrero de 2017, 15:13, Matias Mucciolo
>  escribió:
> >
> > respondo arriba asi no se mezcla tanto..
> >
> > por eso te pido algun log.
> > porque a donde probate enviar con el telnet??
> >
> > si probastes con:
> > sender = u...@cualquierdominio.tld
> > rcpt to = u...@tudominio.tld
> 
> 
> Probe así. sin usar ninguna contraseña desde un equipo fuera de las
> redes conocidas por mi servidor de postfix
> 
> > siempre te va a dejar pasar el correo.
> > fijate que te sale con ese openrelay test
> > y avisanos.
> 
> 
> 
> El Test de Openrelay que hice dio excelente. "All tested completed! No
> relays accepted by remote host!"
> 
> 
> 
> > para mi que algun spamer tiene alguna user/pass
> > y lo esta usando para mandar correos.
> 
> Acá diste con el clavo a ver si se comprende. Me deja enviar sin usar
> user/pass desde cualquier origen.   Quiero restringir el uso sin
> usuario y contraseña (y no se porque paso esto, antes no dejaba enviar
> si no validaba usuario y contraseña)
> 
> PD. Voy  a hacerte caso con el lo de HOLD para no manchar la IP.
> 
> Gracias Matias
> 

si el test te dio ok entonces quiere decir que esta ok no esta ABIERTO(open 
relay).
Es obvio que tenes que fijarte que usuario estan usando para enviar correos
y cambiarle la clave urgentemente. y en muchas ocasiones bloquear la ip
del spammer..que deben ser varias ips...i



ahora por otro lado es obvio que si el mensaje ES de CUALQUIER dominio
y VA para tu dominio lo deja pasar sin auth...
imaginate que si te envio un mail a tu dominio no tengo que autentificar
con un user de tu dominio.(que no tengo)..

ahora SI el mail va PARA un dominio FUERA(relay) de tu correo ejemplo
un correo a u...@gmail.com si DEBERIA autentificar con un usuario/clave.
sino seria open relay.

en tu caso es un robo de contraseña o por bruta fuerza..
que es bastante normal que pase...
Como te dije enfocate en buscar que user usan para enviar spam
y cambiale la pass.

algo asi deberias ver:
AC65A4CECD17: client=unknown[190.172.xx.xx], sasl_method=PLAIN, 
sasl_username=u...@domain.tld

tambien hay forma de que un user solo pueda enviar mails desde su casilla.
es decir si el user es us...@domain.tld no pueda usar el FROM: 
cualqui...@cualquiera.tld
cuando tengas tiempo mira esta doc:

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

saludos.
Matias.-

Re: Postfix Problema consulta

[Epsilon Minus]

El día 14 de febrero de 2017, 15:13, Matias Mucciolo
 escribió:
>
> respondo arriba asi no se mezcla tanto..
>
> por eso te pido algun log.
> porque a donde probate enviar con el telnet??
>
> si probastes con:
> sender = u...@cualquierdominio.tld
> rcpt to = u...@tudominio.tld


Probe así. sin usar ninguna contraseña desde un equipo fuera de las
redes conocidas por mi servidor de postfix

> siempre te va a dejar pasar el correo.
> fijate que te sale con ese openrelay test
> y avisanos.



El Test de Openrelay que hice dio excelente. "All tested completed! No
relays accepted by remote host!"



> para mi que algun spamer tiene alguna user/pass
> y lo esta usando para mandar correos.

Acá diste con el clavo a ver si se comprende. Me deja enviar sin usar
user/pass desde cualquier origen.   Quiero restringir el uso sin
usuario y contraseña (y no se porque paso esto, antes no dejaba enviar
si no validaba usuario y contraseña)

PD. Voy  a hacerte caso con el lo de HOLD para no manchar la IP.

Gracias Matias


> Matias
>
> On Tuesday 14 February 2017 15:09:54 Epsilon Minus wrote:
>> Gracias Matias por responder.
>>
>> Ahora mismo estoy probando lo de openrelay.
>>
>> Con el comando qshape me mostraba 72000 mails en espera. otros miles
>> en deferred.  El problema que hago un telnet desde internet al
>> servidor y puedo simular enviar desde cualquier mail desde dominios
>> que ni son propios, sin necesidad de autenticación. Esto último es lo
>> que me parece más grave. ¿Como puedo restringir estas conexiones?
>>
>> 2017-02-14 15:01 GMT-03:00 Matias Mucciolo :
>> >
>> > On Tuesday 14 February 2017 14:46:49 Epsilon Minus wrote:
>> >> Estimados,
>> >>
>> >> Consulta de la nada un servidor de mail que herede y me tocá
>> >> admnistrar empezo a permirtir la validación desde fuera por telnet sin
>> >> autenticar. Cualquiera puede enviar mails.  No se donde rastrear el
>> >> problema.
>> >>
>> >> ¿Como puede dejar que solo se validen con usuario y este deshabilitado
>> >> para el envio sin validación de usuario? Nunca administre mucho
>> >> postfix y me encontre con este problema medio urgente.
>> >>
>> >> Si alguno me puede dar una mano estaría eternamente agradecido, este
>> >> es el contenido de mi main.cf :
>> >>
>> >>
>> >> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>> >> biff = no
>> >> append_dot_mydomain = no
>> >>
>> >> mydomain = midominio.com
>> >>
>> >> smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
>> >> smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
>> >> smtpd_use_tls=yes
>> >> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>> >> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>> >>
>> >> myhostname = midominio.com
>> >> alias_maps = hash:/etc/aliases
>> >> alias_database = hash:/etc/aliases
>> >> myorigin = /etc/mailname
>> >>
>> >> mydestination = dominiosdemimailserver
>> >>
>> >> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1] 192.168.1.1/32
>> >> mailbox_command = procmail -a "$EXTENSION"
>> >> mailbox_size_limit = 0
>> >> recipient_delimiter = +
>> >> inet_interfaces = all
>> >>
>> >> mailbox_transport = lmtp:unix:/local/socket/lmtp
>> >>
>> >> smtpd_sasl_auth_enable=yes
>> >> smtp_sasl_security_options=noanonymous, noactive
>> >> broken_sasl_auth_clients=yes
>> >> smtpd_sasl_local_domain=
>> >>
>> >> transport_maps = hash:/etc/postfix/transport
>> >>
>> >> smtpd_recipient_restrictions = permit_sasl_authenticated,
>> >> reject_unauth_destination, reject_unknown_sender_domain
>> >>
>> >> debug_peer_level=9
>> >>
>> >> # Amavis
>> >> content_filter=smtp-amavis:[127.0.0.1]:10024
>> >>
>> >> #soft_bounce = yes
>> >> receive_override_options = no_address_mappings
>> >
>> > Buenas
>> >
>> > a simple vista y sin probarlo se ve bien la config.
>> > (al menos la parte que pasaste)
>> > podes pastear logs y demas de lo que ves mal ?
>> >
>> > probaste con alguna web de pruebas ejemplo
>> > http://www.mailradar.com/openrelay/
>> >
>> > o como probaste? con tu dominio como destino ?
>> >
>> > saludos.
>> > Matias
>> >
>> >
>> >
>> >
>>
>

Re: Postfix Problema consulta

[Matias Mucciolo]

Ah y lo mejor que podes hacer en estos momentos es poner toda
la cola del correo en HOLD

ejemplo:
postsuper -h ALL

eso pone todos los mails en hold
asi no los envia..seguro que algun mail
legitimo también te quede en hold
pero es mejor que caer en alguna lista negra
por spam y que se te ensucie la ip.

despeus limpias la cola y si quedo algun en hold
haces un release con -H


Matias

On Tuesday 14 February 2017 15:13:42 Matias Mucciolo wrote:
> 
> respondo arriba asi no se mezcla tanto..
> 
> por eso te pido algun log.
> porque a donde probate enviar con el telnet??
> 
> si probastes con: 
> sender = u...@cualquierdominio.tld
> rcpt to = u...@tudominio.tld
> 
> siempre te va a dejar pasar el correo.
> fijate que te sale con ese openrelay test
> y avisanos.
> 
> para mi que algun spamer tiene alguna user/pass
> y lo esta usando para mandar correos.
> 
> Matias
> 
> On Tuesday 14 February 2017 15:09:54 Epsilon Minus wrote:
> > Gracias Matias por responder.
> > 
> > Ahora mismo estoy probando lo de openrelay.
> > 
> > Con el comando qshape me mostraba 72000 mails en espera. otros miles
> > en deferred.  El problema que hago un telnet desde internet al
> > servidor y puedo simular enviar desde cualquier mail desde dominios
> > que ni son propios, sin necesidad de autenticación. Esto último es lo
> > que me parece más grave. ¿Como puedo restringir estas conexiones?
> > 
> > 2017-02-14 15:01 GMT-03:00 Matias Mucciolo :
> > >
> > > On Tuesday 14 February 2017 14:46:49 Epsilon Minus wrote:
> > >> Estimados,
> > >>
> > >> Consulta de la nada un servidor de mail que herede y me tocá
> > >> admnistrar empezo a permirtir la validación desde fuera por telnet sin
> > >> autenticar. Cualquiera puede enviar mails.  No se donde rastrear el
> > >> problema.
> > >>
> > >> ¿Como puede dejar que solo se validen con usuario y este deshabilitado
> > >> para el envio sin validación de usuario? Nunca administre mucho
> > >> postfix y me encontre con este problema medio urgente.
> > >>
> > >> Si alguno me puede dar una mano estaría eternamente agradecido, este
> > >> es el contenido de mi main.cf :
> > >>
> > >>
> > >> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> > >> biff = no
> > >> append_dot_mydomain = no
> > >>
> > >> mydomain = midominio.com
> > >>
> > >> smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
> > >> smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
> > >> smtpd_use_tls=yes
> > >> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> > >> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> > >>
> > >> myhostname = midominio.com
> > >> alias_maps = hash:/etc/aliases
> > >> alias_database = hash:/etc/aliases
> > >> myorigin = /etc/mailname
> > >>
> > >> mydestination = dominiosdemimailserver
> > >>
> > >> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1] 192.168.1.1/32
> > >> mailbox_command = procmail -a "$EXTENSION"
> > >> mailbox_size_limit = 0
> > >> recipient_delimiter = +
> > >> inet_interfaces = all
> > >>
> > >> mailbox_transport = lmtp:unix:/local/socket/lmtp
> > >>
> > >> smtpd_sasl_auth_enable=yes
> > >> smtp_sasl_security_options=noanonymous, noactive
> > >> broken_sasl_auth_clients=yes
> > >> smtpd_sasl_local_domain=
> > >>
> > >> transport_maps = hash:/etc/postfix/transport
> > >>
> > >> smtpd_recipient_restrictions = permit_sasl_authenticated,
> > >> reject_unauth_destination, reject_unknown_sender_domain
> > >>
> > >> debug_peer_level=9
> > >>
> > >> # Amavis
> > >> content_filter=smtp-amavis:[127.0.0.1]:10024
> > >>
> > >> #soft_bounce = yes
> > >> receive_override_options = no_address_mappings
> > >
> > > Buenas
> > >
> > > a simple vista y sin probarlo se ve bien la config.
> > > (al menos la parte que pasaste)
> > > podes pastear logs y demas de lo que ves mal ?
> > >
> > > probaste con alguna web de pruebas ejemplo
> > > http://www.mailradar.com/openrelay/
> > >
> > > o como probaste? con tu dominio como destino ?
> > >
> > > saludos.
> > > Matias
> > >
> > >
> > >
> > >
> > 
>