server not accepting outgoing mail

[Michael Schumacher]

Hi,

our mail server is running nicely for years. There is one recipients server 
that doesn't accept our mails with a "time out" response without sending a more 
detailed error message. I have attached the -v log output, but only the part 
that is produced by the smtp-process at sending to this recipient. I have also 
replaced the recipients name with the term "recipient", but left the mail 
server domain unchanged.

Any idea what might cause this problem?

Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: inet_addr_local: configured 
4 IPv4 addresses
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: inet_addr_local: configured 
4 IPv6 addresses
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: process generation: 5721 
(5721)
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: match_string: 
parent_domain_matches_subdomains: debug_peer_list ~? debug_peer_list
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: name_mask: 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: auto_clnt_create: 
transport=local endpoint=private/tlsmgr
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: auto_clnt_open: connected to 
private/tlsmgr
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: send attr request = seed
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: send attr size = 32
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: status
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: status
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: seed
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: seed
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 
7QLOqsbbZLYu9LTNy4OxLcxs5vPFcA8ocxXm+PThf24=
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: (list terminator)
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: (end)
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: send attr request = policy
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: send attr cache_type = smtp
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: status
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: status
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: cachable
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: 
cachable
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: timeout
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: timeout
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 3600
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: private/tlsmgr: wanted 
attribute: (list terminator)
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: (end)
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: match_string: 
parent_domain_matches_subdomains: fast_flush_domains ~? debug_peer_list
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: match_string: 
parent_domain_matches_subdomains: fast_flush_domains ~? fast_flush_domains
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: name_mask: canonical
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: name_mask: virtual
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: name_mask: dns
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: host name lookup methods: dns
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: auto_clnt_create: 
transport=local endpoint=private/scache
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: connection established
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: master_notify: status 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: deliver_request_initial: 
send initial status
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: send attr status = 0
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: smtp socket: wanted 
attribute: flags
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: flags
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 3
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: smtp socket: wanted 
attribute: queue_name
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: 
queue_name
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: active
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: smtp socket: wanted 
attribute: queue_id
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute name: 
queue_id
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: input attribute value: 
0C97F101A5168
Jan 13 12:57:43 mailserver3 postfix/smtp[3037980]: smtp socket: wanted 
attribute: offset
Jan 13 12:57:43 mailserver3 postfi

Re: make transport decisions based on headers not envelope

[Wietse Venema]

Sean Hennessey:
> I was using the sender_dependent_default_transport_maps to pick
> off what I thought was going to be the interesting from domain.
> The good news is that this mail is coming from customer applications.
> It's not coming from regular user mail clients. So I can guarantee
> there is going to be a single from header. The recipients are also
> never local. This machine is a pure relay.
> 
> Looks like it's time to learn me some milter. Can you recommend
> any good places to start on walking me through building one. I've
> got a programming background, so coding doesn't scare me.
> 
> Thanks again.

There are language bindings for C, Perl, Python, Rust, ..., and even PHP.
So there will likely be one that you wuold be comfortable with.

These implement something similar to the Sendmail reference API:

http://www.elandsys.com/resources/sendmail/libmilter/api.html

Wietse

Re: server not accepting outgoing mail

[Wietse Venema]

Michael Schumacher:
> Hi,
> 
> our mail server is running nicely for years. There is one recipients server 
> that doesn't accept our mails with a "time out" response without sending a 
> more detailed error message. I have attached the -v log output, but only the 
> part that is produced by the smtp-process at sending to this recipient. I 
> have also replaced the recipients name with the term "recipient", but left 
> the mail server domain unchanged.
> 
> Any idea what might cause this problem?

This needs no steenkeeng verbose logs; default logging is enough.

Jan 13 12:58:43 mailserver3 postfix/smtp[3037980]: 0C97F101A5168: 
to=, relay=none, delay=381463, 
delays=381403/0.02/60/0, dsn=4.4.1, status=deferred (connect to 
mail-d.exxonmobil.com[158.26.70.19]:25: Connection timed out)

Your TCP is unable to reach 158.26.70.19 (it works for me). Either
they don't like you, or it could be a local problem at your end
including an incorrect netmask setting.

Wietse

Re: Replacing initial "Received:" line on submission?

[Rob McGee]

On 1/13/2023 12:02 AM, Benny Pedersen wrote:

Jaroslaw Rafa skrev den 2023-01-12 21:52:

