Postfix with IPV6 error "bind :: port 25: Can't assign requested address"

[Sam]

Hello!

I have a server running FreeBSD 8.1 with FreeBSD 8.1 jails running on it. I 
have 
ipv6 running on both the main server and jails and that is all fine.

I'm running into a strange problem when it comes to postfix though and was 
wondering if anyone has any clues. What's happening is that postfix will not 
start automatically when the jail is started when 'inet_protocols' is set to 
either 'all' or 'ipv4, ipv6'. The error in the logs is: fatal: bind :: port 25: 
Can't assign requested address.

The odd thing is that I can enter the jail right away and start postfix from 
the 
command line and it works fine. Also, if I specify the '-D' flag in rc.conf and 
set the debug command in main.cf to 'sleep 3' then postfix will start 
automatically when the jail is started.

I've also tried setting 'inet_interfaces = loopback-only' in main.cf which 
gives 
the following error in the log:
fatal: /usr/local/etc/postfix/master.cf: line 22: no valid IP address found: 
smtp

And setting '127.0.0.1:smtp ...' in master.cf works but then postfix only 
listens on ipv4:
tcp4   0  0 jailhost.ssh   *.*LISTEN
tcp6   0  0 jailhost.ssh   *.*LISTEN
tcp46  0  0 *.http *.*LISTEN
tcp4   0  0 jailhost.smtp  *.*LISTEN

Setting '[::1]:smtp ...' in master.cf does not work. This is the error in the 
mail log:
fatal: bind :: port 25: Can't assign requested address

I've read through the postfix manual, looked around online and tried many 
different settings but nothing works (besides that hack of running with the -D 
flag). I'd super appreciate any help or any ideas anyone may have. If more info 
is needed please let me know and I will post. Below is the output of 'postconf -
n'

Thank you for your time and help!


command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = scan:blocker:10025
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = /usr/local/share/doc/postfix
inet_protocols = ipv4, ipv6
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
myhostname = example.com
mynetworks_style = host
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
receive_override_options = no_address_mappings
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_client_restrictions = permit_sasl_authenticated,  permit_mynetworks,  
reject_rbl_client sbl.spamhaus.org
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,   
permit_mynetworks,  reject_non_fqdn_recipient,  
reject_unlisted_recipient,   reject_unauth_destination,  
reject_unknown_recipient_domain,check_policy_service inet:blocker:10031
smtpd_sender_restrictions = permit_sasl_authenticated,  permit_mynetworks,  
reject_non_fqdn_sender, reject_rbl_client sbl.spamhaus.org,  
reject_unknown_sender_domain
soft_bounce = no
unknown_local_recipient_reject_code = 550

Re: Postfix with IPV6 error "bind :: port 25: Can't assign requested address"

[Sam]

Wietse Venema  porcupine.org> writes:

> 
> Sam:
> > Hello!
> > 
> > I have a server running FreeBSD 8.1 with FreeBSD 8.1 jails running on it. I 
have 
> > ipv6 running on both the main server and jails and that is all fine.
> > 
> > I'm running into a strange problem when it comes to postfix though and was 
> > wondering if anyone has any clues. What's happening is that postfix will 
> > not 
> > start automatically when the jail is started when 'inet_protocols' is set 
> > to 
> > either 'all' or 'ipv4, ipv6'. The error in the logs is: fatal: bind :: port 
25: 
> > Can't assign requested address.
> 
> Translation: the attempt to bind to "::" port 25 failed, because
> the jail network interface does not have an IPv6 address.
> 
> This means that Postfix is started before the network address is
> configured on the jail interface.

That's interesting, I was wondering about that but it looked to me that the 
network was started before the other daemons. I will ask on the FreeBSD mailing 
lists like you suggested.

My question though is why does it start fine when only ipv4 is used but not 
when 
ipv6 is used either by it's self or with ipv4?


> > The odd thing is that I can enter the jail right away and start
> > postfix from the command line and it works fine. Also, if I specify
> > the '-D' flag in rc.conf and set the debug command in main.cf to
> > 'sleep 3' then postfix will start automatically when the jail is
> > started.
> 
> You have a race condition where Postfix is started before the jail
> network interface is fully initialized. 
> 
> The workaround is to insert some delay before Postfix starts.

I guess this is why starting it with 'sleep 3' allowed postfix to start 
automatically.

> The solution is to file a bug report with FreeBSD. The /etc/rc.d
> scripts must not start network daemons before the network is ready.

See my question above about postfix starting fine when only ipv4 is used. Also, 
apache and sshd start fine and they start at the same time postfix does if I'm 
not mistaken. I'm no expert though so I'm probably missing something somewhere.

I will contact FreeBSD about this though. Thanks for the suggestion.

>   Wietse

Thanks Wietse, I appreciate your time and help.

-Sam

Re: Postfix with IPV6 error

[Sam]

Wietse Venema  porcupine.org> writes:
> It makes perfect sense: the IPv4 address is assigned FIRST
> and the IPv6 address is assigned LAST.
> 
> If you want to find out why a FreeBSD jail network interface
> behaves the way it does, then that would be an excellent
> question for a FreeBSD mailing list.
> 
> I don't think that waiting for three seconds makes a
> fundamental difference in how Postfix works, or how
> FreeBSD system calls work.

No, it doesn't, it's just not a very elegant solution but at least it works
for now.

I'll take this over to the FreeBSD discussions. Thank you very much for your
help and pointing me in the right direction.

Re: Configuring null-mail machine

[sam]

On Sat, Sep 17, 2011 at 8:48 PM, tmac  wrote:
> I Have RHEL6 and am trying to use postfix for the first time.
>
> My host is server1.lab.my.org
>
> The mail server is mailserver.my.org
>
> I also have an alias file being passed around via NIS. This is used
> with sendmail to re-write usernames from u...@lab.my.org or
> just user to u...@my.org
>
> I would like to have this single host (server1) running postfix
> send/forward all mailto the mailserver (mailserver.my.org).
> I would also like it to re-write the user names with the NIS
> aliases file. If the user does not exist in NIS, append my.org to
> the email address.
>
> I have a setup working now, as long as I specify u...@my.org.
> Anything else does not work (i.e. user or u...@lab.my.org)
>
> Thanks!
> --tmac
>

Hi,

I think you need to setup DNS accordingly.
Put the MX record for the corresponding domain in the forward zone.






-- 
Best Regards,
Suresh Kumar Prajapati
Linux Security Admin
E-mail: er.sureshprajap...@gmail.com

Theory is when you know all and nothing works. Practice is when all
works and nobody knows why. In this case we have put together theory
and practice: nothing works... and nobody knows why!

Is pure SSL/TLS termination viable with postfix?

[Sam]

Hello everyone


I would like to run postfix in a docker container, and receive emails 
through HaProxy with SSL termination. So the setup I would like to 
achieve is:


