Re: sender_canonical_maps for incoming e-mails
El 2016-01-19 18:37, wie...@porcupine.org escribió:
Nicol?s:
Hi,
We have a filter located outside our organization for outgoing mail
which rewrites the Return-Path to their domain, in the form:
username=abc@theirdomain.com. Once the filter processes the
message,
it's forwarded to the destination where these headers are received:
Return-Path: username=abc@theirdomain.com
From: Foo
This destination instance also has this configuration for Postfix:
sender_canonical_maps = regexp:/etc/postfix/sender_canonical_maps
sender_canonical_maps:
/^(.*)@abc.com$/ ${1}@xyz.com
What I want to achieve is rewriting sender address when it's received
from a specific domain (concretely, abc.com). As per the
sender_canonical_maps documentation: Optional address mapping lookup
tables for envelope and header sender addresses.
I know the Return-Path doesn't match the regexp, but I believe the
From
header does. Why it's not rewritten to usern...@xyz.com? Am I missing
something?
FWIW, this is Postfix v. 2.9.6-1.
By default, Postfix does not rewrite headers from remote clients.
The idea is to avoid breaking DKIM signatures. This is controlled
with local_header_rewrite_clients.
You may need to specify:
local_header_rewrite_clients = static:all
Or some other suitable filter.
Wietse
Thanks, that did the trick.
I'm confused about the following, however. As documented, default value
for local_header_rewrite_clients is permit_inet_interfaces. In our case,
inet_interfaces = all.
Why does setting static:all explicitly make a difference here?
Regards,
Nicolás
Re: sender based mail routing
On Mon, Jan 18, 2016 at 12:25:12PM -0500, Wietse Venema wrote: > The Postfix SMTP client uses the name from sender_dependent_relayhost_maps > for MX lookups (A lookups if the name is inside []). > > The Postfix SMTP client will not consider other names unless your > DNS provider lies, or you made other configuration changes that > cause Postfix to consider other names (for example, smtp_fallback_relay). You are right. I'd been looking into log files way too long that other day. Which leaves the other part of the question: is there a way to use multiple target adresses? Obviously one could set up special MX records, but I would feel much more comfortable if there would be a way to achieve that within postfix. -- Christian Recktenwald postfix-users-d...@citecs.de
lmtp: transport unavailable
Hi all, I'm trying to configure postfix for lmtp local delivery - delivery fails with "transport unavailable" however. lmtpd ist dovecot-lmtp, which works, I can send mail using smtp-source. Google did only find me questions about "pipe to dovecot"-style delivery, due to lmtp being in config files anyway. Could anyone give me a hand? This is a debian stretch(testing) system with postfix 2.11.3, lmtpd ist dovecot 2.2.18. Relevant commands, logs, config excerpts: master.cf: > lmtp unix - - - - - lmtp appending -v to lmtp does not change log output main.cf: > mailbox_transport = lmtp:unix:private/dovecot-lmtp > virtual_transport = lmtp:unix:private/dovecot-lmtp # ls /var/spool/postfix/private/dovecot-lmtp -l srw--- 1 postfix postfix 0 Jan 20 10:24 /var/spool/postfix/private/dovecot-lmtp # smtp-source -L -l 1000 -m 1 -M sanusi.ch -f ar...@sanusi.ch -t ar...@semioptimal.net unix:/var/spool/postfix/private/dovecot-lmtp ^ works -can fetch the mail with IMAP /var/log/mail.log: > Jan 20 11:31:40 chichak postfix/error[31253]: 6716E6A79: > to=, orig_to=, relay=none, > delay=0.42, delays=0.37/0/0/0.04, dsn=4.3.0, status=deferred (mail transport > unavailable) thank you, arian signature.asc Description: OpenPGP digital signature
Re: lmtp: transport unavailable
Arian Sanusi: > /var/log/mail.log: > > Jan 20 11:31:40 chichak postfix/error[31253]: 6716E6A79: > > to=, orig_to=, relay=none, > > delay=0.42, delays=0.37/0/0/0.04, dsn=4.3.0, status=deferred (mail > > transport unavailable) > You need to look earlier in the logfile. Look for fatal or warning records. Wietse
Re: sender_canonical_maps for incoming e-mails
nico...@devels.es: > > You may need to specify: > > > > local_header_rewrite_clients = static:all > > > > Or some other suitable filter. > > > > Wietse > > Thanks, that did the trick. > > I'm confused about the following, however. As documented, default value > for local_header_rewrite_clients is permit_inet_interfaces. In our case, > inet_interfaces = all. > > Why does setting static:all explicitly make a difference here? "static:all" matches everything (see man 1 postconf). For other details see http://www.postfix.org/postconf.5.html#local_header_rewrite_clients Wietse
Re: lmtp: transport unavailable
> You need to look earlier in the logfile. Look for fatal or warning > records. Just did - the only thing that's there is not helpful to me, either: Jan 20 11:31:40 chichak postfix/qmgr[31189]: warning: connect to transport private/local: Connec tion refused signature.asc Description: OpenPGP digital signature
Re: sender based mail routing
Christian Recktenwald:
> is there a way to use multiple target adresses?
Actually, your question is about *prioritized* addresses. For
equal-preference addresses you can use /etc/hosts with multiple
records per name, or Postfix 3.0 builtin idiom based on pipemap:,
inline: and randmap:
/etc/postfix/main.cf:
transport_maps =
pipemap:{
inline:{example.com=x},
randmap:{[mx1.example.com], [mx2.example.com]}
}
pipemap:{
inline:{example.net=x},
randmap:{[mx1.example.net], [mx2.example.net]}
}
Details in "man 1 postconf".
> Obviously one could set up special MX records,
> but I would feel much more netfortable if there
> would be a way to achieve that within postfix.
MX records are good enough for sending mail to the whole internet;
they can therefore also cover your corner of it.
Wietse
Enforcing strict TLS servers validations possible?
Hi there! I've spent several hours trying to get it right, but seems I'm not getting much to anywhere, so I finally wanted to check whether I was doing something wrong or what. Given the circumstances, I wanted to validate a remote TLS-enabled smtpd certificate before sending any email at all. I know this is not optimal for not-breaking-the-whole-world, but for this particular installation I'm trying to avoid MITM/impersonation/etc without the use of SASL or any kind of user/password mechanism. I've deployed both servers and clients with certificates that are verified correctly using the proper CA keyring and enforced both smtp_tls_security_level and smtpd_tls_security_level to encrypt, enabled smtpd_tls_auth_only smtpd_tls_ask_ccert, between others. Behavior remains the same for both client and remote server: the client mentions a Trusted TLS connection and the remote server keeps saying Anonymous TLS connection all the time. I went further more and manipulated clients TLS certificate so the private key mismatches the public certificate. Nothing is noticed at all, which is the thing that worries me the most. This is server installation TLS debug: Jan 20 10:03:33 server postfix/smtpd[25860]: connect from client[client_ip] Jan 20 10:03:33 server postfix/smtpd[25860]: setting up TLS connection from client[client_ip] Jan 20 10:03:33 server postfix/smtpd[25860]: client[client_ip]: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL" Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:before/accept initialization Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: client[client_ip]: Issuing session ticket, key expiration: DATE Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: SSL_accept:unknown state Jan 20 10:03:33 server postfix/smtpd[25860]: Anonymous TLS connection established from client[client_ip]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) As for the client, this is it: Jan 20 10:06:50 client postfix/smtp[24904]: initializing the client-side TLS engine Jan 20 10:06:50 client postfix/smtp[24904]: setting up TLS connection to server[ip] Jan 20 10:06:50 client postfix/smtp[24904]: server[ip]: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!eNULL" Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:before/connect initialization Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:SSLv2/v3 write client hello A Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: server[ip]: depth=1 verify=1 subject=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=supp...@cacert.org Jan 20 10:06:50 client postfix/smtp[24904]: server[ip]: depth=0 verify=1 subject=/CN=serverfqdn Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:50 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:51 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:51 client postfix/smtp[24904]: SSL_connect:unknown state Jan 20 10:06:51 client postfix/smtp[24904]: server[ip]: subject_CN=serverfqdn, issuer_CN=CA Cert Signing Authority, fingerprint=FINGERPRINT, pkey_fingerprint=FINGERPRINT2 Jan 20 10:06:51 client postfix/smtp[24904]: Trusted TLS connection established to server[ip]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) This appears to be just one piece of the cake thou, because, as I mention, Anonymous connections are still allowed (even with forged client keys). Is there any possible scenario in which postfix can validate a remote smtpd installation making use of a TLS deploy? Thanks in advance! Cheers, Dererk --
Re: lmtp: transport unavailable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.01.2016 um 12:18 schrieb Arian Sanusi: > >> You need to look earlier in the logfile. Look for fatal or >> warning records. > > Just did - the only thing that's there is not helpful to me, > either: Jan 20 11:31:40 chichak postfix/qmgr[31189]: warning: > connect to transport private/local: Connec tion refused > Looks like lack of rights or wrong path. Did you run your smtp-source test as user postfix? BTW - what user is your dovecot running with? What makes you shure, postfix will try to use /var/spool/postfix/private/dovecot-lmtp? Willi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlafijMACgkQ3fC18neDqYEK1gCg3l1rgR6AWUnocItBp425NCyr Og0An33FYG+8wYpZJy81W5aJHI0YKlH2 =wapy -END PGP SIGNATURE-
Re: lmtp: transport unavailable
>> Just did - the only thing that's there is not helpful to me, >> either: Jan 20 11:31:40 chichak postfix/qmgr[31189]: warning: >> connect to transport private/local: Connec tion refused > Looks like lack of rights or wrong path. lack of rights: postfix should be able to use the socket, if it actually has the path, as # ls /var/spool/postfix/private/dovecot-lmtp -l srw--- 1 postfix postfix 0 Jan 20 10:24 /var/spool/postfix/private/dovecot-lmtp > > Did you run your smtp-source test as user postfix? yes: makes no difference. > > BTW - what user is your dovecot running with? root, standard debian config. > > What makes you shure, postfix will try to use > /var/spool/postfix/private/dovecot-lmtp? nothing makes me sure, as postfix does not actually say anywhere which socket it tries to use. (as long as the private/local above is not the path - I don't know where it'd get that, it's not mentioned in the config) There's some doku mentioning this[1], and main.cf has the entries quoted before, which should point there after chrooting. [1] http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP signature.asc Description: OpenPGP digital signature
RE: lmtp: transport unavailable
Ok, debian, my thing.. ;-)
Try :
Edit /etc/dovecot/dovecot.conf
To Change : protocols = imap lmtp
And add:
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
protocol lmtp {
postmaster_address=postmas...@yourdomain.com
hostname=mail.yourdomain.com
}
And in postfix main.cfg
mailbox_transport = lmtp:unix:private/dovecot-lmtp
Is this a setup with dovecot with sql?
Then you need some extra things.
Greetz,
Louis
> -Oorspronkelijk bericht-
> Van: ar...@sanusi.de [mailto:owner-postfix-us...@postfix.org] Namens Arian
> Sanusi
> Verzonden: woensdag 20 januari 2016 14:44
> Aan: postfix-users@postfix.org
> Onderwerp: Re: lmtp: transport unavailable
>
>
> >> Just did - the only thing that's there is not helpful to me,
> >> either: Jan 20 11:31:40 chichak postfix/qmgr[31189]: warning:
> >> connect to transport private/local: Connec tion refused
>
> > Looks like lack of rights or wrong path.
> lack of rights: postfix should be able to use the socket, if it actually
> has the path, as
> # ls /var/spool/postfix/private/dovecot-lmtp -l
> srw--- 1 postfix postfix 0 Jan 20 10:24
> /var/spool/postfix/private/dovecot-lmtp
> >
> > Did you run your smtp-source test as user postfix?
> yes: makes no difference.
> >
> > BTW - what user is your dovecot running with?
> root, standard debian config.
> >
> > What makes you shure, postfix will try to use
> > /var/spool/postfix/private/dovecot-lmtp?
>
> nothing makes me sure, as postfix does not actually say anywhere which
> socket it tries to use. (as long as the private/local above is not the
> path - I don't know where it'd get that, it's not mentioned in the config)
> There's some doku mentioning this[1], and main.cf has the entries quoted
> before, which should point there after chrooting.
>
> [1] http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP
Re: lmtp: transport unavailable
Wietse Venema: > Arian Sanusi: > > /var/log/mail.log: > > > Jan 20 11:31:40 chichak postfix/error[31253]: 6716E6A79: > > > to=, orig_to=, relay=none, > > > delay=0.42, delays=0.37/0/0/0.04, dsn=4.3.0, status=deferred (mail > > > transport unavailable) Based on an *EARLIER* error, the "qmgr" daemon has decided not to deliver this mail. It temporariliy switches deliveries from "lmtp" to "error". This is a safety mechanism that prevents Postfix from going crazy and continuously beating a dead horse. Therefore: > You need to look earlier in the logfile. Look for fatal or warning > records. grep panic /the/maillog/file grep fatal /the/maillog/file Look for the first time that the problem happened, i.e. before the safet mechanism kicks in. Wietse
Re: Enforcing strict TLS servers validations possible?
dererk: > Hi there! > > I've spent several hours trying to get it right, but seems I'm not > getting much to anywhere, so I finally wanted to check whether I was > doing something wrong or what. There is no evidence in your email that the client is required to send a certificate. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix. Wietse
Re: lmtp: transport unavailable
Am 20.01.2016 um 14:59 schrieb Wietse Venema: > Wietse Venema: >> Arian Sanusi: >>> /var/log/mail.log: Jan 20 11:31:40 chichak postfix/error[31253]: 6716E6A79: to=, orig_to=, relay=none, delay=0.42, delays=0.37/0/0/0.04, dsn=4.3.0, status=deferred (mail transport unavailable) Hi Arian, maybe i'm completely wrong. What ist "to=" inside the above printed logline? I know the "+"-addressing, but i don't know what the "$local" should do in that place. As i see, that looks like an entry with name expansion, for instance in a luser_relay file. Willi
Re: lmtp: transport unavailable
wilfried.es...@essignetz.de: [ Charset windows-1252 converted... ] > Am 20.01.2016 um 14:59 schrieb Wietse Venema: > > Wietse Venema: > >> Arian Sanusi: > >>> /var/log/mail.log: > Jan 20 11:31:40 chichak postfix/error[31253]: 6716E6A79: > to=, orig_to=, relay=none, > delay=0.42, delays=0.37/0/0/0.04, dsn=4.3.0, status=deferred (mail > transport unavailable) > > Hi Arian, > > maybe i'm completely wrong. What ist "to=" > inside the above printed logline? > > I know the "+"-addressing, but i don't know what the "$local" should do > in that place. As i see, that looks like an entry with name expansion, > for instance in a luser_relay file. The answer to that question is in the output from "postconf -n" (and perhaps "postconf -P", with Postfix 2.11 and later). Wietse
Re: Cannot get destination_concurrency_limit working properly
Still interested in trying to figure this out if I can. I am not sure what else to look for on this. Any assistance will be gratefully accepted! On 1/18/2016 6:49 PM, Russell Jones wrote: Sorry that was a typo, I meant I checked for "destination_recipient_limit" and did not have anything set with that name in main.cf. On 1/18/2016 6:32 PM, Russell Jones wrote: Hi Wietse, Thanks for replying! I have not set that. Everything I have set for this I provided in my initial email. I double checked to see if I had anything set for "destination_concurrency" and I do not. On 1/18/2016 11:02 AM, Wietse Venema wrote: Russell Jones: Hi all, I am trying to lower the concurrency for emails sent to *.rr.com domains. I have configured the following, can anyone please tell me what I am missing? Thanks in advance! In main.cf: transport_maps = hash:/etc/postfix/transport default_destination_concurrency_limit = 2 slow_destination_concurrency_limit = 1 slow_destination_rate_delay = 1s Did you by any chance set slow_destination_recipient_limit=1? That would a mistake. As documented, that schedules rates and concurrencies per recipient instead of per domain. Wietse
Re: Cannot get destination_concurrency_limit working properly
On 1/20/2016 8:28 PM, Russell Jones wrote: > Still interested in trying to figure this out if I can. I am not > sure what else to look for on this. Any assistance will be > gratefully accepted! > For further help, please show "postconf -n" output, any modifications you've made to master.cf, and logs demonstrating the problem. http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
Change or suppress technical errors
Hello users, I've been wondering if there is any way to alter or suppress technical errors from reject messages. In a virtual mailbox setup, a spammer frequently attempts to send mail to non-existent mailboxes and receives the response: "Recipient address rejected: User unknown in virtual mailbox table;" Is there any way to adjust that error to just be "User unknown" or something that doesn't sound so technical? Is the error due to a debug level setting? Thanks, Steve
Re: Change or suppress technical errors
On 1/20/2016 9:11 PM, Steven Kiehl wrote: > Hello users, > > I've been wondering if there is any way to alter or suppress > technical errors from reject messages. In a virtual mailbox setup, > a spammer frequently attempts to send mail to non-existent mailboxes > and receives the response: > > "Recipient address rejected: User unknown in virtual mailbox table;" > > Is there any way to adjust that error to just be "User unknown" or > something that doesn't sound so technical? Is the error due to a > debug level setting? > > Thanks, > Steve http://www.postfix.org/postconf.5.html#show_user_unknown_table_name -- Noel Jones