Dnia 12.01.2023 o godz. 13:49:33 post...@ptld.com pisze:

My solution...

main.cf:
    smtp_header_checks = pcre:/etc/postfix/header_checks_smtp


/etc/postfix/header_checks_smtp:
    /^Received:/   IGNORE
    /^X-Originating-Ip:/   IGNORE


If you do it in master.cf for submission services only, it my be OK. 


No, you can't set smtp_* options for smtpd(8) instances. You need 
another cleanup(8) instance and point to the cleanup_service_name in 
your options for submission.


https://www.postfix.org/postconf.5.html#cleanup_service_name


smtp_header_checks < is outbound
header_checks < is inbound


Yes, smtp_header_checks is for outbound only (controlling the behavior 
of the smtp(8) service.)


No, header_checks controls the cleanup service, and thus is applied 
globally, except where cleanup_service_name is pointing to a different 
cleanup instance.

--
   http://rob0.nodns4.us/

relay transport ignore

[Matteo Cazzador]

Hi, i 've  question, i need to migrate a virtual domain from 2 server 
(with postfix).


On the new server i define mail users and domain but it'isnt in 
production now dns record defined.


On the same new soerver i've other virtual domain.

I want that , for a few days, if one user of other domain hosted on the 
same new server send an email to the new migrate domain it will be 
relayed to the orld server and not locally delivered.


I try with transport without success.

Can someone plese help me?

Thanks

--

Rispetta l'ambiente: se non ti è necessario,  non stampare questa mail.


Le informazioni contenute in questa e-mail e nei files eventualmente
allegati sono destinate unicamente ai destinatari della stessa
e sono da considerarsi strettamente riservate.
E' proibito copiare, salvare, utilizzare,  inoltrare a terzi e diffondere
il contenuto della presente senza il preventivo consenso, ai sensi
dell'articolo 616 c.p. e della Legge n. 196/2003.
Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo
immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto
senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**



smime.p7s
Description: Firma crittografica S/MIME

Re: Replacing initial "Received:" line on submission?

[Gerald Galster]

>>> 192.0.2.1:submission inet n -   n   -   -   smtpd
>>> -o syslog_name=vpnsubmission
>>> -o smtpd_sasl_auth_enable=no
>>> -o
>>> smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination
>>   -o header_checks=pcre:/etc/postfix/vpn_header_checks
> 
> header_checks is not outbound

Sorry, header_checks is not an smtpd option but it is possible using
cleanup_service_name as Rob pointed out. Here is an example:

https://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission
(Configuring different header/body checks for MX service and submission service)

Global header_checks works for me because the used regular expression
matches hostname and ESMTPSA submission only and does not interfere otherwise.

Best regards
Gerald

Two internal servers, two inside fqdns, one outside fqdn

[Gerben Wierda]

I have created a second postfix server in my LAN. The idea is to use both in a 
failover/loadbalancing setting for now. At the back are two dovecots that 
replicate to each other.

When mail is sent out via my router, it picks up anything that goes out to port 
25 and makes sure it comes from mail.rna.nl (source NAT).

In the single mail server, I have:

main.cf:myhostname = mail.rna.nl

which creates a HELO that fits the reverse DNS of mail.rna.nl because of that 
source NAT. That works.

But now I have two mail servers, say, internally they are called a.rna.nl and 
b.rna.nl

I can have both configured like this:

main.cf:myhostname = mail.rna.nl

or I can have both configured like this:

main.cf:myhostname = a.rna.nl
main.cf:smtp_helo_name = mail.rna.nl

is there a reason to do one or the other?

Gerben Wierda (LinkedIn )
R&A IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: none SRS issues

[Matus UHLAR - fantomas]

On 12.01.23 18:24, Emmanuel Fusté wrote:
For to address the forwarding problem, you should add ARC to the 
sending and verifying stack, It was designed specifically for that, 
but not widely used, it is pretty experimental.


ARC requires you to trust ARC signer as it is third party. 


--
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.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

Re: Replacing initial "Received:" line on submission?

[Steffen Nurpmeso]

Hello!!

Gerald Galster wrote in
 :
 |>>> 192.0.2.1:submission inet n -   n   -   -   smtpd
 |>>> -o syslog_name=vpnsubmission
 |>>> -o smtpd_sasl_auth_enable=no
 |>>> -o
 |>>> smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination
 |>>   -o header_checks=pcre:/etc/postfix/vpn_header_checks
 |> 
 |> header_checks is not outbound
 |
 |Sorry, header_checks is not an smtpd option but it is possible using
 |cleanup_service_name as Rob pointed out. Here is an example:
 |
 |https://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission
 |(Configuring different header/body checks for MX service and submission \
 |service)