Web -> My Server -> HaProxy (SSL/TLS decryption) -> Into my server (as 
localhost with zero encryption) -> docker container with postfix 
handling the email (also dovecot, but that's irrelevant here)


Is that even possible? Please excuse my ignorance, because I run setups 
usually by researching online and I'm not an expert, and the one I 
currently have working is on bare-metal and works just fine, but it's 
causing me issues on migration and down times, while I'm hoping docker 
statelessness can help with that.


But why TLS termination at HaProxy specifically? Because the plan is to 
only keep HaProxy with root access on bare-metal (and access to 
certificates as root), while it wires all connections to internal ports. 
This worked so far on everything except for postfix (and dovecot) due to 
setup complexity and inability to see any logs from postfix (postfix 
does log things like invalid configuration when started with start-fg, 
but nothing else).


Currently, after disabling all TLS stuff in main.cf file (all smtpd tls 
configs, including smtpd_tls_security_level, smtpd_tls_auth_only and 
smtpd_use_tls), I only can telnet to port 587 (25 and 465 are 
non-responsive), and I'm still required to provide STARTTLS command when 
testing.


Is there a way to achieve the SSL/TLS termination I'm hoping to do? How 
can I get postfix to forget about TLS and just work without any of it?


Best regards,
Sam

Re: Is pure SSL/TLS termination viable with postfix?

[Sam]

Dear Viktor, dear readers

Thank you very much for your quick reply and insight. I went ahead and 
disabled wrapper mode in master.cf (and there's no wrapper mode in 
main.cf), and I still can't telnet to port 465, even though it's in use 
in the container. When I try to do that, the connection is closed 
immediately (44465 forwards to docker's 465):


telnet localhost 44465
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

This is what smtps looks like in master.cf

smtps  inet  n   -   y   -   -   smtpd
    -o smtpd_tls_wrappermode=no

Are there other things to be enabled to allow this? How can I debug 
this? postfix still doesn't print anything except when I do wrong 
config, even though I attempted to enable debug printing at level 3 for 
address 0.0.0.0/0.


On the other topic:

You've provided advice on security and I'd really appreciate it 
expanding on that a little bit. First, no, haproxy doesn't provide 
STARTTLS support, so it will be supporting only raw encryption for tcp 
packets, which seems to be equivalent to "wrapper mode". So all network 
packets will be encrypted. This is also extremely tempting for me 
because I can centrally control encryption properties without touching 
anything from the inside (like allowing specific ciphers, disabling 
specific encryption protocols, etc), which I may need to do once every 
few years without digging back into every different application. 
Management is not error-prone like when handling many different 
encryption configurations on the server.


With that in mind (and given also that I don't fully understand SASL, so 
I may be missing something), why should postfix know about the security 
properties of the connection? Why should it care? What kind of problem 
are we trying to solve here? Because if all network packets going in and 
out of the server are encrypted with haproxy, I guess, mission 
accomplished, right? My plan is to pass port 465 straight to haproxy, 
then haproxy does the encryption in and out. Ports 587 and 25 won't even 
be exposed. I only need one port. What kind of scenario are we trying to 
prevent?


Can you please also elaborate on the fragile security boundaries on 
docker? Typically my bare-metals are fully firewalled (and even docker 
port bindings are only on localhost). So the only access to postfix will 
be through the port we allow (which seems to be 465). The user from the 
outside won't notice the difference, but my hope is that this will make 
migrations much easier, because I don't have time to keep doing this 
again and again every time there's a potential security threat or some 
kind of machine failure (which require me to migrate with minimal 
effort, which happened recently, and I'm a software engineer running my 
own little infrastructure with limited resources). What am I missing in 
this plan?


Thank you again.

Best regards,
Sam



On 08/12/2022 1:30 AM, Viktor Dukhovni wrote:

On Wed, Dec 07, 2022 at 11:51:32PM +0400, Sam wrote:


I would like to run postfix in a docker container, and receive emails
through HaProxy with SSL termination. So the setup I would like to
achieve is:

It is generally preferrable to let Postfix do TLS-termination, so that
Postfix can be aware of the connection security properties, and e.g.
not offer SASL for cleartext connections.

Also, does "haproxy" support doing STARTTLS?  On port 587 TLS does not
start at the beginning of the connection, but instead negotiated after
EHLO.  I am not sure how haproxy handles that.


Is that even possible?

Yes.  Postfix supports cleartext SMTP.  You'd have disable wrapper-mode
TLS on port 465, disable STARTTLS on port 587, and not require TLS for
submission or SASL.


But why TLS termination at HaProxy specifically? Because the plan is to
only keep HaProxy with root access on bare-metal (and access to
certificates as root), while it wires all connections to internal ports.

I think you're optimising for the wrong security properties.
Containerised Postfix relies on much more fragile security boundaries
than Postfix running in a full VM.

I would not recommend this design.

Verbose logging issues of postfix in docker container

[Sam]

  
  
Dear experts in postfix:


I've been having different kinds of issues in postfix when moving
  my email server into docker containers (which I know some don't
  recommend, but please tolerate that as I have trade-offs to make).
  In my test setup where I'm experimenting, I copied all the
  configuration I already have in bare-metal into the container (and
  changed some of it, like paths, and used lmtp instead of lda),
  copied some test emails in there, and launched separate containers
  for postfix, dovecot, opendkim and mariadb. In previous email to
  this email list I was trying to do haproxy SSL/TLS termination,
  but I gave that up (for now) because I also failed at debugging
  what's going on for the same reason I'm writing this email: 



**I really can't debug any smtp issues whatsoever.**


My postfix container is based on Debian 11, where I install
  postfix with apt and then launch `postfix start-fg`. 



Btw, networking to containers is bridges automatically created by
  docker-compose. Most communication is done with inet, and some are
  done with unix-socket files across containers (most of which I
  plan to change to inet later, ... one step at a time), in case
  someone is wondering.



When I launch my containers with docker-compose, I can see logs
  from dovecot and mariadb. I see logs of postfix ONLY if some
  configuration is incorrect. It can say things like "this
  configuration line isn't used", and so on. But nothing during
  operation whatsoever. The directory /var/log/ in the container has
  nothing in it related to postfix. There's literally zero logging
  all in all.


To test my setup, I tunnel with ssh to my server, and then use a
  fresh Thunderbird installation on the same test computer to add
  127.0.0.1 as email server (which passes through the tunnel to my
  server). The initial authentication works fine for both IMAP and
  SMTP. Also downloading emails with dovecot works fine. But sending
  emails with postfix always fails with the error: "The mail server
  responded: : Temporary lookup failure.
  Please check the message recipient "u...@example.com" and try
  again.


I'm happy to pursue the error myself, but all my attempts to log
  any useful information has failed. I added in main.cf the lines
  (and I use wildcard for all IPv4 addresses because this is all a
  test setup before this becomes serious):


debug_peer_list=0.0.0.0/0    
  debug_peer_level=6



and in master.cf, I added `-v` flag on smtpd. Nothing comes out
  of it. Zero logging to both stdout and /var/log/.



When attempting to send an email (which fails like I mentioned),
  I can see the process of smtpd launched with the command (using ps
  -ax):


postfix 1457  1.5  0.0  44652 10632 ?    S    23:24  
  0:00 smtpd -n submission -t inet -u -o stress= -v -o
  smtpd_tls_security_level=encrypt -o smtpd_enforce_tls=yes -o
  smtpd_sasl_auth_enable=yes -o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject



and I tried moving that `-v` around to the end of everything...
  no use. I can't get a single line of actions logged. Why? What am
  missing? How can I get postfix to tell me what's going on step by
  step in its failure?


Thank you and best regards,
Sam

  

Re: Verbose logging issues of postfix in docker container

[Sam]

  
  
Thank you very much, guys. Actually Charles' comment made me
  realize this. I found a post on serverfault specifying how to run
  a postfix in foreground, and I added that line with maillog_file =
  /dev/stdout and I'm starting to see things now when I send and
  email. 



Thank you very much, guys. Have a great day!


Cheers,
Sam





On 12/12/2022 5:37 AM,
  mailm...@ionos.gr wrote:


  
Docker containers don't log like normal linux distos do with syslog/rsyslog/syslog-ng/etc. They expect the main process to output all logging to STDOUT, this is recorded as "log" output by the docker daemon.

You may need to set the "maillog_file" postfix config option to "/dev/stdout", thus redirect all logging to STDOUT for docker to read.

This is my first post to this mailing list, so hi!



On Mon, 12 Dec 2022 04:11:06 +0400 Sam  wrote:


  
Dear experts in postfix:


I've been having different kinds of issues in postfix when moving my email server into docker containers (which I know some don't recommend, but please tolerate that as I have trade-offs to make). In my test setup where I'm experimenting, I copied all the configuration I already have in bare-metal into the container (and changed some of it, like paths, and used lmtp instead of lda), copied some test emails in there, and launched separate containers for postfix, dovecot, opendkim and mariadb. In previous email to this email list I was trying to do haproxy SSL/TLS termination, but I gave that up (for now) because I also failed at debugging what's going on for the same reason I'm writing this email:


**I really can't debug any smtp issues whatsoever.**


My postfix container is based on Debian 11, where I install postfix with apt and then launch `postfix start-fg`.


Btw, networking to containers is bridges automatically created by docker-compose. Most communication is done with inet, and some are done with unix-socket files across containers (most of which I plan to change to inet later, ... one step at a time), in case someone is wondering.


When I launch my containers with docker-compose, I can see logs from dovecot and mariadb. I see logs of postfix ONLY if some configuration is incorrect. It can say things like "this configuration line isn't used", and so on. But nothing during operation whatsoever. The directory /var/log/ in the container has nothing in it related to postfix. There's literally zero logging all in all.


To test my setup, I tunnel with ssh to my server, and then use a fresh Thunderbird installation on the same test computer to add 127.0.0.1 as email server (which passes through the tunnel to my server). The initial authentication works fine for both IMAP and SMTP. Also downloading emails with dovecot works fine. But sending emails with postfix always fails with the error: "The mail server responded: : Temporary lookup failure. Please check the message recipient "u...@example.com" and try again.


I'm happy to pursue the error myself, but all my attempts to log any useful information has failed. I added in main.cf the lines (and I use wildcard for all IPv4 addresses because this is all a test setup before this becomes serious):


debug_peer_list=0.0.0.0/0    
debug_peer_level=6


and in master.cf, I added `-v` flag on smtpd. Nothing comes out of it. Zero logging to both stdout and /var/log/.


When attempting to send an email (which fails like I mentioned), I can see the process of smtpd launched with the command (using ps -ax):


postfix 1457  1.5  0.0  44652 10632 ?    S    23:24   0:00 smtpd -n submission -t inet -u -o stress= -v -o smtpd_tls_security_level=encrypt -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject


and I tried moving that `-v` around to the end of everything... no use. I can't get a single line of actions logged. Why? What am missing? How can I get postfix to tell me what's going on step by step in its failure?


Thank you and best regards,

Sam

  

  

What are the consequences of disabling chroot in all master services?

[Sam]

  
  
Dear postfix experts:


While setting up postfix in a docker container, I have been
  getting the error "fatal: unknown service: smtp/tcp" when
  attempting to send an email. I investigated the issue, and it
  seems it has something to do with setting up chroot inside of
  docker container


https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg



The easiest solution to this problem was to just disable chroot,
  which worked fine. I'm considering disabling chroot for all the
  postfix master services. Is this a bad move considering that
  postfix is running in a docker container? I would appreciate your
  insight into this.


Best regards,
Sam


  

Re: What are the consequences of disabling chroot in all master services?

[Sam]

I apologize for the email being html-only, not my intention. I'm having 
trouble getting Thunderbird to do this right as I have to manually do 
this for every outgoing email.


Can you please elaborate on what you mean with "problems of their own"? 
Anything specific comes to mind?


This whole movement to docker is a big set of trade-offs that I'm still 
researching.


Best regards,
Sam


On 13/12/2022 3:17 AM, Wietse Venema wrote:

Sam:
[ text/html is unsupported, treating like TEXT/PLAIN ]


?html style="direction: ltr;"?
   ?head?

 ?meta http-equiv="content-type" content="text/html; charset=UTF-8"?
 ?style id="bidiui-paragraph-margins" type="text/css"?body p { 
margin-bottom: 0cm; margin-top: 0pt; } ?/style?
   ?/head?
   ?body bidimailui-charset-is-forced="true" style="direction: ltr;"?
 ?p?Dear postfix experts:?/p?
 ?p??br?
 ?/p?
 ?p?While setting up postfix in a docker container, I have been
   getting the error "fatal: unknown service: smtp/tcp" when
   attempting to send an email. I investigated the issue, and it
   seems it has something to do with setting up chroot inside of
   docker container?/p?
 ?p??br?
 ?/p?
 ?p??a class="moz-txt-link-freetext" 
href="https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg"?https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg?/a??br?
 ?/p?
 ?p??br?
 ?/p?
 ?p?The easiest solution to this problem was to just disable chroot,
   which worked fine. I'm considering disabling chroot for all the
   postfix master services. Is this a bad move considering that
   postfix is running in a docker container? I would appreciate your
   insight into this.?/p?

The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.

One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.

By the way it is rude to post html-only email to a mailing list.

Wietse

mynetworks_style -> subnet within containers

[Sam]

Hello postfix experts:


So today I finished my initial setup of docker with different containers 
running different email services. There's a container for postfix, one 
for dovecot, one for fetchmail, one for postfixadmin, etc.



The networking is basically bridged from every container to the outside. 
In fact, I didn't set this manually, as docker-compose automatically 
creates a network for all its components. The binding is strictly with 
localhost. The outside world accesses the containers through tcp 
forwarding with HAProxy, which binds to the required ports in the 
containers (143, 587, etc). The command `docker ps` shows the bindings 
for postfix:



127.0.0.1:3725->25/tcp, 127.0.0.1:37465->465/tcp, 127.0.0.1:37587->587/tcp


In order to give other containers easy access to postfix (like 
fetchmail, for example, to deliver fetched emails), I chose the setting:



mynetworks_style = subnet


The rationale behind this is that (in my head, and that's why I'm asking 
here since I'm no expert), is that everything in the subnet, i.e., the 
containers, should consider each other "mynetwork". Does that make sense?



Within the postfix container, this is what ifconfig returns:


```

# ifconfig -a
eth0: flags=4163  mtu 1500
    inet 172.30.0.3  netmask 255.255.0.0  broadcast 172.30.255.255
    ether 02:42:ac:1e:00:03  txqueuelen 0  (Ethernet)
    RX packets 434  bytes 57106 (55.7 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 427  bytes 133987 (130.8 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 72  bytes 6173 (6.0 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 72  bytes 6173 (6.0 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

```


Other containers seem to share the same subnet with that subnet mask.


Please let me know whether I'm reasoning correctly about this and 
whether it's right to choose that setting (and, also, whether I missed 
something in my setup, if obvious).



Best regards,

Sam

Re: mynetworks_style -> subnet within containers

[Sam]

Thank you for the response.


One of the reasons for me asking this question is that I'm not fully 
sure about the consequences of that. Another one is that the 
documentation of postfix specifies that this can be dangerous if 
connected to wide-area network, which quite frankly I'm not sure about 
given the setup I described, given that the proxy gives that kind of 
exposure. I would appreciate your insight into whether I'm doing 
something wrong with the decisions I made.



Best regards,

Sam


On 14/12/2022 3:18 PM, Wietse Venema wrote:

mynetworks_style applies to local interface addresses, not proxied
ones.

Wietse

Re: mynetworks_style -> subnet within containers

[Sam]

Thank you for your answer.


HAProxy is on the same machine. As you see in the bindings I shared that 
are created by docker-compose, docker exposed ports are only allowed to 
connect to localhost (127.0.0.1), which is why HAProxy can connect to it.



I gather that as long as HAProxy doesn't propagate its own view of the 
network, then postfix in a docker container within a docker-compose 
subnet will only see the internal subnet of the containers around it and 
will never see anything from the outside as mynetworks. Meaning, I have 
nothing to worry about. I hope I got this right.



Cheers,

Sam


On 14/12/2022 8:44 PM, Wietse Venema wrote:

On 14/12/2022 3:18 PM, Wietse Venema wrote:

mynetworks_style applies to local interface addresses, not proxied
ones.

Sam:

Thank you for the response.

One of the reasons for me asking this question is that I'm not fully
sure about the consequences of that.

If a future version of HAProxy propagates interface netmasks, then
we can revisit that in Postfix. Before that happens, Postfix does
not know remote subnet information.


Another one is that the documentation of postfix specifies that
this can be dangerous if connected to wide-area network, which
quite frankly I'm not sure about given the setup I described, given
that the proxy gives that kind of exposure. I would appreciate
your insight into whether I'm doing something wrong with the
decisions I made.

Depending on where Postfix is deployed, the subnet of a local WAN
interface may include IP addresses of other customers of the network
provider. This is why it is not safe to include those IP addresses
by default in the mynetworks setting.

Wietse

nmap says there's vulnerability with Diffie-Hellman settings

[Sam]

Hello everyone

when I run `nmap --script vuln example.com` against a server I manage, I 
get the following vulnerability on my server on both ports 465 and 587. 
The only solutions I found are for legacy systems.



587/tcp   open   submission
| ssl-dh-params:
|   VULNERABLE:
|   Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
|   Transport Layer Security (TLS) services that use anonymous
|   Diffie-Hellman key exchange only provide protection against passive
|   eavesdropping, and are vulnerable to active man-in-the-middle 
attacks

|   which could completely compromise the confidentiality and integrity
|   of any data exchanged over the resulting session.
| Check results:
|   ANONYMOUS DH GROUP 1
| Cipher Suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: Unknown/Custom-generated
| Modulus Length: 2048
| Generator Length: 8
| Public Key Length: 2048
| References:
|_  https://www.ietf.org/rfc/rfc2246.txt



My settings (slightly redacted):

```
$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
maillog_file = /dev/stdout
message_size_limit = 0
milter_default_action = accept
milter_protocol = 2
mydestination = localhost
myhostname = example.com
mynetworks_style = subnet
myorigin = localmail.example.com
non_smtpd_milters = inet:email-opendkim:12301
postscreen_upstream_proxy_protocol = haproxy
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps 
$virtual_mailbox_domains $relay_recipient_maps $relay_domains 
$canonical_maps $sender_canonical_maps $recipient_canonical_maps 
$relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps

readme_directory = no
recipient_delimiter = +
relay_domains =
relayhost =
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = reject_rbl_client dnsbl.sorbs.net
smtpd_helo_restrictions = reject_invalid_helo_hostname,
smtpd_milters = inet:email-opendkim:12301
smtpd_recipient_restrictions = check_sender_access 
hash:/etc/postfix/sender_access, permit_sasl_authenticated, 
permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, 
reject_unknown_recipient_domain, reject_unauth_destination, 
reject_rbl_client sbl.spamhaus.org, reject_rbl_client 
b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, 
reject_rbl_client truncate.gbudb.net, reject_rbl_client bl.spamcop.net, 
reject_rbl_client cbl.abuseat.org, permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination

smtpd_sasl_authenticated_header = yes
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = 
proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf

smtpd_tls_auth_only = yes
smtpd_tls_cert_file = fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = ultra
smtpd_tls_key_file = privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_security_level = may
```

Let me know what you think.

All the best,
Sam

Re: nmap says there's vulnerability with Diffie-Hellman settings

[Sam]

Thank you for explaining. I'm sorry I'm not sure whether I understand 
that there's a solution or it's OK. Is there a setting that I can update 
in postfix to fix this? I already limited smtpd ciphers to high, with 
smtpd_tls_ciphers.


Is there something I can do to fix this "vulnerability"?

PS: Matus asked about the "outdated" solution, here it's: 
https://www.clearos.com/clearfoundation/social/community/did-an-external-nmap-script-vuln-scan-and-found-a-few-issues-relating-to-ssl-fixes 
; none of these options seem to apply in postfix somehow, and then from 
a previous discussion I learned that many TLS_* options were deprecated. 
Besides, I saw in postfix documentation that DH options should be loaded 
automatically from OpenSSL and not be specified (IIRC).


Best regards,
Sam


On 07/01/2023 6:38 PM, Wietse Venema wrote:

Wietse Venema:

Sam:

Hello everyone

when I run `nmap --script vuln example.com` against a server I manage, I
get the following vulnerability on my server on both ports 465 and 587.
The only solutions I found are for legacy systems.


587/tcp   open   submission
| ssl-dh-params:
|   VULNERABLE:
|   Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
|   Transport Layer Security (TLS) services that use anonymous
|   Diffie-Hellman key exchange only provide protection against passive

Yes, anonymous ciphers do not authenticate. That is a feature, not
a bug. PKI alone cannot authenticate an SMTP server, that requires
DANE with DNSSEC.

Correction: mail to port 465 and 587 currently uses A/ lookups,
and in those cases an SMTP server actually can be authenticated
with PKI alone. So turning off anonymous ciphers for ports 465 and
587 can make sense.

That would change when Postfix looks up submission SMTP servers
using SRV support. Where MX lookup returns a hostname, SRV lookup
returns a host and port. Host lookups with MX or SRV are insecure
without DNSSEC validation.

Wietse

Re: nmap says there's vulnerability with Diffie-Hellman settings

[Sam]

Thank you, guys. I appreciate it. Have a great day.



On 07/01/2023 9:23 PM, Viktor Dukhovni wrote:

On Sat, Jan 07, 2023 at 12:38:06PM +0400, Sam wrote:


when I run `nmap --script vuln example.com` against a server I manage, I
get the following vulnerability on my server on both ports 465 and 587.
The only solutions I found are for legacy systems.

The "nmap" report is wasting your time.  Support for anon-DH in
*servers* is not a feature, not a bug.  If the *client* actually
authenticates the server, the *client* will not support anon-DH ciphers,
and they will not be negotiated.  If the client does not authenticate
the server, pretending that hiding anon-DH ciphers creates
authentication is magical thinking.

 https://www.rfc-editor.org/rfc/rfc7672#section-8.2


| State: VULNERABLE
|   Transport Layer Security (TLS) services that use anonymous
|   Diffie-Hellman key exchange only provide protection against passive
|   eavesdropping, and are vulnerable to active man-in-the-middle attacks
|   which could completely compromise the confidentiality and integrity
|   of any data exchanged over the resulting session.

The server is NOT vulnerable.  *Clients* that don't authenticate the server
are vulnerable to MITM, whether or not anon-DH ciphers are negotiated.

Ignore overzealous security scan reports.  They are trying to look more
thorough by finding as much as possible, whether a real issue or not.

On Sat, Jan 07, 2023 at 06:53:38PM +0400, Sam wrote:

Thank you for explaining. I'm sorry I'm not sure whether I understand
that there's a solution or it's OK. Is there a setting that I can update
in postfix to fix this? I already limited smtpd ciphers to high, with
smtpd_tls_ciphers.

Is there something I can do to fix this "vulnerability"?

Do nothing.  Your server is fine.

On Sat, Jan 07, 2023 at 05:26:57PM +0100, Matus UHLAR - fantomas wrote:


use smtpd_tls_mandatory_exclude_ciphers instead of smtpd_tls_exclude_ciphers
for ports 465/587 as *_mandatory_* options apply on ports where tls is
mandatory

Nothing needs to be done.

 http://www.postfix.org/TLS_README.html#client_tls_limits
 ...
 Consequently, TLS security for mail delivery to public MX hosts is
 almost entirely the client's responsibility. The server is largely
 a passive enabler of TLS security, the rest is up to the client.
 While the server has a greater opportunity to mandate client
 security policy when it is a dedicated MSA that only handles
 outbound mail from trusted clients, below we focus on the client
 security policy.

Re: nmap says there's vulnerability with Diffie-Hellman settings

[Sam]

Hi Eero. I'm using the default settings in postfix. In fact, you can 
look in my settings you'll find `smtpd_tls_eecdh_grade = ultra`. That's 
the only DH related thing AFAIK.



On 07/01/2023 1:53 PM, Eero Volotinen wrote:

I think you are using insecure dh group 1?

Eero

la 7. tammik. 2023 klo 10.39 Sam (lis...@afach.de) kirjoitti:

Hello everyone

when I run `nmap --script vuln example.com <http://example.com>`
against a server I manage, I
get the following vulnerability on my server on both ports 465 and
587.
The only solutions I found are for legacy systems.


587/tcp   open   submission
| ssl-dh-params:
|   VULNERABLE:
|   Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
|   Transport Layer Security (TLS) services that use anonymous
|   Diffie-Hellman key exchange only provide protection
against passive
|   eavesdropping, and are vulnerable to active man-in-the-middle
attacks
|   which could completely compromise the confidentiality and
integrity
|   of any data exchanged over the resulting session.
| Check results:
|   ANONYMOUS DH GROUP 1
| Cipher Suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: Unknown/Custom-generated
| Modulus Length: 2048
| Generator Length: 8
| Public Key Length: 2048
| References:
|_ https://www.ietf.org/rfc/rfc2246.txt



My settings (slightly redacted):

```
$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
maillog_file = /dev/stdout
message_size_limit = 0
milter_default_action = accept
milter_protocol = 2
mydestination = localhost
myhostname = example.com <http://example.com>
mynetworks_style = subnet
myorigin = localmail.example.com <http://localmail.example.com>
non_smtpd_milters = inet:email-opendkim:12301
postscreen_upstream_proxy_protocol = haproxy
proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
$virtual_mailbox_domains $relay_recipient_maps $relay_domains
$canonical_maps $sender_canonical_maps $recipient_canonical_maps
$relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps
readme_directory = no
recipient_delimiter = +
relay_domains =
relayhost =
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = reject_rbl_client dnsbl.sorbs.net
<http://dnsbl.sorbs.net>
smtpd_helo_restrictions = reject_invalid_helo_hostname,
smtpd_milters = inet:email-opendkim:12301
smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/sender_access, permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination,
reject_invalid_hostname,
reject_unknown_recipient_domain, reject_unauth_destination,
reject_rbl_client sbl.spamhaus.org <http://sbl.spamhaus.org>,
reject_rbl_client
b.barracudacentral.org <http://b.barracudacentral.org>,
reject_rbl_client zen.spamhaus.org <http://zen.spamhaus.org>,
reject_rbl_client truncate.gbudb.net <http://truncate.gbudb.net>,
reject_rbl_client bl.spamcop.net <http://bl.spamcop.net>,
reject_rbl_client cbl.abuseat.org <http://cbl.abuseat.org>, permit
smtpd_relay_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
smtpd_sasl_authenticated_header = yes
smtpd_sasl_type = dovecot
smtpd_sender_login_maps =
proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
<http://mysql_sender_login_maps.cf>
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = ultra
smtpd_tls_key_file = privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_security_level = may
```

Let me know what you think.

All the best,
Sam

Re: postscreen_upstream_proxy_protocol and smtpd_upstream_proxy_protocol

[Sam]

It's practically not possible to support both with and without haproxy 
within postfix within one connection. The reason is that postfix 
receives plain bytes with the TCP protocol. The interpretation of these 
bytes can only be done by defining the protocol underneath. When you set 
the protocol to use the haproxy proxy protocol, you basically tell 
postfix to expect a binary header of a specific format (defined by 
haproxy), which contains the source information and other things. I 
guess this is why your proposition is kind of silly, in a way, because 
it's kind of impossible to do with a modern protocol (proxy protocol) 
combined with a protocol that has been there for like 40 years (smtp 
protocol). Though I understand why you'd misunderstand it under "wishful 
thinking". It would be nice.


Now with regards to your problem, the solution is easy. First, let's 
establish that you using haproxy on the postfix interface basically 
means that port 25 isn't usable anymore. The protocol is all different. 
No MTA will be able to talk to this port. So, first step: Don't use port 
25 directly. Online you'll find examples using port 10024. Up to you.


Now, your email server has port 10024 used for haproxy, for connections 
coming from server online (and I assume you're doing this because you 
want to maintain some SPF and MX record correctness on some public 
server you're proxying through). But then the solution writes itself: 
Connection coming from the "outside" should go to port 10024 (or 
whatever you choose) in your local server through haproxy to be 
"deproxied", per se. On the other hand, you get postfix to bind to port 
25 normally, So postfix now maintains two ports for MTAs, 25 for the 
smtpd service, and 10024 for postscreen, which will handle the proxy for 
you. To have extra assurance, I think you can set client_restrictions on 
port 25 to come only from your local subnet, so that no one can reach it 
from the outside no matter what. Not sure how to do that, I guess the 
postfix experts here can suggest a better way. Though this is an extra 
precaution that most likely isn't necessary, since your router's 
NAT/firewall will protect from connecting to port 25 from the outside, 
but being paranoid, you can restrict it at the postfix level too. Up to you.


Best regards,

Sam


On 15/01/2023 6:59 PM, Gerben Wierda wrote:

On 15 Jan 2023, at 15:47, Wietse Venema  wrote:

"The name of the proxy protocol used by a before-postscreen proxy agent."


That still doesn't tell you what the effect is of entering a value for 
that setting while the traffic is not coming from a proxy. Normally, 
when you enter config data for something you do not use it is 
harmless. Basically, here, by setting the name here, you are also 
turning it on. That is for me at least intuitively a side-effect.


Basically, I am looking for a setup where I can have postfix work when 
part of the traffic (from the internet) is coming via a proxy whereas 
local (LAN) traffic isn't. Probably not an option, I guess, but it 
would make life a lot easier in my current situation.


G

Re: Wietse: Old Mirrors on postfix.org/download.html

[Sam]

Hi Wietse

Can you add this into mirrors list?

http://mirrors.standaloneinstaller.com/postfix/ (France)


On 3/6/2017 7:54 PM, Matthew McGehrin wrote:


Wietse,

There are several old mirrors with bad links that don't work on the 
postfix download page and needs to be updated.


404 Not Found  
http://mirrors-usa.go-parts.com/postfix/source/index.html USA, MI, 
Lansing 
404 Not Found  
http://mirrors.xservers.ro/postfix-release/index.html Romania, 
Bucharest 
404 Not Found  
http://postfix.psshee.com/pub/index.html South Korea, Seoul 

-1 Timeout  
http://postfix.poldownload.com/postfix/postfix-source/index.html Iran, 
Tehran 
-1 Timeout  
http://mirror.tje.me.uk/pub/mirrors/postfix-release/index.html UK, 
London 



Several of the FTP sites are down as well, including cloud9.

ftp://postfix.cloud9.net/index.html
ftp://ftp.its.cz/MIRRORS/ftp.porcupine.org/mirrors/postfix-release/index.html 


ftp://ftp.ucr.ac.cr/pub/Unix/mail/postfix/postfix-release/index.html
ftp://ftp.sunet.se/pub/unix/mail/postfix/index.html
ftp://ftp.is.co.za/networking/mail/mta/postfix/index.html
ftp://postfix.mirrors.pair.com/postfix-release/index.html

Thank You.

Bounced mails

[Sam Przyswa]

Hi,

Is it possible to accept and send in a default mail adddress all the 
mail rejected for User unknown ?


Thanks for your help.

Sam.

Re: Bounced mails

[Sam Przyswa]

/dev/rob0 a écrit :

On Fri, Mar 12, 2010 at 12:47:45AM +0100, Sam Przyswa wrote:
  

Is it possible to accept and send in a default mail adddress all the
mail rejected for User unknown ?



Commonly referred to as a "catchall address", this is a bad idea. It 
*will* be abused by spammers, and it must be monitored to be sure 
that small typoes do not cause lost mail.
  


Yes sure but we have antispam running (blacklists, postfix-policyd, 
spamassassin)



For local(8) delivery, see:
http://www.postfix.org/postconf.5.html#luser_relay
For other address classes, the table lookup key is "@domain" as per:
http://www.postfix.org/virtual.5.html
http://www.postfix.org/postconf.5.html#relay_recipient_maps
http://www.postfix.org/postconf.5.html#virtual_mailbox_maps
  


Thanks fotr your help.

Sam.

--
Sam Przyswa - Chef de projet
Email: s...@arial-concept.com
Arial Concept - Intégrateur Internet
36, rue de Turin - 75008 - Paris - France
Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01
Fax privé: 09 57 12 27 22
Skype ID: arial-concept
Web: http://www.arial-concept.com

Mails bounced 550 5.7.1

[Sam Przyswa]

Hi,

On last Postfix install on new server some mails are refused with error 
550 5.7.1 se the report :



: host gw.aflo.be[87.66.26.108] said: 550 5.7.1 Your email
   messages have been blocked by the recipient OR by Trend Micro Email
   Reputation Service. Contact the recipient or his/her administrator using
   alternate means to resolve the issue. (in reply to RCPT TO command)


How to fix ?

Thanks for your help.

Sam.

Re: Mails bounced 550 5.7.1

[Sam Przyswa]

The problem occur when we send mail to this domain, we had no problems 
before we changed our IP mail server and MX record for our domain.


Sam.


Martijn de Munnik - Postfix List a écrit :

On Fri, 19 Mar 2010 15:06:42 +0100, Sam Przyswa 
wrote:
  

Hi,

On last Postfix install on new server some mails are refused with error 
550 5.7.1 se the report :



Are these mails entering your system or are these mails leaving your
system? If the mails are leaving your system then the remote site has
decided not to accept your e-mail.

  


: host gw.aflo.be[87.66.26.108] said: 550 5.7.1 Your
email
messages have been blocked by the recipient OR by Trend Micro Email
Reputation Service. Contact the recipient or his/her administrator
using
alternate means to resolve the issue. (in reply to RCPT TO command)


How to fix ?

Thanks for your help.

Sam.



--
Sam Przyswa - Chef de projet
Email: s...@arial-concept.com
Arial Concept - Intégrateur Internet
36, rue de Turin - 75008 - Paris - France
Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01
Fax privé: 09 57 12 27 22
Skype ID: arial-concept
Web: http://www.arial-concept.com

Re: Mails bounced 550 5.7.1

[Sam Przyswa]

I'm sorry but since I install Postfix (a lot of years) it's the first 
time I have this problem, (blacklisted in Backscatter.org, SORBS-SPAM) 
and I would like to know why !


Actually the server is a mail relay for a Zimbra server (www.zimbra.com) 
on two Vservers on the same host. I don't find any explanation on why 
our IP is listed on Backscatter.org, on the website the request page 
notify this note:


---
This IP is temporary listed.
The listing will expire automatically and free of charge 4 weeks after 
the last abuse is seen from that IP.
Expedited manual express delisting is available as an option, in case 
you do not want to wait for the automatic and free expiration.

You will be charged 50 Euro's using one of the following payment services.
---

It's not an ABUSE !!!

But what should be the origin of the problem and what is the quick fix ?

Thanks in advance.

Sam.


Martijn de Munnik - Postfix List a écrit :

On Fri, 19 Mar 2010 15:31:18 +0100, Sam Przyswa 
wrote:
  
The problem occur when we send mail to this domain, we had no problems 
before we changed our IP mail server and MX record for our domain.



Your mailserver seems to be listed on several blacklists, please fix those
problems first.

Backscatter.org
SORBS-SPAM
UCEPROTECTL2

maybe others...
  

Sam.


Martijn de Munnik - Postfix List a écrit :


On Fri, 19 Mar 2010 15:06:42 +0100, Sam Przyswa
  


  

wrote:
  
  

Hi,

On last Postfix install on new server some mails are refused with

error 
  

550 5.7.1 se the report :



Are these mails entering your system or are these mails leaving your
system? If the mails are leaving your system then the remote site has
decided not to accept your e-mail.

  
  


: host gw.aflo.be[87.66.26.108] said: 550 5.7.1 Your
email
messages have been blocked by the recipient OR by Trend Micro


Email
  

Reputation Service. Contact the recipient or his/her administrator
using
alternate means to resolve the issue. (in reply to RCPT TO


command)
  



How to fix ?

Thanks for your help.

Sam.

Mail routing problem

[Sam Przyswa]

Hi,

I have to build a mail system with one main server (main) who send mails 
to several secondaries servers on the net as serv1, serv2, servX, for 
the same domain but how to send mail from the serv1 to an user on the 
serv2 for the same domain without got the "user unknown" reply on serv1 
and force to send it to main who know where to send it.


Thanks in advance for your help.

Sam.

--
Sam Przyswa - Chef de projet
Email: s...@arial-concept.com
Arial Concept - Intégrateur Internet
36, rue de Turin - 75008 - Paris - France
Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01
Fax privé: 09 57 12 27 22
Skype ID: arial-concept
Web: http://www.arial-concept.com 

Dispatching mail on severals servers

[Sam Przyswa]

Hi,

I have to dispatch mail for a domain my_domain.com to severals servers. 
All mail addresses are on the form u...@my_domain.com but users are 
dispatched on different hosts (host1, host2, etc) All mails are received 
on a main mail server and I have to send it to the right host where the 
user is.


Then when user1 on the host1 want send a mail to user2 on host2 user1 
send the mail to us...@my_domain.com. How to set the system on host1 to 
route the mail on main mail server instead of "user unknown" message ?


What is the best setup to do that ?

Thanks for your help.

Sam.

Re: Dispatching mail on severals servers

[Sam Przyswa]

Wietse Venema a écrit :

  Sam Przyswa:
  
  
Hi,

I have to dispatch mail for a domain my_domain.com to severals servers. 
All mail addresses are on the form u...@my_domain.com but users are 
dispatched on different hosts (host1, host2, etc) All mails are received 
on a main mail server and I have to send it to the right host where the 
user is.

Then when user1 on the host1 want send a mail to user2 on host2 user1 
send the mail to us...@my_domain.com. How to set the system on host1 to 
route the mail on main mail server instead of "user unknown" message ?

What is the best setup to do that ?

  
  
On both the MX machines and on the user machines, use virtual
aliases to route mail to the right mail server.

us...@example.com	us...@host.provider.example

Virtual aliasing does not change To: or From: headers.

The aliases can be shared across the network with replicated *SQL,
LDAP etc. I don't think it's a good idea to try to SHARE hash/btree
files with NFS (read/write by a only one NFS client should be OK).
  


Hmm, I will explore this point...

Thanks for your help.

Sam.

Mail to non system account

[Sam Wootton]

Hi,

I nearly have Postfix working on Opensuse 11.1.

For a non system account user, it works.  For example:

/var/mail/vhosts/samwootton.com/bruno

gets populated with incoming mail.  However, when i try to do the same for a
system account user, it never reaches that message store.

It was going in to /var/spool/mail/useraccount but i commented out:

mail_spool_directory

in mail.cf.  Here are the rest of my settings:

*inet_interfaces = $myhostname, localhost*
> *mydestination = $myhostname*
> *virtual_mailbox_maps = hash:/etc/postfix/vmailmaps*
> *local_recipient_maps = $virtual_mailbox_maps*
> *local_transport = virtual*
> *mynetworks_style = host*
> *virtual_mailbox_domains = samwootton.com*
> *virtual_mailbox_base = /var/mail/vhosts*
>


I have commented out 'mailbox_transport' completely.

Here is my vmailmaps:

s...@samwootton.com samwootton.com/sam

Could anyone help me fix this problem?  Just to clarify, i can get non
system account mail being delivered, but not a system account.

I'm guessing it is still using the default delivery agent for that on system
account?  A delivery agent that looks inside /etc/passwd and /etc/aliases
files?

Thanks for any help.

Regards, Sam

-- 
s...@samwootton.com

Re: Mail to non system account

[Sam Wootton]

2009/11/22 Magnus Bäck 

> On Sunday, November 22, 2009 at 17:34 CET,
>      Sam Wootton  wrote:
>
> > I nearly have Postfix working on Opensuse 11.1.
> >
> > For a non system account user, it works.  For example:
> >
> > /var/mail/vhosts/samwootton.com/bruno
> >
> > gets populated with incoming mail.  However, when i try to do the same
> > for a system account user, it never reaches that message store.
>
> Is it the same domain? Show logs.
>
> > It was going in to /var/spool/mail/useraccount but i commented out:
> >
> > mail_spool_directory
> >
> > in mail.cf.
>
> Doing so was most likely useless.
>
> > Here are the rest of my settings:
>
> Next time, post "postconf -n" output instead.
>
> > *inet_interfaces = $myhostname, localhost*
> > > *mydestination = $myhostname*
> > > *virtual_mailbox_maps = hash:/etc/postfix/vmailmaps*
> > > *local_recipient_maps = $virtual_mailbox_maps*
> > > *local_transport = virtual*
> > > *mynetworks_style = host*
> > > *virtual_mailbox_domains = samwootton.com*
> > > *virtual_mailbox_base = /var/mail/vhosts*
>
> The cause of your problems may very well be that you're messing with
> local_recipient_maps and local_transport in this manner. There are very
> few occasions where such a configuration makes any sense, and this is
> most likely not one of them. You need to read up on address classes.
>
> List local domains in mydestination.
> List virtual mailbox domains in virtual_mailbox_domains.
> List virtual alias domains in virtual_alias_domains.
> List relay domains in relay_domains.
>
> Unless you have a single domain that contains users in two or more of
> these address classes, getting the above right is all it takes.
>
> > I have commented out 'mailbox_transport' completely.
>
> That doesn't make any difference as you're not using local(8) at all.
>
> > Here is my vmailmaps:
> >
> > s...@samwootton.com samwootton.com/sam
> >
> > Could anyone help me fix this problem?  Just to clarify, i can get non
> > system account mail being delivered, but not a system account.
> >
> > I'm guessing it is still using the default delivery agent for that on
> > system account?  A delivery agent that looks inside /etc/passwd and
> > /etc/aliases files?
>
> Until you show us logs we can only guess. Throw in full "postconf -n"
> output while you're at it.
>
> --
> Magnus Bäck
> mag...@dsek.lth.se
>

Hi,

Thank you for your quick response - apologies for my slow response.

I have a single domain that has 2 categories of user (a unix holding account
user, and a non-unix account user).

I didn't think my set-up was that odd.  After all, in main.cf, it states:

"You need to update the local_recipient_maps setting if:
>
>  - You define $mydestination domain recipients in files other than
>/etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
>For example, you define $mydestination domain recipients in
>the $virtual_mailbox_maps files."
>

So i assumed that:

*local_recipient_maps = $virtual_mailbox_maps*

was ok.  About address classes.  I don't think i need to alter the
transport.db, and therefore am unsure about where to define address classes
and what the vlaue should be.

Here is my postconf output:

biff = no
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
defer_transports =
delay_warning_time = 1h
disable_dns_lookups = no
disable_mime_output_conversion = no
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = $myhostname, localhost
inet_protocols = all
local_recipient_maps = $virtual_mailbox_maps
local_transport = virtual
mail_owner = postfix
mailbox_command =
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains =
masquerade_exceptions = root
message_size_limit = 1024
message_strip_characters = \0
mydestination = $myhostname
myhostname = samwootton.com
mynetworks_style = host
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relay_domains = $mydestination
relayhost =
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_sasl_auth_enable = no
smtp_use_tls = no
smtpd_client_rest

Re: Mail to non system account

[Sam Wootton]

2009/11/23 tobi 

> Sam Wootton schrieb:
> > 2009/11/22 Magnus Bäck 
> >
> >
> >> On Sunday, November 22, 2009 at 17:34 CET,
> >>  Sam Wootton  wrote:
> >>
> >>
> >>> I nearly have Postfix working on Opensuse 11.1.
> >>>
> >>> For a non system account user, it works.  For example:
> >>>
> >>> /var/mail/vhosts/samwootton.com/bruno
> >>>
> >>> gets populated with incoming mail.  However, when i try to do the same
> >>> for a system account user, it never reaches that message store.
> >>>
> >> Is it the same domain? Show logs.
> >>
> >>
> >>> It was going in to /var/spool/mail/useraccount but i commented out:
> >>>
> >>> mail_spool_directory
> >>>
> >>> in mail.cf.
> >>>
> >> Doing so was most likely useless.
> >>
> >>
> >>> Here are the rest of my settings:
> >>>
> >> Next time, post "postconf -n" output instead.
> >>
> >>
> >>> *inet_interfaces = $myhostname, localhost*
> >>>
> >>>> *mydestination = $myhostname*
> >>>> *virtual_mailbox_maps = hash:/etc/postfix/vmailmaps*
> >>>> *local_recipient_maps = $virtual_mailbox_maps*
> >>>> *local_transport = virtual*
> >>>> *mynetworks_style = host*
> >>>> *virtual_mailbox_domains = samwootton.com*
> >>>> *virtual_mailbox_base = /var/mail/vhosts*
> >>>>
> >> The cause of your problems may very well be that you're messing with
> >> local_recipient_maps and local_transport in this manner. There are very
> >> few occasions where such a configuration makes any sense, and this is
> >> most likely not one of them. You need to read up on address classes.
> >>
> >> List local domains in mydestination.
> >> List virtual mailbox domains in virtual_mailbox_domains.
> >> List virtual alias domains in virtual_alias_domains.
> >> List relay domains in relay_domains.
> >>
> >> Unless you have a single domain that contains users in two or more of
> >> these address classes, getting the above right is all it takes.
> >>
> >>
> >>> I have commented out 'mailbox_transport' completely.
> >>>
> >> That doesn't make any difference as you're not using local(8) at all.
> >>
> >>
> >>> Here is my vmailmaps:
> >>>
> >>> s...@samwootton.com samwootton.com/sam
> >>>
> >>> Could anyone help me fix this problem?  Just to clarify, i can get non
> >>> system account mail being delivered, but not a system account.
> >>>
> >>> I'm guessing it is still using the default delivery agent for that on
> >>> system account?  A delivery agent that looks inside /etc/passwd and
> >>> /etc/aliases files?
> >>>
> >> Until you show us logs we can only guess. Throw in full "postconf -n"
> >> output while you're at it.
> >>
> >> --
> >> Magnus Bäck
> >> mag...@dsek.lth.se
> >>
> >>
> >
> > Hi,
> >
> > Thank you for your quick response - apologies for my slow response.
> >
> > I have a single domain that has 2 categories of user (a unix holding
> account
> > user, and a non-unix account user).
> >
> > I didn't think my set-up was that odd.  After all, in main.cf, it
> states:
> >
> > "You need to update the local_recipient_maps setting if:
> >
> >>  - You define $mydestination domain recipients in files other than
> >>/etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
> >>For example, you define $mydestination domain recipients in
> >>the $virtual_mailbox_maps files."
> >>
> >>
> >
> > So i assumed that:
> >
> > *local_recipient_maps = $virtual_mailbox_maps*
> >
> > was ok.  About address classes.  I don't think i need to alter the
> > transport.db, and therefore am unsure about where to define address
> classes
> > and what the vlaue should be.
> >
> > Here is my postconf output:
> >
> > biff = no
> > canonical_maps = hash:/etc/postfix/canonical
> > command_directory = /usr/sbin
> > config_directory = /etc/postfix
> > daemon_directory = /usr/lib/postfix
> > data_directory = /var/lib/postfix
> > debug_peer_level = 2
> >

RrDNS-v-PTR

[Sam Jones]

Good Afternoon,

My senior tech and I have been having a squabble over PTR, Hostnames and
reverse mapping.

If you have a client connect from 1.2.3.4 and perform a host name lookup
on that, so you get back host.example.com, would it impact on mail if a
forward query for host.example.com returned multiple A records, say
1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
round robin?

I ask because we've seen an slightly odd pattern to some deferrals with
a host where this happens and wonder if they may be using:

 reject_unknown_client_hostname feature, which requires not only
that the address->name and name->address mappings exist, but
also that the two mappings reproduce the client IP address. 
The unknown_client_reject_code parameter specifies the response
code for rejected requests (default: 450). The reply is always
450 in case the address->name lookup failed due to a temporary
    problem. 

Sam

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 10:31 -0500, Stan Hoeppner wrote:
> On 4/3/2012 9:56 AM, Sam Jones wrote:
> > Good Afternoon,
> > 
> > My senior tech and I have been having a squabble over PTR, Hostnames and
> > reverse mapping.
> > 
> > If you have a client connect from 1.2.3.4 and perform a host name lookup
> > on that, so you get back host.example.com, would it impact on mail if a
> > forward query for host.example.com returned multiple A records, say
> > 1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
> > round robin?
> 
> It's possible, but the devil is in the details, which you did not
> provide to us.
It really was just a general question as to how an MTA, specifically
Postfix, would respond if multiple alternating A records were returned
in respect of a forward DNS request for a PTR/Hostname connection
return.

If you don't know, that's fine - just say so. You don't need to let
yourself down with the old flame:

> 
> This was included in your list welcome message.
> http://www.postfix.org/DEBUG_README.html#mail

> Please read it and post the relevant information it instructs you to.
> In this case, at minimum, we need to see the SMTP responses from the
> remote MTA.
> 
Because I actually had gone through that, which is why I was able to
find the configuration value that could impact in such a scneario.

I do apologise for the distress, offence and disturbance my rude stupid
question has obviously caused you. I won't repeat it and I hope you can
forgive me.

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 10:36 -0500, /dev/rob0 wrote:
> > 
> > If you have a client connect from 1.2.3.4 and perform a host name
> > lookup on that, so you get back host.example.com, would it impact
> > on mail if a forward query for host.example.com returned multiple
> > A records, say 1.2.3.4 & 5.6.7.8 alternating between the top of
> > the result sets in a round robin?
> 
> Multiple A records for a particular PTR value should not be a 
> problem. The order in which those records are returned cannot be 
> relied upon. If 192.0.2.22 connects to smtpd(8), and:
> 
> 22.2.0.192.in-addr.arpa.  PTR host.example.com.
> host.example.com. A   192.0.2.2
> host.example.com. A   192.0.2.22
> host.example.com. A   192.0.2.222
> 
> Postfix would log the connection as host.example.com[192.0.2.22]. 
> "unknown[192.0.2.22]" is logged if:
> 
> 1. 22.2.0.192.in-addr.arpa./PTR returns no value (including NXDOMAIN, 
>SERVFAIL, and NOERROR)
> 2. Lookup of the 22.2.0.192.in-addr.arpa./PTR value does not return
>an A record with 192.0.2.22 as value.
> 
Thank you rob0, that clears it up nicely. Basically, as I understand it,
if the connecting IP appears in a list of multiple A records for the
host, it won't break.

I may have lost a Pizza, but I've gained useful knowledge.

Kind thanks for your polite and very helpful reply. It is really
appreciated.

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 11:53 -0400, Wietse Venema wrote:
> With Postfix, multiple IP address per A record are fine, as long
> as the CLIENT IP address is listed among them.
> 
> However, having multiple PTR records for one IP address, that is a
> different matter. Postfix will not try to guess which name it should
> use. It just takes the first name that comes up, and requires that
> that name resolves to the client IP address. 
Thank you. That is valuable knowledge. Much appreciated.

Re: RrDNS-v-PTR

[Sam Jones]

> > I do apologise for the distress, offence and disturbance my rude stupid
> > question has obviously caused you. I won't repeat it and I hope you can
> > forgive me.
> 
> Re-reading what I wrote, and reading your reply, leaves me at a bit of a
> loss as to what prompted this immature drivel.  My reply was totally
> professional, if dry and somewhat canned.  But how such would prompt a
> reply like this escapes me.  Maybe you're just having a bad day?
> 
I really don't want to start a war. I'm old, tired and underpaid, but
you were rude, and quite unnecessarily so. You don't seem to be able to
help it, because when I was perfectly polite to you - if a touch
sarcastic in return to your 'dry and canned' response, you then went on
to describe it as 'immature drivel' - which, I'm sure you would agree,
is somewhat unprofessional and quite hypocritical.

I'm sorry you did not know the answer, but the question has now been
addressed very professionally by polite, skilled people - to whom I am
most grateful and obliged.

I'm sorry to have troubled you.

OT illogical? Helo-v-Host varience - why?

[Sam Jones]

Good morning,

A bit of an extreme example, but i've often wondered, when looking
through my Postfix logs, why some senders do this:

Received: from mx-out.facebook.com (outmail019.snc7.facebook.com
[69.171.232.153]) by .

The connecting host has HELO'd as 'mx-out.facebook.com'
If it is traced through in DNS:
mx-out.facebook.com: 69.63.179.26
69.63.179.26: mx.snc1.tfbnw.net.
mx.snc1.tfbnw.net 67.231.153.30
67.231.153.30 mx0b-00082601.pphosted.com.
mx0b-00082601.pphosted.com. 67.231.153.30

What I find a little crazy is why this bears no relationship to the
connecting IP, and its reverse DNS:

69.171.232.153 - matching, as shown, outmail019.snc7.facebook.com

I'm just wondering as to what circumstances would lead to a host
HELO'ing with a hostname that differs from the connecting IP and host.
I'm sure it is perfectly legal, but I don't see the logic?

Re: OT illogical? Helo-v-Host varience - why?

[Sam Jones]

On Mon, 2012-04-16 at 08:34 -0500, /dev/rob0 wrote:
> On Mon, Apr 16, 2012 at 07:58:31AM +0100, Sam Jones wrote:
> > A bit of an extreme example, but i've often wondered, when
> > looking through my Postfix logs, why some senders do this:
> > 
> > Received: from mx-out.facebook.com (outmail019.snc7.facebook.com
> > [69.171.232.153]) by .
> > 
> > The connecting host has HELO'd as 'mx-out.facebook.com'
> > If it is traced through in DNS:
> > mx-out.facebook.com: 69.63.179.26
> > 69.63.179.26: mx.snc1.tfbnw.net.
> > mx.snc1.tfbnw.net 67.231.153.30
> > 67.231.153.30 mx0b-00082601.pphosted.com.
> > mx0b-00082601.pphosted.com. 67.231.153.30
> > 
> > What I find a little crazy is why this bears no relationship to
> > the connecting IP, and its reverse DNS:
> > 
> > 69.171.232.153 - matching, as shown, outmail019.snc7.facebook.com
> > 
> > I'm just wondering as to what circumstances would lead to a host 
> > HELO'ing with a hostname that differs from the connecting IP and 
> > host.
> 
> Possibly the sending MTA is behind a load balancer?

> > I'm sure it is perfectly legal, but I don't see the logic?
> 
> I wouldn't do it that way ... I would have had all the load balancer 
> IP addresses resolve to the HELO name. But I have not managed a 
> project on the scale of Facebook, so maybe there is some other 
> consideration involved.
Thank you rob0. Much appreciated. I did not considered the sheer amount
of email they must emit and I guess some form of load distribution would
be inevitable. 

Re: postgrey outgoing mail whitelister

[Sam Jones]

On Tue, 2012-04-17 at 11:50 +0200, Reindl Harald wrote:
> 
> Am 17.04.2012 11:48, schrieb Claudius:
> > Hi,
> > 
> > as nobody seems to have a working solution I built a little Perl script
> > that adds the IP of the server receiving outgoing mail to
> > postgrey_clients.db
> > 
> > It's still a little unfinished but working fine on my server. There's
> > room for improvement though (IPv6 missing, rsyslog spawning and lastline
> > fetching is non-optimal). Maybe I will improve this with piping and a fifo.
> 
> are you aware that you are whitelisting this way
> servers which sent spam to a user with autorply?
> 
And I would add that an inbound MX does not necessarily === the same
outbound server a domain would use. Typically anti-spam gateways or
hosted services used inbound on one IP, whereas outbound mail coming
from another IP and server.

Just imagine whitelisting a shared, spammy server because a domain is
hosted on it. Naturally it will probably come through greylisting in the
end anyway, but I'd not go out of my way to make it easy on them!

Does Cleanup (or something) change message body line endings?

[Sam Jones]

Good afternoon,

I've just been troubleshooting an issue with the php mail() function and
Postfix.

Keeping it short and to the point it appears that DKIM can be broken
because something (assuming Cleanup) changes the line endings in the
body section of the mail after it has been signed.

What I noticed (eventually.) was that text areas in forms submitted
to a PHP script contained line endings \r\n. These were passed through
to the Postfix sendmail implementation care of the php mail() function
where it went:

pickup,cleanup,qmgr,smtp,smtpd,smtp before going into: dkimproxy.out

Then, after signing it went:

cleanup,qmgr,smtp

But by the time it arrived with the recipient the body had changed (not
apparent to the eye) and this was happening:

dkim=neutral (body hash did not verify)


Now, if I manually strip the line endings \r\n and replace them a plain
newline \n, it works perfectly suggesting something strips the line
endings if the are \r\n after it has been signed.

Initially I thought 'it won't be Postfix doing this' and I checked:
http://www.postfix.org/cleanup.8.html to make sure it was not
documented. The only fly in the ointment of that train of thought was
another Postfix that I tested against (so I had Postfix to Postfix)
where I got:

(amavisd-new); dkim=softfail (fail, message has been altered)

It's not a big issue, it's easy to filter out the spurious \r coming in
from PHP, but I'd just like to know for my own piece of mind that I'm
not going mad and that something is doing a little house-keeping here? 

Thank you, in advance, for any replies.

Re: Does Cleanup (or something) change message body line endings?

[Sam Jones]

On Tue, 2012-04-24 at 12:58 -0400, Wietse Venema wrote:
> Sam Jones:
> > Now, if I manually strip the line endings \r\n and replace them a plain
> > newline \n, it works perfectly suggesting something strips the line
> > endings if the are \r\n after it has been signed.
> 
> This happens when you use an old Postfix version AND have MIXED
> line endings (some lines end in , other lines end in ).
> 
> Two solutions:
> 
> A) Use consistent line endings: ALL lines end in , or ALL lines
> end in .
> 
> B) Upgrade to a Postfix 2.9 or later that strips  regardless.
> as described in the manpage entry below.
> 
>   Wietse
> 
> sendmail_fix_line_endings (default: always)
>Controls  how  the Postfix sendmail command converts email message line
>endings from  into UNIX format ().
> 
>always Always convert message lines ending in . This setting is
>   the default with Postfix 2.9 and later.
> 
>strict Convert message lines ending in  only if the first input
>   line ends in . This setting is backwards-compatible with
>   Postfix 2.8 and earlier.
> 
>never  Never  convert  message  lines  ending in . This setting
>   exists for completeness only.
> 
>This feature is available in Postfix 2.9 and later.
Thanks for the response, that's perfect. For a moment I really thought I
was going quite mad and at least now I know.

