On Fri, May 27, 2022 at 06:22:01PM -0700, Jim Garrison wrote:
> I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos
> 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working
> EXCEPT SASL authentication, and the amount of conflicting information
> on Postfix+SASL
Dear Joachim,
"Joachim Lindenberg" writes:
> Couldn´t run the python script due to postfix in docker, but can run
> postfix-finger domain - but this tells me what I already knew and
> wrote in my first mail. The certificate is not trusted and thus verify
> as default does not work, and it doesn´
Viktor Dukhovni writes:
> (... thanks ...)
> Yes. But in your case (with an overly strict default policy, requiring
> may exceptions) it would be more appropriate to define a dedicated
> transport for opportunistic unauthenticated TLS:
>
> # Or "dane" instead of "may" if you have a working D
I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos
6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working
EXCEPT SASL authentication, and the amount of conflicting information
on Postfix+SASL on the web is rather amazing :-).
I tried reading the Cyrus SASL manu
On Fri, May 27, 2022, James Feeney wrote:
> The "more information" that would be helpful is an example of a
> literal text string transmission, from Postfix, to a milter, and
> then from the milter to Postfix,
"What's the problem you are trying to solve?"
Are you trying to write a replacement fo
ran...@skurelabs.com:
> Hi Wietse,
>Thanks for your information. We are now using milter
> connected with Kafka to process emails.
> One more issue we are facing now is how to quarantine email(Change
> content) and block emails. Does milter support that?
Many sites use Milters to bloc
James Feeney:
> For the milter to "reject a command" implies that the milter is
> rejecting a command from the MTA for some reason, which makes no
> sense, since such behavior would appear to contradict the milter
> protocol described in the milter protocol article.
Yet that is EXACTLY what happen
On Fri, May 27, 2022 at 07:55:31AM -0400, charlie derr wrote:
> Are there any suggestions on how we can make sure that both internally
> generated and external email reach both Gmail and Dovecot mailboxes
> without creating a routing loop?
Yes, you should gateway the "Bcc" email traffic from Gmai
On Fri, May 27, 2022 at 09:21:23AM +0200, Joachim Lindenberg wrote:
> I added a transport map (or “route” as mailcow-dockerized calls it)
> that points to the alive MX
What was the exact form of the transport entry? Presumably, something
like:
example.com smtp:[mx1.example.com]
> plus
Couldn´t run the python script due to postfix in docker, but can run
postfix-finger domain - but this tells me what I already knew and wrote in my
first mail. The certificate is not trusted and thus verify as default does not
work, and it doesn´t look like postfix-finger evaluates tls policies a
Hellow charlie,
charlie derr writes:
> Greetings fine postfix wizards,
>
> We are in the process of transitioning from a local postfix and dovecot
> infrastructure to using gmail. While we're in the process of copying
> over all of our users' archived email to the new gmail environment, we'd
> l
> Von: "Benny Pedersen"
>
> On 2022-05-27 13:40, Wietse Venema wrote:
>
> > 4) Make Postfix smarter so that it can predict the future.
> >This is not yet implemented.
>
> +1
>
> rfc 7505 subdomain does not solve it ?
>
> du...@nullmx.example.org
>
> in dns make nullmx.example.org mx 0 .
>
>
On 2022-05-27 13:40, Wietse Venema wrote:
4) Make Postfix smarter so that it can predict the future.
This is not yet implemented.
+1
rfc 7505 subdomain does not solve it ?
du...@nullmx.example.org
in dns make nullmx.example.org mx 0 .
then use a...@nullmx.example.org for things not want
Hellow Joachim,
"Joachim Lindenberg" writes:
> Hello Byung-Hee,
> I do have all of the following in my TLS policy:
> domainmay
> mx.domain may
> [mx.domain]:25may
> and it doesn´t work for me.
Well you could check that your server is 'good' or 'not g
Greetings fine postfix wizards,
We are in the process of transitioning from a local postfix and dovecot
infrastructure to using gmail. While we're in the process of copying
over all of our users' archived email to the new gmail environment, we'd
like to have all email delivered both to gmail and t
juan smitt:
> Hi,
>
>
> We have some rules to drop emails sent to certain recipients.
>
> main.cf:
> smtpd_recipient_restrictions = check_recipient_access
> regexp:/etc/postfix/custom_recipient_blacklist_regex
>
> custom_recipient_blacklist_regex:
> /^du...@whatever.fqdn$/ discard
>
> The prob
> Von: "Wietse Venema"
> >
> > 1. x-original-to header
> > I still have no clue why the domain part is missing.
> > But this is still a test and at the end we will use pipe to
> > dovecot. Maybe this changes things.
>
> X-Original-To has always been the address before any rewriting,
> i.e. the
Hello Byung-Hee,
I do have all of the following in my TLS policy:
domain may
mx.domain may
[mx.domain]:25 may
and it doesn´t work for me.
Thanks,
Joachim
-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org <> Im Auftrag von Byung-Hee HWANG
Gesend
Hi,
We have some rules to drop emails sent to certain recipients.
main.cf:
smtpd_recipient_restrictions = check_recipient_access
regexp:/etc/postfix/custom_recipient_blacklist_regex
custom_recipient_blacklist_regex:
/^du...@whatever.fqdn$/ discard
The problem is when an email has more recipie
Dnia 26.05.2022 o godz. 16:02:07 James Feeney pisze:
>
> For the milter to "reject a command" implies that the milter is rejecting
> a command from the MTA for some reason, which makes no sense, since such
> behavior would appear to contradict the milter protocol described in the
> milter protocol
Hellow Joachim,
"Joachim Lindenberg" writes:
> I wanted to send a mail to a domain yesterday, that was using dead MX records
> and one
> the one MX that was alive, was presenting an untrusted certificate (my server
> uses verify
> by default). I added a transport map (or “route” as mailcow-doc
I wanted to send a mail to a domain yesterday, that was using dead MX records
and one the one MX that was alive, was presenting an untrusted certificate (my
server uses verify by default). I added a transport map (or “route” as
mailcow-dockerized calls it) that points to the alive MX plus a TLS
22 matches
Mail list logo