README_FILES/BUILTIN_FILTER_README was a *fantastic* hint, thank
you very much!  Well i now have to start two (!) new services, but
with the following in master.cf

  192.0.2.1:submission inet n -   n   -   -   smtpd
  -o syslog_name=vpnsub
  -o smtpd_sasl_auth_enable=no
  -o 
smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination
  -o cleanup_service_name=vpnsub_cleanup
  vpnsub_cleanup   unix  n   -   n   -   0   cleanup
  -o {header_checks=regexp:{{/^Received:/ IGNORE}}}

it really seems to work out!

 |Global header_checks works for me because the used regular expression
 |matches hostname and ESMTPSA submission only and does not interfere \
 |otherwise.
 |
 |Best regards
 |Gerald

Thank you very much.

Ciao!

 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: make transport decisions based on headers not envelope

[Viktor Dukhovni]

On Fri, Jan 13, 2023 at 05:36:16AM +, Sean Hennessey wrote:

> I was using the sender_dependent_default_transport_maps to pick off
> what I thought was going to be the interesting from domain. The good
> news is that this mail is coming from customer applications. It's not
> coming from regular user mail clients. So I can guarantee there is
> going to be a single from header. The recipients are also never local.
> This machine is a pure relay.
> 
> Looks like it's time to learn me some milter. Can you recommend any
> good places to start on walking me through building one. I've got a
> programming background, so coding doesn't scare me.

I found the Python "Milter" module quite easy to use.  

FWIW, you don't strictly need milters if all you is something equivalent
to a regex match on the "From:" header, header_checks can do that, BUT:

* With a milter you get an address parser, not just regular
  expressions, so that:

From: "" 

  parses correctly.

* With a milter you can add logic to deal with missing headers,
  multiple addresses, ... and perhaps also inspect the client
  IP address or SASL id, ...

So do use a milter, but do it right.  A crude regex check doesn't count.

-- 
Viktor.

Re: Replacing initial "Received:" line on submission?

[Peter]

On 13/01/23 08:40, Viktor Dukhovni wrote:

On Thu, Jan 12, 2023 at 01:49:33PM -0500, post...@ptld.com wrote:


My solution...

main.cf:
  smtp_header_checks = pcre:/etc/postfix/header_checks_smtp


/etc/postfix/header_checks_smtp:
  /^Received:/   IGNORE
  /^X-Originating-Ip:/   IGNORE


That's a rather radical "solution".  More typically one would just drop
"Received" headers known to be added by the local MTA (matching the
hostnname in "by" clause explicitly).  As for "X-Originating-Ip:", if
you're the one not adding it, why remove it?  And if you are adding it,
then why, if only to remove it?


Perhaps:

/^(Received:.*)192\.168\.1\.2(.*)$/ REPLACE ${1}127.0.0.2${2}

Substitute your server's IP address for 192\.168\.1\.2 above, and it 
should replace that IP with 127.0.0.2 in any Received headers.  Since 
you're explicitly telling it to only match and replace the exact IP 
address of your server the rest of the header should remain intact and 
troubleshooting should still be relatively easy.  Note that I explicitly 
used 127.0.0.2 for the IP address to replace with since it's a 
legitimate loopback address, but it's easy to identify it as the one 
that got replaced because other references to the loopback address will 
be 127.0.0.1.  Modify to suit.



Peter

Queue postfix sending when on failover WAN

[Simon Wilson]

This is I suspect a little off-topic for here, in which case accept my  
apologies please.


My Postfix instance is well-established on a LAN behind a WAN IP with  
a decent reputation. The internet router for the network has a 4G  
failover device for occasional downtime to ensure that critical comms  
can still be routed to the internet, e.g. security system  
notifications (not over email).


When the router fails over, postfix's default route to the internet  
still goes through the same gateway IP and the internet is accessible  
- but now postfix sees the world through the router getting to the  
internet via a non-static IP, not reversible DNS, etc.; I'd like it to  
not send anything but queue until the standard route returns.


Is there a postfix way to do this? Or should I be looking at  
lower-level network routing configuration for the server running  
postfix?


Thanks for any ideas.


--
Simon Wilson
M: 0400 12 11 16