Totally agree that this is not a Postfix issue as such. I had clearly
failed to spot that the Textarea inputs was giving \r\n and filter it.

Again, thank you for your time.

Defer a specific recipient?

[Sam Jones]

A bit of a strange request, but is there a simple way to have Postfix
continually defer mail to a specific recipient, say mail to
'defer.t...@domain.tld' ?

I know with header checks I can do magic like rejecting mail with 5xx
errors, but looking through http://www.postfix.org/header_checks.5.html
I don't see a 'defer' option, but I'm probably putting the cart in front
of the horse with my logic - so I'm open to ideas as I'm clutching at
straws a bit.

Re: Defer a specific recipient?

[Sam Jones]

On Fri, 2012-06-08 at 11:26 +0100, Sam Jones wrote:
> A bit of a strange request, but is there a simple way to have Postfix
> continually defer mail to a specific recipient, say mail to
> 'defer.t...@domain.tld' ?
> 
> I know with header checks I can do magic like rejecting mail with 5xx
> errors, but looking through http://www.postfix.org/header_checks.5.html
> I don't see a 'defer' option, but I'm probably putting the cart in front
> of the horse with my logic - so I'm open to ideas as I'm clutching at
> straws a bit.
> 
Ignore me, I found it in check_recipient_access. I'm having a bad and
inattentive day.

Bulk Mailing Performance

[Sam Jones]

More to satisfy my own curiosity than anything else, I'm wondering about
the performance that could be squeezed out of Postfix in a bulk mailing
capacity.

I have a client that currently uses and ESP who have an astounding
throughput of up to a million messages per hour. This brought up a
discussion about high-performance MTAs and tuning and the general
comments I'm hearing are that things like Postfix, Exim, Sendmail &
are just not man enough for such a task and the absolute best you could
expect from any of them is about 100k messages per hour.

Now, I like to wipe out the fact from fiction because people like
PowerMTA are looking to sell their products and it would be in their
interest to neglect that any MTA (Postfix/Exim/Sendmail) could be set up
in a way that would easily rival their product.

Can anyone on the list tell me if it's possible to performance tune
Postfix to a point where it could complete with this and possible
strategies?

Kind thanks

Re: Bulk Mailing Performance

[Sam Jones]

On Sun, 2012-09-02 at 15:39 +, Viktor Dukhovni wrote:
> On Sun, Sep 02, 2012 at 10:43:07AM +0100, Sam Jones wrote:
> 
> > More to satisfy my own curiosity than anything else, I'm wondering about
> > the performance that could be squeezed out of Postfix in a bulk mailing
> > capacity.
> 
> Running a high volume bulk email platform is not a software problem.
> It is a logistics problem. Enrolling on the whitelists and feedback
> loops of various large email providers, handling bounce-backs,
> jumping through rate-limit hoops, ...
> 
> 
> > I have a client that currently uses and ESP who have an astounding
> > throughput of up to a million messages per hour.
> 
> This is not astounding, a single ~2003 Dell 1850 Postfix server
> was measured by me at ~300 msgs/sec of deliveries to real users
> with nothing but a simple MegaRAID controller (with battery cache)
> striping two SCSI disks. This would go another factor of 2 faster
> on today's commodity servers, but the real issue is finding peers
> who'll accept your mail at that rate.
> 
> > discussion about high-performance MTAs and tuning and the general
> > comments I'm hearing are that things like Postfix, Exim, Sendmail &
> > are just not man enough for such a task and the absolute best you could
> > expect from any of them is about 100k messages per hour.
> 
> Many bulk email services in fact use Postfix, Exim, ...  The MTA
> software is often not the bottleneck. They split bulk deliveries
> over many machines (or lots of IPs on the same machine) and tune
> to avoid throttling by the ESP over and above all other concerns.
> Raw MTA performance is rarely a factor.
> 
> > Now, I like to wipe out the fact from fiction because people like
> > PowerMTA are looking to sell their products and it would be in their
> > interest to neglect that any MTA (Postfix/Exim/Sendmail) could be set up
> > in a way that would easily rival their product.
> 
> Bulk email is a logistics exercise. When you choose an bulk email
> delivery service, you're buying their logistics skills and their
> reputation with mailbox providers (Gmail, Hotmail, Yahoo, ...)
> 
> > Can anyone on the list tell me if it's possible to performance tune
> > Postfix to a point where it could complete with this and possible
> > strategies?
> 
> Wrong question.
> 
I really appreciate the post Viktor. Thought provoking and clear.

I guess what I'm querying in a way is some of the sales blurb from
people like PowerMTA & GreenArrow and the remarks they make about open
source solutions like Postfix etc. This one in particular: "Open source
Mail Transfer Agents (MTAs) often max out between 20 and 30 thousand
messages per hour. GreenArrow can send 300,000 messages per hour—more
than ten times as fast."

If we strip this back to hypothetical and assume a perfect world without
any issues like rate limiting and rejection, small emails with nomay
restrictions or network issues with the recipient MX's, is the above
statement plausibly true?

I'm assuming - and I've not yet looked deeply at this - that there is
probably a way to get Postfix to run parallel instances to improve
delivery speed.

Re: Bulk Mailing Performance

[Sam Jones]

On Sun, 2012-09-02 at 22:46 +0200, Lorens Kockum wrote:
> The exact same question was sent by someone calling himself
> "Ron White" to the exim mailing list at almost exactly the same
> time. Peddling one's services by soliciting comparisons with
> competitors is so passé . . .
> 
Yes, it was. Well done. The question applied to both MTA's and funny
enough, the use of Aliases on the internet is nothing new.

Thanks to those that contributed useful information. I think it's safe
to say that the sales blurb is looking at a very basic scenario.

Freemailer segregation best way? Transports - Instances & IP's

[Sam Jones]

Good afternoon,

I'm looking to get some views and advice on the best way to set Postfix
up so I can segregate a large newsletter list up into a semi decent
working structure.

Basically my newsletter server has a /29 and I want to set up Postfix to
(hopefully) do something like this:

eth0:1 1.1.1.1 GMAIL Subscribers
eth0:2 2.2.2.2 AoL Subscribers
eht0:3 3.3.3.3 all others

I'd like to be able to rate control the Gmail & AoL to complicate issues
a little. I know how powerful and fast Postfix can be and I don't want
to exceed the limits set on small scale mailers like us.

What I'm looking for is the best approach to do this?

I don't think I can do this with multiple instances as the incoming mail
stream from the newsletter server (SMTP) has a stream of recipients at
various domains, so what arrives in the Instance of Postfix will be
mixed to start with.

So I guess this means I'll need to simply do this in transports. I think
I read that it's possible to create transports for specific SMTP
destinations in the Book of Postfix. I guess I'd need to ask 'can I
assign a specific interface/IP on a per transport basis?'

Any suggestions or feedback would be gratefully received.

Sam

Re: Freemailer segregation best way? Transports - Instances & IP's

[Sam Jones]

That looks like a good starting point, Thank you for the pointers
Robert, really appreciated.


On Tue, 2012-11-20 at 14:35 +0100, Robert Schetterer wrote:
> Am 20.11.2012 14:13, schrieb Sam Jones:
> > Good afternoon,
> > 
> > I'm looking to get some views and advice on the best way to set Postfix
> > up so I can segregate a large newsletter list up into a semi decent
> > working structure.
> > 
> > Basically my newsletter server has a /29 and I want to set up Postfix to
> > (hopefully) do something like this:
> > 
> > eth0:1 1.1.1.1 GMAIL Subscribers
> > eth0:2 2.2.2.2 AoL Subscribers
> > eht0:3 3.3.3.3 all others
> > 
> > I'd like to be able to rate control the Gmail & AoL to complicate issues
> > a little. I know how powerful and fast Postfix can be and I don't want
> > to exceed the limits set on small scale mailers like us.
> > 
> > What I'm looking for is the best approach to do this?
> > 
> > I don't think I can do this with multiple instances as the incoming mail
> > stream from the newsletter server (SMTP) has a stream of recipients at
> > various domains, so what arrives in the Instance of Postfix will be
> > mixed to start with.
> > 
> > So I guess this means I'll need to simply do this in transports. I think
> > I read that it's possible to create transports for specific SMTP
> > destinations in the Book of Postfix. I guess I'd need to ask 'can I
> > assign a specific interface/IP on a per transport basis?'
> > 
> > Any suggestions or feedback would be gratefully received.
> > 
> > Sam
> > 
> 
> perhaps do it like this ( total untested )
> 
> master.cf
> 
> smtpaol  unix -   -   n   -   -   smtp
>  
>   -o smtp_bind_address=1.2.3.1
> smtpgmail  unix -   -   n   -   -   smtp
>   .
>   -o smtp_bind_address=1.2.3.2
> 
> main.cf
> 
> smtpaol_destination_concurrency_limit = 2
> smtpaol_destination_recipient_limit = 5
> smtpaol_destination_rate_delay = 1s
> smtpaol_destination_concurrency_failed_cohort_limit = 100
> 
> 
> smtpgmail_destination_concurrency_limit = 2
> smtpgmail_destination_recipient_limit = 5
> smtpgmail_destination_rate_delay = 1s
> smtpgmail_destination_concurrency_failed_cohort_limit = 100
> 
> transport
> 
> 
> googlemail.com smtpgmail:googlemail.com
> aol.com smtpaol:aol.com
> 
> 
> Best Regards
> MfG Robert Schetterer
> 

Re: Freemailer segregation best way? Transports - Instances & IP's

[Sam Jones]

Appreciated, thanks.

I'm just installing it to an old bare metal test server so I can get it
right before putting it into production.

Many thanks to you both - really appreciated.


On Tue, 2012-11-20 at 09:58 -0500, Wietse Venema wrote:
> Sam Jones:
> > That looks like a good starting point, Thank you for the pointers
> > Robert, really appreciated.
> 
> You need to keep the following in mind, if you ever decide to use
> a per-destination recipient of 1.
> 
> Wietse
> 
> default_destination_rate_delay (default: 0s)
>The default amount of delay that is inserted between individual
> deliv-
>eries  to  the  same destination; the resulting behavior
> depends on the
>value of the corresponding per-destination recipient limit.
> 
>o  With a corresponding per-destination recipient limit  >
> 1,  the
>   rate  delay  specifies  the  time between deliveries to
> the same
>   domain.  Different domains are delivered in parallel,
> subject to
>   the process limits specified in master.cf.
> 
>o  With a corresponding per-destination recipient limit
> equal to 1,
>   the rate delay specifies the time between deliveries to
> the same
>   recipient.  Different recipients are delivered in
> parallel, sub-
>   ject to the process limits specified in master.cf. 

unused parameter

[Sam Jones]

Good afternoon,

When I start my Postfix up (fresh install I'm trying to commission to
take over newsletter duties) I'm seeing this:

unused parameter: smtpd_client_restrictons=permit_mynetworks
sleep 1, warn_if_reject reject_unauth_pipelining?warn_if_reject
reject_unknown_client?permit

The chunk of main.cf it relates to:

smtpd_client_restrictons =
permit_mynetworks
sleep 1, warn_if_reject reject_unauth_pipelining
warn_if_reject reject_unknown_client
permit


I suspect it is because I have 'upcycled' my main from a working
install: mail_version = 2.7.0 but the new server has mail_version =
2.9.3.

If I could remember why I put that stanza in there it would be helpful,
but I can't recall what I was trying to fire off with Warn. 

I'm sure there is a change and if I spent some time going through the
docs I may probably find it - but if I could get a headstart and some
pointers that would be kind and wonderful.

Warm regards
Sam

Re: [Bulk] Re: unused parameter

[Sam Jones]

Thank you so much Noel.

That was exactly it, and to confuse matters even more it had been in my
old config like that for a year with no warning coming up.

I've removed the sleep 1, I have no idea why I put it there but as the
typo would have stopped it working I think it's safe to say I don't need
it!

Warm regards
Sam

On Wed, 2012-11-21 at 11:23 -0600, Noel Jones wrote:
> On 11/21/2012 11:12 AM, Sam Jones wrote:
> > Good afternoon,
> > 
> > When I start my Postfix up (fresh install I'm trying to commission to
> > take over newsletter duties) I'm seeing this:
> > 
> > unused parameter: smtpd_client_restrictons=permit_mynetworks
> > sleep 1, warn_if_reject reject_unauth_pipelining?warn_if_reject
> > reject_unknown_client?permit
> > 
> > The chunk of main.cf it relates to:
> > 
> > smtpd_client_restrictons =
> > permit_mynetworks
> > sleep 1, warn_if_reject reject_unauth_pipelining
> > warn_if_reject reject_unknown_client
> > permit
> > 
> > 
> > I suspect it is because I have 'upcycled' my main from a working
> > install: mail_version = 2.7.0 but the new server has mail_version =
> > 2.9.3.
> 
> Looks like a typo.
> 
> smtpd_client_restrictons <> smtpd_client_restrictions
> Note the missing "i".
> 
> As a side note, rather than using "sleep 1" which penalizes all
> clients, configure postscreen.
> 
> 
> 
>   -- Noel Jones

VERP clarification

[Sam Jones]

Am I right in thinking that it's the mailing software/client (Be that
Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for
creating the VERP address, and that it's not something I can get POSTFIX
to do on the fly (perhaps with a milter or header rewrite) at SMTP time?

I've read - but don't fully 'get' - the docs, so I'm really looking for
a basic 'yes you can, read this' or 'no, that's the job of the client'
type answer.

Kind regards
Sam

Re: VERP clarification

[Sam Jones]

Noel, once more you help me out. Thank you so very much. I did look at
that, but didn't fully understand it. Now I know I CAN do it, I'll work
with it and experiment.

Thank you so much,
Sam

On Fri, 2012-11-30 at 13:35 -0600, Noel Jones wrote:
> On 11/30/2012 1:27 PM, Sam Jones wrote:
> > Am I right in thinking that it's the mailing software/client (Be that
> > Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for
> > creating the VERP address, and that it's not something I can get POSTFIX
> > to do on the fly (perhaps with a milter or header rewrite) at SMTP time?
> > 
> > I've read - but don't fully 'get' - the docs, so I'm really looking for
> > a basic 'yes you can, read this' or 'no, that's the job of the client'
> > type answer.
> > 
> > Kind regards
> > Sam
> > 
> > 
> 
> 
> If your mailing list software creates VERP addresses, postfix will
> happily use them.
> 
> Postfix also has built-in support for creating VERP while sending mail.
> http://www.postfix.org/VERP_README.html
> 
> 
> Official postfix docs can be found here:
> http://www.postfix.org/documentation.html
> The docs are one of postfix's best features.
> 
> 
> 
>   -- Noel Jones

VERP Sanity Check

[Sam Jones]

Good afternoon List Members,

I'm having a bit of a problem getting VERP to work on my multi-instance
Postfix. I'm probably missing a step.

I've checked I have PCRE available, and that they work. I've set up
everything as per http://www.postfix.org/VERP_README.html.

MAPS
/^(MAIL FROM:<.+@munged1\.co\.uk>.*)/ $1 XVERP
/^(MAIL FROM:<.+@munged2\.co\.uk>.*)/ $1 XVERP=+=

main.cf for outbound instance
#VERP
smtpd_command_filter = pcre:/etc/postfix-out/maps/append-verp.pcre
(not sure where in main.cf I put this, it's close to the top)

But when I test I get:

MAIL FROM command failed: Unsupported option: XVERP
and
MAIL FROM command failed: Unsupported option: XVERP=+=

With log lines like
outpostfix/smtpd[] . replacing command "MAIL
FROM:" with "MAIL FROM:" with "MAIL FROM:

Re: [Bulk] Re: VERP Sanity Check

[Sam Jones]

Thank you Viktor - that is exactly it. I assumed it was an option but
when I read further that was incorrect.

It is now working just as intended. Thank you very much for taking the
time to look at my post and reply. I am very grateful for your time.

Kind regards and happy holidays.
Sam

On Fri, 2012-12-21 at 16:19 +, Viktor Dukhovni wrote:
> On Fri, Dec 21, 2012 at 04:12:11PM +0000, Sam Jones wrote:
> 
> > I've checked I have PCRE available, and that they work. I've set up
> > everything as per http://www.postfix.org/VERP_README.html.
> 
> See: http://www.postfix.org/VERP_README.html#config
> 
> You likely forgot to set:
> 
>   smtpd_authorized_verp_clients
> 
> or else the legacy equivalent:
> 
>   authorized_verp_clients
> 
> > MAPS
> > /^(MAIL FROM:<.+@munged1\.co\.uk>.*)/ $1 XVERP
> > /^(MAIL FROM:<.+@munged2\.co\.uk>.*)/ $1 XVERP=+=
> 
> Coercing XVERP globally is only safe if all clients permitted
> to use your SMTP server should be allowed to use XVERP.
> 

Postfix sending issue

[Sam Flint]

Hi
I've been having issues sending email out through postfix.  My postconf
-n is:

broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = ipv4, ipv6
message_size_limit = 3072
mydestination = $myhostname, localhost, localhost.localdomain
mydomain = flintfam.org
myhostname = mail.flintfam.org
mynetworks = all
myorigin = $mydomain
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps 
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
$virtual_mailbox_limit_maps
relay_domains = .com .org .net .info $mydestination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
smtpd_use_tls = yes
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, 
mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_transport = dovecot
virtual_uid_maps = static:5000

The log entries are:

Jul  3 00:28:41 bell postfix/smtpd[15256]: warning: dict_nis_init: NIS domain 
name not set - NIS lookups disabled
Jul  3 00:28:41 bell postfix/smtpd[15256]: connect from localhost[::1]
Jul  3 00:28:41 bell postfix/smtpd[15256]: NOQUEUE: reject: RCPT from 
localhost[::1]: 554 5.7.1 : Relay access denied; 
from= to= proto=ESMTP 
helo=
Jul  3 00:28:41 bell postfix/smtpd[15256]: lost connection after RCPT from 
localhost[::1]
Jul  3 00:28:41 bell postfix/smtpd[15256]: disconnect from
localhost[::1]

The error in my mail client is:

Transaction failed
554 5.7.1 : Relay access denied

Sam

-- 
Sam Flint
Happy Hacking!
swfl...@flintfam.org
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

I see, but it does nothing.

Sam


On Fri, Jul 19, 2013 at 4:32 PM, Simon B  wrote:

>
> On 19 Jul 2013 23:28, "Sam Flint"  wrote:
> >
> > my postfix will not accept remote connections, but it will accept local.
> >
> > postconf -n:
> > broken_sasl_auth_clients = yes
> > config_directory = /etc/postfix
> > home_mailbox = Maildir/
> > inet_interfaces = all
> > inet_protocols = ipv4, ipv6
> > message_size_limit = 3072
> > mydestination = $myhostname, localhost, localhost.localdomain
> > mydomain = flintfam.org
> > myhostname = mail.flintfam.org
> > mynetworks = all
> > myorigin = $mydomain
> > proxy_read_maps = $local_recipient_maps $mydestination
> $virtual_alias_maps
> $virt
> ual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
> $relay_recipien
> t_maps $relay_domains $canonical_maps $sender_canonical_maps
> $recipient_canonica
> l_maps $relocated_maps $transport_maps $mynetworks
> $virtual_mailbox_limit_maps
> > relay_domains = .com .org .net .info $mydestination
> > smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
> rej
> ect_unauth_destination, permit
>
> So, you permit your networks, and if that condition is satisfied, you
> permit if sasl authenticated, and if that's satisfied you reject non-local
> domains.
>
> Do you see the issue?
>
> Simon
>
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_authenticated_header = yes
> > smtpd_sasl_path = private/auth
> > smtpd_sasl_type = dovecot
> > smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
> > smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
> > smtpd_use_tls = yes
> > virtual_alias_maps = proxy:mysql:/etc/postfix/
> mysql-virtual_forwardings.cf,
> mysq
> l:/etc/postfix/mysql-virtual_email2email.cf
> > virtual_gid_maps = static:5000
> > virtual_mailbox_base = /home/vmail
> > virtual_mailbox_domains = proxy:mysql:/etc/postfix/
> mysql-virtual_domains.cf
> > virtual_mailbox_maps = proxy:mysql:/etc/postfix/
> mysql-virtual_mailboxes.cf
> > virtual_transport = dovecot
> > virtual_uid_maps = static:5000
> >
> > Log entry:
> > none.
> >
> > Sam
> >
> > --
> > Sam Flint
> > flintfam.org/~swflint
>



-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

it's already like that



On Fri, Jul 19, 2013 at 4:42 PM, Noel Jones  wrote:

> On 7/19/2013 4:26 PM, Sam Flint wrote:
> > my postfix will not accept remote connections, but it will accept local.
>
> Some linux distros configure postfix to only listen on localhost,
> forcing you to edit master.cf to listen remotely.
>
> Look for a line in msater.cf something like:
> 127.0.0.1:smtp inet  n  -  n  -  -  smtpd
>
> and take out the 127.0.0.1: part so the line starts with "smtp inet"
> smtp inet  n  -  n  -  -  smtpd
>
> Then do a "postfix stop ; postfix start"
>
>
>   -- Noel Jones
>
>
>
> >
> > postconf -n:
> > broken_sasl_auth_clients = yes
> > config_directory = /etc/postfix
> > home_mailbox = Maildir/
> > inet_interfaces = all
> > inet_protocols = ipv4, ipv6
> > message_size_limit = 3072
> > mydestination = $myhostname, localhost, localhost.localdomain
> > mydomain = flintfam.org <http://flintfam.org>
> > myhostname = mail.flintfam.org <http://mail.flintfam.org>
> > mynetworks = all
> > myorigin = $mydomain
> > proxy_read_maps = $local_recipient_maps $mydestination
> > $virtual_alias_maps
> > $virt
> > ual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
> > $relay_recipien
> > t_maps $relay_domains $canonical_maps $sender_canonical_maps
> > $recipient_canonica
> > l_maps $relocated_maps $transport_maps $mynetworks
> > $virtual_mailbox_limit_maps
> > relay_domains = .com .org .net .info $mydestination
> > smtpd_recipient_restrictions = permit_mynetworks,
> > permit_sasl_authenticated,
> > rej
> > ect_unauth_destination, permit
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_authenticated_header = yes
> > smtpd_sasl_path = private/auth
> > smtpd_sasl_type = dovecot
> > smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
> > smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
> > smtpd_use_tls = yes
> > virtual_alias_maps =
> > proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf
> > <http://mysql-virtual_forwardings.cf>,
> > mysq
> > l:/etc/postfix/mysql-virtual_email2email.cf
> > <http://mysql-virtual_email2email.cf>
> > virtual_gid_maps = static:5000
> > virtual_mailbox_base = /home/vmail
> > virtual_mailbox_domains =
> > proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
> > <http://mysql-virtual_domains.cf>
> > virtual_mailbox_maps =
> > proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
> > <http://mysql-virtual_mailboxes.cf>
> > virtual_transport = dovecot
> > virtual_uid_maps = static:5000
> >
> > Log entry:
> > none.
> >
> > Sam
> >
> > --
> > Sam Flint
> > flintfam.org/~swflint <http://flintfam.org/~swflint>
>
>


-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

Still nothing


On Fri, Jul 19, 2013 at 4:46 PM, Noel Jones  wrote:

>
> >> relay_domains = .com .org .net .info $mydestination
>
> The above is very bad, change it to empty:
>
> relay_domains =
>
>
> >> smtpd_recipient_restrictions = permit_mynetworks,
> > permit_sasl_authenticated,
> > rej
> > ect_unauth_destination, permit
> >
> > So, you permit your networks, and if that condition is satisfied,
> > you permit if sasl authenticated, and if that's satisfied you reject
> > non-local domains.
> >
> > Do you see the issue?
>
> No issue with this entry, this is normal.  (well, the final "permit"
> is unneeded, but won't hurt anything.)
>
>
>
>   -- Noel Jones
>



-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

Sorry, Gmail.

I'm testing by attempting to connect with my android tablet


On Fri, Jul 19, 2013 at 5:08 PM, Noel Jones  wrote:

> On 7/19/2013 4:58 PM, Sam Flint wrote:
> > I'm running on a linode, and I'm sorry.
> >
> > Netstat:
> > Proto Recv-Q Send-Q Local Address   Foreign
> > Address State
> > tcp0232 flintfam.org:ssh
> > ip98-161-54-206.om.om:52460 <http://ip98-161-54-206.om.om:52460>
> > ESTABLISHED
> > tcp0  0 localhost:44273
> > localhost:mysql TIME_WAIT
> > tcp0  0 flintfam.org:http
> > 89-145-108-208.as2901:47988 TIME_WAIT
> > tcp0  0 flintfam.org:http
> > 89-145-108-208.as2901:47975 TIME_WAIT
>
>
> Stop top posting. And plain-text only please -- the HTML makes
> tables and logs impossible to read.
>
> Doesn't look as if postfix is listening at all.  How are you testing
> postfix?
>
> Check the postfix log for errors.
> http://www.postfix.org/DEBUG_README.html
> http://www.postfix.org/DEBUG_README.html#logging
>
>
>
>   -- Noel Jones
>



-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

Ok, well thanks.

I'm sorry, I will try.


On Fri, Jul 19, 2013 at 5:01 PM, Noel Jones  wrote:

> On 7/19/2013 4:53 PM, Sam Flint wrote:
> > Still nothing
> >
> >
> > On Fri, Jul 19, 2013 at 4:46 PM, Noel Jones  > <mailto:njo...@megan.vbhcs.org>> wrote:
> >
> >
> > >> relay_domains = .com .org .net .info $mydestination
> >
> > The above is very bad, change it to empty:
> >
> > relay_domains =
> >
>
>
> Stop top posting.  And maybe more than one-line answers would get
> you better help.
>
>
> BTW, the above correction ("relay_domains =  ")is to keep you from
> being an open relay, and was not expected to fix the apparent
> problem of postfix not listening on outside interfaces.
>
>
>   -- Noel Jones
>



-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

alemail-backend unix -   n   n   -   2   pipe
#  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
#  ${nexthop} ${user} ${extension}
#
#mailman   unix  -   n   n   -   -   pipe
#  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
#  ${nexthop} ${user}
dovecot   unix  -   n   n   -   -   pipe
   flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -d
${recipient} -f ${recipient}


Thanks.

Sam


On Fri, Jul 19, 2013 at 4:55 PM, Noel Jones  wrote:

> On 7/19/2013 4:45 PM, Sam Flint wrote:
> > it's already like that
> >
>
> stop top posting.
>
>
> Sorry, my crystal ball is at the cleaners. Maybe start with
> describing how you're testing.
>
> Also note some ISPs block port 25 on "consumer" connections, making
> running or testing a mail server impossible. You didn't mention what
> kind of connection you have.
>
> Also, master.cf contents, and netstat or lsof output showing what's
> listening on port 25 might be helpful.
>
>
>
>   -- Noel Jones
>



-- 
Sam Flint
flintfam.org/~swflint

Postfix not accepting remote connections

[Sam Flint]

my postfix will not accept remote connections, but it will accept local.

postconf -n:
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = ipv4, ipv6
message_size_limit = 3072
mydestination = $myhostname, localhost, localhost.localdomain
mydomain = flintfam.org
myhostname = mail.flintfam.org
mynetworks = all
myorigin = $mydomain
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virt
ual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipien
t_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonica
l_maps $relocated_maps $transport_maps $mynetworks
$virtual_mailbox_limit_maps
relay_domains = .com .org .net .info $mydestination
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
rej
ect_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
smtpd_use_tls = yes
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf,
mysq
l:/etc/postfix/mysql-virtual_email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_transport = dovecot
virtual_uid_maps = static:5000

Log entry:
none.

Sam

-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

On Fri, Jul 19, 2013 at 6:02 PM, Wietse Venema  wrote:
> Sam Flint:
>> Postfix is listening, I can still recieve email.
>
> Hi. I wrote most of Postfix. What evidence do you have (SHOW POSTFIX
> LOGGING) that Postfix is receiving mail for you?
>
> Wietse
It arrives in my inbox, delivered by dovecot.

Postfix says:
Jul 19 23:09:47 bell postfix/smtpd[29578]: warning: dict_nis_init: NIS
domain name not set - NIS lookups disabled
Jul 19 23:09:47 bell postfix/smtpd[29578]: connect from
mail-qc0-f170.google.com[209.85.216.170]
Jul 19 23:09:48 bell postfix/smtpd[29578]: 2809696BF:
client=mail-qc0-f170.google.com[209.85.216.170]
Jul 19 23:09:48 bell postfix/cleanup[29588]: 2809696BF:
message-id=
Jul 19 23:09:48 bell postfix/qmgr[28887]: 2809696BF:
from=, size=1493, nrcpt=1 (queue active)
Jul 19 23:09:48 bell postfix/smtpd[29578]: disconnect from
mail-qc0-f170.google.com[209.85.216.170]
Jul 19 23:09:48 bell postfix/pipe[29590]: 2809696BF:
to=, relay=dovecot, delay=0.2,
delays=0.13/0.01/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot
service)
Jul 19 23:09:48 bell postfix/qmgr[28887]: 2809696BF: removed

dovecot's delivery log shows:
2013-07-19 23:09:48 lda(swfl...@flintfam.org): Info:
msgid=:
saved mail to INBOX

Sam


--
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

On Fri, Jul 19, 2013 at 5:11 PM, Sam Flint  wrote:
> Sorry, Gmail.
>
> I'm testing by attempting to connect with my android tablet
>
>
> On Fri, Jul 19, 2013 at 5:08 PM, Noel Jones  wrote:
>>
>> On 7/19/2013 4:58 PM, Sam Flint wrote:
>> > I'm running on a linode, and I'm sorry.
>> >
>> > Netstat:
>> > Proto Recv-Q Send-Q Local Address   Foreign
>> > Address State
>> > tcp0232 flintfam.org:ssh
>> > ip98-161-54-206.om.om:52460 <http://ip98-161-54-206.om.om:52460>
>> > ESTABLISHED
>> > tcp0  0 localhost:44273
>> > localhost:mysql TIME_WAIT
>> > tcp0  0 flintfam.org:http
>> > 89-145-108-208.as2901:47988 TIME_WAIT
>> > tcp0  0 flintfam.org:http
>> > 89-145-108-208.as2901:47975 TIME_WAIT
>>
>>
>> Stop top posting. And plain-text only please -- the HTML makes
>> tables and logs impossible to read.
>>
>> Doesn't look as if postfix is listening at all.  How are you testing
>> postfix?
>>
>> Check the postfix log for errors.
>> http://www.postfix.org/DEBUG_README.html
>> http://www.postfix.org/DEBUG_README.html#logging
>>
>>
>>
>>   -- Noel Jones
>
>
>
>
> --
> Sam Flint
> flintfam.org/~swflint

Postfix is listening, I can still recieve email.

Sam

--
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

It shouldn't be...

On Fri, Jul 19, 2013 at 5:59 PM, /dev/rob0  wrote:
> On Fri, Jul 19, 2013 at 05:51:20PM -0500, Sam Flint wrote:
>> On Fri, Jul 19, 2013 at 5:11 PM, Sam Flint  wrote:
>> > On Fri, Jul 19, 2013 at 5:08 PM, Noel Jones  wrote:
>> >>
>> >> On 7/19/2013 4:58 PM, Sam Flint wrote:
>> >> > I'm running on a linode, and I'm sorry.
>> >> >
>> >> > Netstat:
> snip
>> >>
>> >> Stop top posting. And plain-text only please -- the HTML makes
>> >> tables and logs impossible to read.
>> >>
>> >> Doesn't look as if postfix is listening at all.  How are you
>> >> testing postfix?
>> >>
>> > Sorry, Gmail.
>> >
>> > I'm testing by attempting to connect with my android tablet
>> >
> snip
>> Postfix is listening, I can still recieve email.
>
> $ telnet mail.flintfam.org 25
> Trying 50.116.25.174...
> Connected to mail.flintfam.org.
> Escape character is '^]'.
> 220 mail.flintfam.org ESMTP Postfix
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
> $ telnet mail.flintfam.org 587
> Trying 50.116.25.174...
> telnet: connect to address 50.116.25.174: Connection refused
>
> Port 25 is fine (or at least as far as I tested.) 587 is not. Perhaps
> your ISP is blocking port 25 outbound from the android tablet?
>
>> >
>> >> Check the postfix log for errors.
>> >> http://www.postfix.org/DEBUG_README.html
>> >> http://www.postfix.org/DEBUG_README.html#logging
> --
>   http://rob0.nodns4.us/ -- system administration and consulting
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:



-- 
Sam Flint
flintfam.org/~swflint

Re: Postfix not accepting remote connections

[Sam Flint]

On Fri, Jul 19, 2013 at 6:02 PM, Sam Flint  wrote:
> It shouldn't be...
>
> On Fri, Jul 19, 2013 at 5:59 PM, /dev/rob0  wrote:
>> On Fri, Jul 19, 2013 at 05:51:20PM -0500, Sam Flint wrote:
>>> On Fri, Jul 19, 2013 at 5:11 PM, Sam Flint  wrote:
>>> > On Fri, Jul 19, 2013 at 5:08 PM, Noel Jones  
>>> > wrote:
>>> >>
>>> >> On 7/19/2013 4:58 PM, Sam Flint wrote:
>>> >> > I'm running on a linode, and I'm sorry.
>>> >> >
>>> >> > Netstat:
>> snip
>>> >>
>>> >> Stop top posting. And plain-text only please -- the HTML makes
>>> >> tables and logs impossible to read.
>>> >>
>>> >> Doesn't look as if postfix is listening at all.  How are you
>>> >> testing postfix?
>>> >>
>>> > Sorry, Gmail.
>>> >
>>> > I'm testing by attempting to connect with my android tablet
>>> >
>> snip
>>> Postfix is listening, I can still recieve email.
>>
>> $ telnet mail.flintfam.org 25
>> Trying 50.116.25.174...
>> Connected to mail.flintfam.org.
>> Escape character is '^]'.
>> 220 mail.flintfam.org ESMTP Postfix
>> quit
>> 221 2.0.0 Bye
>> Connection closed by foreign host.
>> $ telnet mail.flintfam.org 587
>> Trying 50.116.25.174...
>> telnet: connect to address 50.116.25.174: Connection refused
>>
>> Port 25 is fine (or at least as far as I tested.) 587 is not. Perhaps
>> your ISP is blocking port 25 outbound from the android tablet?
>>
>>> >
>>> >> Check the postfix log for errors.
>>> >> http://www.postfix.org/DEBUG_README.html
>>> >> http://www.postfix.org/DEBUG_README.html#logging
>> --
>>   http://rob0.nodns4.us/ -- system administration and consulting
>>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

What can I do to fix this on the server end? how can I run on both?

Sam


--
Sam Flint
flintfam.org/~swflint

Re: Why Postfix always complain "unexpected EOF" with my own tcp_table program?

[Sam Flint]

On Jul 28, 2013 7:25 AM, "Wietse Venema"  wrote:
>
> Zhang Huangbin:
> > Dear all,
> >
> > I wrote a simple daemon service in Python, it's used in Postfix
transport_maps like this:
> >
> > transport_maps = tcp:127.0.0.1:1234
> >
> > It always returns '200 my_transport\n' as described in Postfix manual
page tcp_table(5), but Postfix always complains "unexpected EOF" like below:
> >
> > Jul 27 22:51:53 d7 postfix/trivial-rewrite[4260]: warning: read TCP map
reply from 127.0.0.1:1234: unexpected EOF (Success)
> >
> > This Python daemon server uses 'asynchat' module, and return '200
my_transport\n' with 'async_chat.push()' method like this:
> >
> > self.push('200 my_transport\n')
> >
> > Any idea why Postfix always complain "unexpected EOF"?
>
> 1) Use a network sniffer to see what Python actually sends. You may
>assume that your program sends \n, but Postfix does not receive \n.
>
> 2) Unrelated to this bug: closing the connection after one request
>is inefficient.

But is it the fact that he closes the connection? Keep in mind that any
time a network connection is closed it sends EOF.   Could it be that
Postfix wants to keep a constant connection?

Sam

> Wietse

Alias to command not working

[Sam Flint]

I hve an alias to a command defined in my /etc/aliases file, anytime I
send to it, I get this error:

This is the mail system at host mail.flintfam.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

<|postman...@flintfam.org> (expanded from ): user
unknown

Any idea why?

Sam



-- 
Sam Flint
flintfam.org/~swflint

Re: Would somebody let me know what I need to do to improve this setup.

[Sam Flint]

Try ownCloud, it provides webdav and sharing.

On Wed, Aug 7, 2013 at 10:17 AM, DTNX Postmaster  wrote:
> On Aug 7, 2013, at 16:32, John Allen  wrote:
>
>>>>> Is there any particular reason you need to accept messages 32 GB in size?
>>>>>
>>>> Yes. We support a business that designs and manufactures packaging and 
>>>> displays. The sort of thing you might see in the aisle of a supermarket or 
>>>> store selling gum, personal care products.  The graphics, art work and 
>>>> design of these need to be sent to the people involved. We have looked 
>>>> into using services like Dropbox but the problem with all of these is 
>>>> copyright. Our customers legal eagles have advise against such services as 
>>>> they may compromise their copyright on anything stored on such services.
>>>>
>>>> OT: It is the same advice and reasoning they gave against using public 
>>>> cloud services, some of whose terms of service essentially strip the user 
>>>> of all copyright ownership.
>>> And they are regularly sending you files, via e-mail, up to 32 GB in
>>> size? Attachments that are larger than, say, 1 GB? Does the sending
>>> mail server allow attachments that big in outgoing mail? Does your
>>> queue directory reside on a partition that has that much room?
>>>
>>> When have you last grepped through your logs to look at the actual
>>> sizes of the messages that are coming in? What is the largest message
>>> size you have received in, say, the last four weeks?
>>>
>>> I find it all a wee bit hard to believe. You see, we also support
>>> similar businesses, and have for many years. For large files, they are
>>> uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
>>> they are using WeTransfer for this. Check their terms, several of our
>>> clients have abandoned their local file transfer setups for it.
>>>
>>> But please, stop abusing e-mail for this. It's insane, and a disaster
>>> waiting to happen.
>>
>> We have already setup a webdav system for saving large attachments, the in 
>> house users are supposed to use this for internal mail.
>> This still leaves the problem of contractors and suppliers. The problem here 
>> is how to isolate them from each other and the whole from the outsider.
>
> It is a solved problem, has been for years. For example, a SFTP or FTPS
> server; contractors and suppliers each get their own login and are
> locked into their home directory. They only see their own files, no one
> else's.
>
> Or you use one of the several options out there in terms of web based
> project management and whatnot, such as activeCollab, or one of the
> suggestions made here on the list. Each user only has access to
> relevant projects, and you have the advantage of storing file metadata
> such as description, comments, versioning and so on.
>
> And at the very least, review your logs for the actual sizes of
> incoming messages, and see what usage dictates. I have a hunch it is
> going to be much lower than your current limit.
>
> Mvg,
> Joni
>



-- 
Sam Flint
flintfam.org/~swflint

UCE and restriction classes

[Sam Przyswa]

Hi all,

I succeed to limit some local users to send mail only on my local 
domain, but I would like to limit the mail received ONLY from the local 
users too for these users,  no mails from internet (others domains).


There is my actual Postfix config:

/etc/postfix/main.cf:
...
smtpd_recipient_restrictions = check_sender_access 
hash:/etc/postfix/restricted_senders

   permit_mynetworks
   reject_unauth_destination
   reject_unknown_sender_domain
   permit
smtpd_restriction_classes = local_only
local_only = check_recipient_access hash:/etc/postfix/local_domains, reject
...

/etc/postfix/restricted_senders:
...
[EMAIL PROTECTED]addr_class_1
[EMAIL PROTECTED]   addr_class_1
[EMAIL PROTECTED]addr_class_1
[EMAIL PROTECTED]   addr_class_1
...

/etc/postfix/local_domains:
mjc-idf.asso.fr   OK
gw.mjc-idf.asso.fr OK

/etc/postfix/addr_class_1:
mjc-idf.asso.fr  OK

--

What I have to add to restrict the received mail only from local domain 
for these users ?


Thanks in advance for your help.

Sam.



--
Sam Przyswa - Chef de projet
Email: [EMAIL PROTECTED]
Arial Concept - Intégrateur Internet
36, rue de Turin - 75008 - Paris - France
Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01
Fax privé: 09 57 12 27 22
Skype ID: arial-concept
Web: http://www.arial-concept.com 



--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
For all your IT requirements visit: http://www.transtec.co.uk

Restrict users to received outside mails

[Sam Przyswa]

Hi,

How to restrict users to received outside mail (from internet) but only 
from the local domain/network ?


Thanks in advance for your help.

Sam.



--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
For all your IT requirements visit: http://www.transtec.co.uk

Re: Restrict users to received outside mails

[Sam Przyswa]

mouss a écrit :

Sam Przyswa wrote:

Hi,

How to restrict users to received outside mail (from internet) but 
only from the local domain/network ?




If your goal is to restrict few addresses so that:

- they can only send mail to your own domains (domains in 
mydestination, virtual_*_domains and relay_domains).


- the addresses can only be used from mynetworks (outsiders may not 
use the address as sender or recipient)


then you can do it like this:

smtpd_restriction_classes =
...
internal_only
...

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/restricted_addr
check_recipient_access hash:/etc/postfix/restricted_addr

internal_only =
# they can't relay
reject_unauth_destination
# they can only be used from mynetworks
permit_mynetworks
reject

== restricted_addr
[EMAIL PROTECTED]internal_only
local.example.orginternal_only


if this is not what you want, explain your goal more clearly. it may 
be easier to give examples of what is allowed and what is not. if you 
can formulate the goal in a "mathematical logic" style (if blah and 
blah, then allow. if blah and blah then reject. ...), do that too.


So, I have some user:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

in class restricted_users

and I want these user, ONLY these users, able to send and receive mail
to others users on local network and only on @my.domain.com

1 - all user in local network and in domain @my.domain.com can
*send/receive* mail from everywhere.

2 - *restricted_users* DON'T send/receive mails from network except
$mynetworks AND NO *others domains* BUT @my.domain.com

The goal is to restrict *restricted_users* in *local mail only* in
company domain on the LAN area for security reasons.

Sam.




--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
For all your IT requirements visit: http://www.transtec.co.uk

Re: UCE and restriction classes

[Sam Przyswa]

mouss a écrit :

Sam Przyswa wrote:

Hi all,

I succeed to limit some local users to send mail only on my local 
domain, but I would like to limit the mail received ONLY from the 
local users too for these users,  no mails from internet (others 
domains).


There is my actual Postfix config:

/etc/postfix/main.cf:
...
smtpd_recipient_restrictions = check_sender_access 
hash:/etc/postfix/restricted_senders


this is wrong. see below.


   permit_mynetworks
   reject_unauth_destination
   reject_unknown_sender_domain
   permit
smtpd_restriction_classes = local_only
local_only = check_recipient_access hash:/etc/postfix/local_domains, 
reject

...

/etc/postfix/restricted_senders:
...
[EMAIL PROTECTED]addr_class_1
[EMAIL PROTECTED]   addr_class_1
[EMAIL PROTECTED]addr_class_1
[EMAIL PROTECTED]   addr_class_1
...

/etc/postfix/local_domains:
mjc-idf.asso.fr   OK
gw.mjc-idf.asso.fr OK

/etc/postfix/addr_class_1:
mjc-idf.asso.fr  OK




now, you are an open relay. any attackers who sends you mail from an 
address @mjc-idf... can use your system as a relay.


do never ever return OK in smtpd_recipient_restrictions before 
reject_unauth_destination based on information that the sender can 
forge. this include sender and helo.


use the following instead

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/restricted_senders

smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_unknown_sender_domain

an OK in smtpd_sender_restrictions will not skip 
smtpd_recipient_restrictions, so no open relay.


Argh [EMAIL PROTECTED]

Thanks a lot !





--

What I have to add to restrict the received mail only from local 
domain for these users ?




not clear what you mean by "from local domain"? ("domain" is 
ambiguous: is it the domain of the IP? is it the domain in the sender 
address?).


I need for the users below (in restricted_senders) that don't receive
mails from internet, from an other domain than mjc-idf.asso.fr and only
from $mynetworks.


if you only want mail from mynetworks, simply do

smtpd_recipient_restrictions =
permit_mynetworks
reject



Yes but for all others users I have to received mails from internet,
local domain and $mynetworks.

Thanks again.

Sam.




--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
For all your IT requirements visit: http://www.transtec.co.uk

Re: Mail Archiving

[Sam Przyswa]

We use MailScanner as spam and virus filter and the mail archiving and 
monitoring function to copy mails in dedicated  account, it is easy 
configurable with rules to copy mails in severals mails account, see 
http://www.mailscanner.info/


Sam.

Adam Tauno Williams a écrit :

On Mon, 2008-09-22 at 15:07 -0700, Chris St Denis wrote:
  

James wrote:

I was wondering if anyone here knew of a good way to duplicate emails 
for archival purposes.
What i want to do is use a gateway machine that will deliver mail to 
two machines.
one being an active imap/pop3 system and the other being a mail 
archival system
i was thinking that there might be something like editing the 
transport file to do that but that only allows a single destination 
per domain as far as i know.

Any help is appreciated,
Thanks
  

Try recipient_bcc_maps
http://www.postfix.org/postconf.5.html#recipient_bcc_maps



I do not believe this is sufficient for [legal] archive purposes;  it
does not appear to capture BCC recipients of the message.  An archive
milter is probably required to meet data retention requirements;  while
a few people claim to have such a milter no one has shared one to my
knowledge.

  


--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
For all your IT requirements visit: http://www.transtec.co.uk

Re: postfix.org site CSS change

[Sam Tuke]

> Any ideas why the background "to me" is now white when its been yellow for 
> years?

There's a smoker in the house and you recently changed screens?

-- Sam (cigars)

On 2 June 2021 19:40:31 CEST, post...@ptld.com wrote:
>> On 06-02-2021 1:35 pm, Josef Vybíhal wrote:
>> 
>>> the background was changed to white.
>> 
>> curl -sI http://www.postfix.org/postfix.css | grep Last
>> Last-Modified: Sun, 20 Feb 2011 12:14:00 GMT
>
>Any ideas why the background "to me" is now white when its been yellow 
>for years?
>I tried in both ff/edge browsers to make sure one browser wasn't acting
>
>strange.
>What color is the background to you?

Fwd: Issue with Postfix and GSSAPI Authentication

[Sam R]

Hello,

I want to set up a Postfix SMTP server with cyrus-sasl in GSSAPI mode. I
have two Samba4 servers in AD mode, and my clients are in windows 10.
I removed the execution of Posfix in chroot to simplify.
I added two keytab in /etc/krb5.keytab smtp/smtptest.domain.fr and host/
smtptest.domain.fr
Currently I can authenticate with windows credentials from a windows client
under Thunderbird with the "normal password" settings.
But if I try to switch from LOGIN to GSSAPI ( in
/etc/postfix/sasl/smtpd.conf ) it doesn't work.
Client side, here is the message I see in Thunderbird ( Sending of the
message failed.The Kerberos/GSSAPI ticket was not accepted by the Outgoing
server (SMTP). Please check that you are logged in to the Kerberos/GSSAPI
realm.)

And here is the output from /var/log/mail.log :

Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
master_notify: status 0
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: name_mask: resource
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: name_mask: software
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: connect from
unknown[192.168.128.253]
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: unknown: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: 192.168.128.253: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: unknown: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: 192.168.128.253: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
smtp_stream_setup: maxtime=300 enable_deadline=0
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_hostname: smtpd_client_event_limit_exceptions: unknown ~?
127.0.0.0/8
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_hostaddr: smtpd_client_event_limit_exceptions: 192.168.128.253
~? 127.0.0.0/8
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_hostname: smtpd_client_event_limit_exceptions: unknown ~?
192.168.128.0/24
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_hostaddr: smtpd_client_event_limit_exceptions: 192.168.128.253
~? 192.168.128.0/24
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 220 smtptest.domain.fr ESMTP Postfix
(Debian/GNU)
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
xsasl_cyrus_server_create: SASL service=smtp, realm=(null)
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: name_mask: noanonymous
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: <
unknown[192.168.128.253]: EHLO [172.20.4.195]
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: unknown: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]:
match_list_match: 192.168.128.253: no match
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-smtptest.domain.fr
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-PIPELINING
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-SIZE 1024
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-VRFY
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-ETRN
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-STARTTLS
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-AUTH GSSAPI
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-AUTH=GSSAPI
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-ENHANCEDSTATUSCODES
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-8BITMIME
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-DSN
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250-SMTPUTF8
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: >
unknown[192.168.128.253]: 250 CHUNKING
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: warning:
unknown[192.168.128.253]: request longer than 2048: AUTH GSSAPI
YIIG8AYJKoZIhvcSAQ...
Oct  1 10:58:35 smtptest postfix/submission/smtpd[61932]: <
unknown[192.168.128.253]: AUTH GSSAPI
YIIG8AYJKoZIhvcSAQICAQBuggbfMIIG26ADAgEFoQMCAQ6iBwMFACCjggUCYYIE/jCCBPqgAwIBBaEOGwxBUklBTkUuSU5UUkGiKjAooAMCAQKhITAfGwRzbXRwGxdzbXRwdGVzdC5hbGJlcnR2aWxsZS5mcqOCBLUwggSxoAMCARehAwIBAqKCBKMEggSfLDVrhA0h4uAhD4dLTjNmUF/kLPsdml9HzNKFV4mmZ36ha8iZz8pjYu9zd2AaWjUF6kb0Ii8lx7bf99JkjqTTANfUmfyNuNf0XdGRxNVD0u+7EdFGIR54yfvvxvN3sJQWFpqQhERMNCn6kWh5ZR6txInKbydJx32BgHIu/ZWPHfeGw5/7t6eeCuWMG6Yog2J4kdnYqnMb3gAL0tcR+HA57738B4w97fmPCIfKWAB0WKqObZky9l0+JXUTsza56+zuQbvO8eZ4OHuZNMvaHiAeTgqX/t+QZxrday+OAKPeJA0dyMc2ETj8ulFo4rTvqew0FK2d9dNiMa+q6mFudGkY7+pO1UtHO6gvJkkaEi9xVaPc1r/oIyfE/jb/x+wShn3ZZ6Xzk4cN+9rNMabph4KS97d

Re: Fwd: Issue with Postfix and GSSAPI Authentication

[Sam R]

Good morning Viktor,

Thank you for all this information, I will do the necessary for the keytabs
right away.
Concerning the clients, it is Thunderbird under Windows 10, the AD server
being Samba4. I will try to see why the Kerberos ticket is so long. I don't
think the problem is with Thunderbird but rather with Samba4. I'll check it
out.

In the meantime, if I understand correctly, I must either increase :
- smtpd_sasl_response_limit ( currently 2048 )
- line_length_limit ( currently 998 )
- smtpd_sasl_response_limit and line_length_limit

Samuel

Le ven. 1 oct. 2021 à 19:15, Viktor Dukhovni  a
écrit :

> On Fri, Oct 01, 2021 at 12:47:29PM -0400, Viktor Dukhovni wrote:
>
> > > -- basics --
> > > Postfix: 3.5.6
> >
> > Since you're using Postfix 3.5, which by default supports long SASL
> > messages after the initial response, your client is in violation of the
> > SMTP SASL specification, and needs to have a bug filed against its SASL
> > GSSAPI implementation.  If that client is also Postfix, file that bug
> > on this list.  If not, reach out on the relevant forum, or bug tracking
> > system.
>
> Note that I rather expect the broken client is not Postfix 3.4 or later,
> since the Postfix SMTP client code since then reads in part:
>
>
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_sasl_glue.c#L366-L388
>
> /*-
>  * Send the AUTH command and the optional initial client response.
>  *
>  * https://tools.ietf.org/html/rfc4954#page-4
>  * Note that the AUTH command is still subject to the line length
>  * limitations defined in [SMTP].  If use of the initial response
> argument
>  * would cause the AUTH command to exceed this length, the client MUST
> NOT
>  * use the initial response parameter...
>  *
>  * https://tools.ietf.org/html/rfc5321#section-4.5.3.1.4
>  * The maximum total length of a command line including the command
> word
>  * and the  is 512 octets.
>  *
>  * Defer the initial response if the resulting command exceeds the
> limit.
>  */
> if (LEN(session->sasl_reply) > 0
> && strlen(mechanism) + LEN(session->sasl_reply) + 8 <= 512) {
> smtp_chat_cmd(session, "AUTH %s %s", mechanism,
>   STR(session->sasl_reply));
> VSTRING_RESET(session->sasl_reply); /* no deferred initial
> reply */
> } else {
> smtp_chat_cmd(session, "AUTH %s", mechanism);
> }
>
> > You can accommodate broken clients by raising line_length_limit even
> > on Postfix >= 3.4 systems where this should not otherwise be necessary
> > in most cases.
>
> So this is your short-term solution, as well as filing bugs against the
> actual broken clients.
>
> --
> Viktor.
>

Re: Fwd: Issue with Postfix and GSSAPI Authentication

[Sam R]

Now it's working fine!

I finally succeeded. I worked around by increasing only the value of the
line_length_limit option to 12288 ( same value as the default for
smtpd_sasl_response_limit  )
And create a specific keytab file containing the SPN (
/etc/postfix/smtp.keytab )

But I haven't thought about why the Kerberos ticket size is too big. Maybe
I should ask the question about the samba list?

In any case thank you all!

Samuel

Le lun. 4 oct. 2021 à 09:37, Sam R  a écrit :

> Good morning Viktor,
>
> Thank you for all this information, I will do the necessary for the
> keytabs right away.
> Concerning the clients, it is Thunderbird under Windows 10, the AD server
> being Samba4. I will try to see why the Kerberos ticket is so long. I don't
> think the problem is with Thunderbird but rather with Samba4. I'll check it
> out.
>
> In the meantime, if I understand correctly, I must either increase :
> - smtpd_sasl_response_limit ( currently 2048 )
> - line_length_limit ( currently 998 )
> - smtpd_sasl_response_limit and line_length_limit
>
> Samuel
>
> Le ven. 1 oct. 2021 à 19:15, Viktor Dukhovni 
> a écrit :
>
>> On Fri, Oct 01, 2021 at 12:47:29PM -0400, Viktor Dukhovni wrote:
>>
>> > > -- basics --
>> > > Postfix: 3.5.6
>> >
>> > Since you're using Postfix 3.5, which by default supports long SASL
>> > messages after the initial response, your client is in violation of the
>> > SMTP SASL specification, and needs to have a bug filed against its SASL
>> > GSSAPI implementation.  If that client is also Postfix, file that bug
>> > on this list.  If not, reach out on the relevant forum, or bug tracking
>> > system.
>>
>> Note that I rather expect the broken client is not Postfix 3.4 or later,
>> since the Postfix SMTP client code since then reads in part:
>>
>>
>> https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_sasl_glue.c#L366-L388
>>
>> /*-
>>  * Send the AUTH command and the optional initial client response.
>>  *
>>  * https://tools.ietf.org/html/rfc4954#page-4
>>  * Note that the AUTH command is still subject to the line length
>>  * limitations defined in [SMTP].  If use of the initial response
>> argument
>>  * would cause the AUTH command to exceed this length, the client
>> MUST NOT
>>  * use the initial response parameter...
>>  *
>>  * https://tools.ietf.org/html/rfc5321#section-4.5.3.1.4
>>  * The maximum total length of a command line including the command
>> word
>>  * and the  is 512 octets.
>>  *
>>  * Defer the initial response if the resulting command exceeds the
>> limit.
>>  */
>> if (LEN(session->sasl_reply) > 0
>> && strlen(mechanism) + LEN(session->sasl_reply) + 8 <= 512) {
>> smtp_chat_cmd(session, "AUTH %s %s", mechanism,
>>   STR(session->sasl_reply));
>> VSTRING_RESET(session->sasl_reply); /* no deferred initial
>> reply */
>> } else {
>> smtp_chat_cmd(session, "AUTH %s", mechanism);
>> }
>>
>> > You can accommodate broken clients by raising line_length_limit even
>> > on Postfix >= 3.4 systems where this should not otherwise be necessary
>> > in most cases.
>>
>> So this is your short-term solution, as well as filing bugs against the
>> actual broken clients.
>>
>> --
>> Viktor.
>>
>

Re: Fwd: Issue with Postfix and GSSAPI Authentication

[Sam R]

Ok, Thank you for these useful clarifications

Samuel

Le lun. 4 oct. 2021 à 17:27, Viktor Dukhovni  a
écrit :

> On Mon, Oct 04, 2021 at 04:34:39PM +0200, Sam R wrote:
>
> > Now it's working fine!
> >
> > I finally succeeded. I worked around by increasing only the value of the
> > line_length_limit option to 12288 ( same value as the default for
> > smtpd_sasl_response_limit  )
>
> That's the right thing to do when the client is not honouring the
> initial response length limits of the SASL RFC.
>
> > And create a specific keytab file containing the SPN
> (/etc/postfix/smtp.keytab )
>
> That works, but I would put the file in ${data_directory} (typically
> somewhere under /var).  The files in /etc/postfix are all supposed to be
> root-owned.
>
> > But I haven't thought about why the Kerberos ticket size is too big.
> Maybe
> > I should ask the question about the samba list?
>
> That's normal for Windows AD and Samba, because tickets issued by
> Windows KDCs (and Samba which is just an implementation of the Windows
> server stack on Unix) contain a "PAC" with the full list of group SIDs
> the user belongs to.  These lists can be long.
>
> --
> Viktor.
>

Re: Assembling log entries for each SMTP session

[Sam Tuke]

On 21/12/2021 10:11, Nikolaos Milas wrote:

A quick question: Can you please suggest a software tool which
quickly "restructures" postfix mail log in a way that lines pertinent
to each and every SMTP session are assembled and kept together…

I think Lightmeter does what you want. It traces the entire history of each 
message and shows the history in a web-based viewer.

You can search for a given message by timeframe, sender, recipient, or Postfix ID, and 
see its history, using the included "Message detective". That's in version 2.0 
RC3. Older Lightmeter versions also provide tracing but with fewer search options. 
Screenshot: https://nextcloud.lightmeter.io/index.php/s/a2styNnAZ24NdQn

I work on Lightmeter so free to ask questions off-list. Sam.

SASL authentication question

[Sam R]

I have configured Postfix with Cyrus-sasl to send mail with Active
Directory authentication.
I'm very happy with the result, my users log in with a firstname.lastname
user and their Windows password.
But I have a router that needs to send mails and that has only one field
that is used for both the login and the sender's email address.
So here is my question, I am looking for a server equivalent to this client
option smtp_sasl_password_maps, to add in a file the adapted login.
Do you have an idea?
Samuel

send mail from the domain directly to the local server without going out to the Internet

[Sam R]

Hello to all,

I have several Postfix servers named MX, SMTP and MAIL on my dmz:
MX is used to receive mails to our "@domain.fr" from Internet
SMTP is used to send mails from "@domain.fr
MAIL is used as a storage server for "@domain.fr" mails

However, I would like to be able to for example directly transmit a mail to
"@domain.fr" from SMTP to MAIL without having to go out on the Internet.
Both to redirect mails from "@domain.fr" users and also for example to send
logwatch mails to a centralized address.

Currently I use the following settings:
transport_maps = hash:/etc/postfix/transport
domain.fr smtp:[192.168.X.X]:465
This works but I get the following Postfix message:
SMTPS wrappermode (TCP port 465) requires setting "smtp_tls_wrappermode =
yes", and "smtp_tls_security_level = encrypt" (or stronger)

If I put these additional settings, it doesn't work anymore because the
internal address of my servers doesn't match the certificate that is
created with the external addresses (I have a handshake failure)

So I am tempted to use this :
smtp_tls_policy_maps=hash:/etc/postfix/tls_policy
and in /etc/postfix/tls_policy :
domain.fr none

I think I can keep the encryption of the transmission between my servers,
without doing any certificate verification.

Does this seem correct to you? Or is there another method more suitable?

Thank you very much for your answers!

Samuel

Re: send mail from the domain directly to the local server without going out to the Internet

[Sam R]

Hello Noel,
As you suggest, I enabled TLS wrappermode on both senders servers and the
internal server, set  "smtp_tls_security_level =  encrypt " to senders
servers and it seems perfect now.
Thanks a lot Noel and Thank you all too!
Samuel

Le mer. 17 août 2022 à 17:42, Noel Jones  a écrit :

> On 8/17/2022 10:04 AM, Sam R wrote:
> >
> > Currently I use the following settings:
> > transport_maps = hash:/etc/postfix/transport
> > domain.fr <http://domain.fr> smtp:[192.168.X.X]:465
> > This works but I get the following Postfix message:
> > SMTPS wrappermode (TCP port 465) requires setting
> > "smtp_tls_wrappermode = yes", and "smtp_tls_security_level =
> > encrypt" (or stronger)
>
> Apparently you're sending plain text mail to port 465. Standard
> practice is for port 465 to use smtps TLS wrappermode.
>
> >
> > If I put these additional settings, it doesn't work anymore because
> > the internal address of my servers doesn't match the certificate
> > that is created with the external addresses (I have a handshake failure)
>
> This likely has nothing to do with certificate verification.
>
> Apparently the internal server isn't configured for TLS
> "wrappermode" on port 465 causing the delivery to fail when you turn
> on encryption.
>
>
> You have a couple of choices...
>
> - Configure the internal server to use TLS wrappermode on port 465,
> and enable wrappermode as the log warning suggests.
>
> - Use a different port, possibly 587. Likely the two systems will
> negotiate STARTTLS and send mail encrypted.
>
>
> If you need further help, share your "postconf -nf" and "postconf
> -Mf" and the actual log lines of both successful delivery and what
> happens after you add the -o smtp_tls_wrappermode=yes
> http://www.postfix.org/DEBUG_README.html#mail
>
>
>
>-- Noel Jones
>

Re: send mail from the domain directly to the local server without going out to the Internet

[Sam R]

 So I am a little divided,
On the one hand I think that port 25 is enough to transmit mails locally,
on the other hand I think that an encryption would be better, especially on
the dmz.
Also, I have 20 servers that send logwatch locally and I don't see myself
creating a tunnel for each of them.
Samuel

Le jeu. 18 août 2022 à 17:55, Jaroslaw Rafa  a écrit :

> Dnia 18.08.2022 o godz. 10:34:18 Demi Marie Obenour pisze:
> >
> > I recommend using client certificate authentication on port 465 instead.
> > IP addresses are not a strong form of authentication unless one is using
> > a secure VPN such as WireGuard.
>
> On an internal network, between one's own servers?
>
> > Also one should be encrypting traffic
> > anyway as a matter of best practice.
>
> Use of port 25 (or any other port) does not exclude encryption.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
>

Re: send mail from the domain directly to the local server without going out to the Internet

[Sam R]

Understood, I adopt the communication in starttls port 25 between my
servers.
Thanks again to all.
Samuel

Le ven. 19 août 2022 à 13:09, Matus UHLAR - fantomas  a
écrit :

> On 19.08.22 10:47, Sam R wrote:
> > So I am a little divided,
> >On the one hand I think that port 25 is enough to transmit mails locally,
>
> I guess by "locally" you mean "on the local network".
>
> port 25 is standard for server-server communication, 465/587 are standard
> for client-server communication where authentication is required/enforced.
>
> >on the other hand I think that an encryption would be better, especially
> on
> >the dmz.
>
> I'd say "especially for connections crossing not-secured network".
> mails within LAN/DMZ should be safe unencrypted, unless you have reason
> not
> to trust the network or someone on it.
>
> you still can use encryption on port 25 using the STARTTLS mechanizm.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> There's a long-standing bug relating to the x86 architecture that
> allows you to install Windows.   -- Matthew D. Fuller
>

Port 25 closed on bulk sending servers

[Sam Tuke]

I noticed that newsletters which I receive from large firms are typically sent 
from servers which have port 25 closed.

Is it common practice to close port 25 on bulk sending servers? Should we do 
this for Postfix servers which serve the same role? What's the advantage?

Maybe the MTAs that such senders use are so customised as to be capable of only 
sending, not receiving, mail?

Thanks!

Sam.

Re: Port 25 closed on bulk sending servers

[Sam Tuke]

Thank you all for your insightful replies.

Sam.

On 15/01/2020 15:24, Bill Cole wrote:
> On 15 Jan 2020, at 7:56, Sam Tuke wrote:
>
>> I noticed that newsletters which I receive from large firms are typically 
>> sent from servers which have port 25 closed.
>>
>> Is it common practice to close port 25 on bulk sending servers?
>
> Yes, and not only for bulk sending servers.
>
>> Should we do this for Postfix servers which serve the same role? What's the 
>> advantage?
>
> It is quite common for inbound and outbound email to be handled by separate 
> systems. In environments using internal mail servers that aren't good at spam 
> exclusion and/or have a general pattern of chronic insecurity (e.g. Exchange) 
> it is not uncommon to have them sending outbound mail from behind a very 
> strict firewall and/or NAT with no listeners exposed to the world and to 
> receive via a more robust platform for dealing with mail from the Internet.
>
>> Maybe the MTAs that such senders use are so customised as to be capable of 
>> only sending, not receiving, mail?
>
> There's some of that for very large senders, but in the modern age of almost 
> everything being virtual, it is also just simpler to disperse essentially 
> independent functions onto independent systems, with each specifically 
> configured and scaled to their role. In DNS this has meant splitting 
> authoritative servers and resolvers. In email this has meant a more diverse 
> split, with public MXs, initial mail submission handlers, outbound queue 
> handlers, mailstore management & access, and internal distribution 
> potentially being autonomous systems. This can simplify the configuration of 
> each system and make securing them less challenging.
>

Re: Is there a library for validating gmail's Variants

[Sam Tuke]

I see the value of the ability to recognise such Gmail address variants, and 
would use it myself to prevent people trivially working around Gmail addresses 
being on a blacklist email receipt or for service signup.

Sam.


On 30/04/2020 09:27, Walter Peng wrote:
> Hello community,
>
> We are running a small website which allow users registration with their
> email.
>
> Many users use gmail's variants to sign up the site, as we know,
> foo...@gmail.com is equivalent to below similar:
>
> foo...@googlemail.com
> foob...@googlemail.com
> foo@gmail.com
> foobar+...@gmail.com
> foo.bar+m...@gmail.com
> ...
>
> Is there a library existing to validate all those variants to make sure
> they are exactly the same account?
>
> Thanks.

Re: thanks and a little bit question

[Sam Tuke]

Here the source code repo: 

https://github.com/vdukhovni/postfix

Merry Christmas and a happy new year,

Sam.

On 13 December 2020 12:19:22 CET, "황병희"  wrote:
>Hellow i'm pleasure to using Postfix which runs at my personal Google
>Cloud Platform. So i'm interested in somewhat internal things about
>Postfix. Where is the main reposiotry, GitLab? or Other server?
>
>Thanks for any comments welcome!
>
>Sincerley, Postfix user Byung-Hee
>
>-- 
>^고맙습니다 _布德天下_ 감사합니다_^))//

Re: postfix filter to encrypt incoming emails with public gpg key

[Sam Tuke]

As well as fetching the public key, it'd need access to a private key too. I 
think the private key is considered the bigger problem, for various reasons.

There have been a few attempts addressing the needs of this complex use case. 
AFAICS none have been successful, but I'm out of date. 

See the (abandoned?) STEED project and their whitepaper: 
https://g10code.com/steed.html. That is by g10code - the creator of GPG. 
Disclaimer: I once worked for them.

Sam.

On 27 October 2019 07:27:53 CET, lists  wrote:
>Let me try again. So the email comes in. Some programs gets your public
>key and then encrypts the email on the server. Then when you retrieve
>your email, it sends it out in what it believes is plain text or for
>that matter can to TLS on the file, but you get a GPG message that you
>then decrypt. 
>
>So the reason this isn't normally done is a general purpose email
>server would have to do this on  per client basis, somehow getting the
>proper public key for each client. 
>
>Am I right? Close? 
>
>If not I will shut up and wait for a guru to reply. 
>
>
>
>
>
>
>     Original Message  
>
>
>
>From: 400the...@gmx.ch
>Sent: October 26, 2019 10:46 PM
>To: postfix-users@postfix.org
>Subject: Re: postfix filter to encrypt incoming emails with public gpg
>key
>
>
>On 27/10/2019 06.26, lists wrote:
>> My bank insists I use their website for anything secure. I don't get
>anything in my email that would be a security problem.
>
>I used bank just as an example. Feel free to substitute another
>scenario, if you find mine hard to imagine.
>
>> Wouldn't a private key have to be held on your server to do what you
>want? If so, that hacker can get the key.
>
>No. Definitely not.
>Only public key is needed for asymmetric encryption.
>
>> Personally I would harden the server. It sounds like this is a
>private server. You can use the firewall to vastly limit the countries
>where your email can be retrieved. That is filter the hell out of all
>email ports except 25. Besides filtering countries, I have a file of
>about 30k of ipv4 cidrs from data centers that I block from all email
>ports except 25 and all the web ports. No eyeballs in datacenters.
>
>Sure, I want to have both:
>A secure server, AND encrypted emails. What is wrong with that ?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[pfx] Build errors with upcoming GCC 15 (defaults to -std=gnu23)

[Sam James via Postfix-users]

Hi,

Apologies if this was reported already.

Upcoming GCC 15 defaults to -std=gnu23 with which Postfix fails to build.

As reported at https://bugs.gentoo.org/945733, with postfix-3.9.0, we
get:
```
[...]
x86_64-pc-linux-gnu-gcc -fPIC -I. -I../../include -DHAS_PCRE=2 -DUSE_TLS 
-DNO_NIS -DHAS_DEV_URANDOM 
-DDEF_SHLIB_DIR=\"/usr/lib64/postfix/\${mail_version}\" -DUSE_DYNAMIC_LIBS 
-UUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fno-common -fPIC 
 -O2 -march=x86-64 -fpermissive -pipe -pipe -frecord-gcc-switches 
-fno-diagnostics-color -fmessage-length=0 -I. -I../../include -DLINUX6 -c 
file_id.c
In file included from debug_peer.c:69:
./mail_params.h:17:13: error: two or more data types in declaration specifiers
   17 | typedef int bool;
  | ^~~~
./mail_params.h:17:1: warning: useless type name in empty declaration
   17 | typedef int bool;
  | ^~~
In file included from defer.c:176:
./mail_params.h:17:13: error: two or more data types in declaration specifiers
   17 | typedef int bool;
  | ^~~~
./mail_params.h:17:1: warning: useless type name in empty declaration
   17 | typedef int bool;
  | ^~~
[...]
```

thanks,
sam
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Build errors with upcoming GCC 15 (defaults to -std=gnu23)

[Sam James via Postfix-users]

Wietse Venema via Postfix-users  writes:

> Sam James via Postfix-users:
>> Hi,
>> 
>> Apologies if this was reported already.
>> 
>> Upcoming GCC 15 defaults to -std=gnu23 with which Postfix fails to build.
>> 
>> As reported at https://bugs.gentoo.org/945733, with postfix-3.9.0, we
>> get:
>> ./mail_params.h:17:13: error: two or more data types in declaration 
>> specifiers
>>17 | typedef int bool;
>
> Will Postfix build if you replace that line with:
>
> #define bool int

Yeah, builds fine with that, although it may lead to confusion given the
built-in bool and int are different.

thanks,
sam
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Build errors with upcoming GCC 15 (defaults to -std=gnu23)

[Sam James via Postfix-users]

Wietse Venema via Postfix-users  writes:

> Sam James via Postfix-users:
>> Wietse Venema via Postfix-users  writes:
>> 
>> > Sam James via Postfix-users:
>> >> Hi,
>> >> 
>> >> Apologies if this was reported already.
>> >> 
>> >> Upcoming GCC 15 defaults to -std=gnu23 with which Postfix fails to build.
>> >> 
>> >> As reported at https://bugs.gentoo.org/945733, with postfix-3.9.0, we
>> >> get:
>> >> ./mail_params.h:17:13: error: two or more data types in declaration 
>> >> specifiers
>> >>17 | typedef int bool;
>> >
>> > Will Postfix build if you replace that line with:
>> >
>> > #define bool int
>> 
>> Yeah, builds fine with that, although it may lead to confusion given the
>> built-in bool and int are different.
>
> Not until Postfix has to set, or act on, new bool values in system
> or third-party APIs.
>
> There will be some time to rename the Postfix 3.10 internal bool
> type before it becomes the next stable release.
>
> For the existing stable Postfix versions, you may have override
> compiler options.
>

Thank you Wietse, I'll build with -std=gnu17 for now.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: gcc-15 support?

[Sam James via Postfix-users]

Wietse Venema via Postfix-users  writes:

> Sam James via Postfix-users:
>> Jaroslav ?karvada via Postfix-users  writes:
>> > In Fedora downstream we compile it now with the explicit -std=gnu17,
>> > but maybe it could be handled by type rename, stdbool, or preprocessor
>> > conditionals
>> 
>> (Please be careful when suggesting that, as the safety of it depends on
>> if the value escapes to disk / in an API or not.)
>
> There can be no Postfix 'bool' value that is visible to non-Postfix
> code (via function calls or via I/O). For reasons that should be
> obvious to anyone, (the C23 'bool' type did not exist prior to C23),
> Postfix 'bool' is necessarily an internal data type only.

I understand. I was asking Jaroslav keep this in mind when making the
suggestion in general to projects when reporting these bugs.

>
> The fix is to simply use a different name and move on. I have already
> verified that the compiler produces identical output.
>
> There is a non-Postfix 'bool' value in the MondgDB client, and that
> is fine.
>
>   Wietse
>
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: gcc-15 support?

[Sam James via Postfix-users]

Jaroslav Škarvada via Postfix-users  writes:

> Hi,
>
> gcc-15 defaults to the C23 standard which introduces new keyword
> "bool" and postfix compilation fails:
>
> In file included from anvil_clnt.c:165:
> ./mail_params.h:17:13: error: ‘bool’ cannot be defined via ‘typedef’
>17 | typedef int bool;
>   | ^~~~
> ./mail_params.h:17:13: note: ‘bool’ is a keyword with ‘-std=c23’ onwards
> ./mail_params.h:17:1: warning: useless type name in empty declaration
>17 | typedef int bool;
>   | ^~~
>
> In Fedora downstream we compile it now with the explicit -std=gnu17,
> but maybe it could be handled by type rename, stdbool, or preprocessor
> conditionals

(Please be careful when suggesting that, as the safety of it depends on
if the value escapes to disk / in an API or not.)

Anyway, see https://marc.info/?l=postfix-users&m=173540326904986&w=2.

>
> thanks & regards
>
> Jaroslav
>
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org