Re: custom reject message for reject_sender_login_mismatch
Thanks, I'll check it out. Am Sa., 8. Sep. 2018 um 19:01 Uhr schrieb Kacper : > Looks like you would have to recompile postfix with changes to > smtpd_check.c, > https://github.com/vdukhovni/postfix/blob/c8e31ae510e006127934ce54413a829933ccae9d/postfix/src/smtpd/smtpd_check.c#L3818 > On Sat, Sep 8, 2018 at 3:18 PM Stefan Bauer > wrote: > > > > Hi, > > > > using > > > > smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch > > smtpd_sender_login_maps = hash:/etc/postfix/login_maps > > > > rejects user with invalid mail from domain with > > > > : Sender address rejected: not owned by user abc; from= > to= proto=ESMTP helo=<[192.168.0.173]> > > > > How can i customize this reject message? > > > > Thank you. > > > > Stefan >
Host offered STARTTLS: [mxlb... without relation to destination domain
I like the option smtp_tls_note_starttls_offer = yes but when a host is logged, it's hard to keep track to which recipient domain that host belong without doing dns-lookups against all listed in smtp_tls_policy_maps. Can this be improved to maybe also list the appropriate recipient domain?
smtp_tls_policy_maps on a per tls user basis
Hi, is there a way to specify on a per user basis (sasl authenticated user) if TLS should be none or may or encrypted for a specific recipient domain? I would like to have the user to decide if his mail to a specific domain should be TLS encrypted and then maybe bounce back but let other users mails to same destination domain go ahead with a may or none.
Re: smtp_tls_policy_maps on a per tls user basis
Stefan Bauer:
> Hi,
>
> is there a way to specify on a per user basis (sasl authenticated user) if
> TLS should be none or may or encrypted for a specific recipient domain?
There is no "per-recipient map" version for Postfix SMTP client
parameters (or most other parameters). It does not make sense,
because
- One message may have multiple recipients.
- One connection may deliver multiple messages.
- TLS is a connection property, not a recipient property.
Instead, you can use transport_maps to choose between different
Postfix SMTP clients (with different configurations) based on the
recipient address or domain.
You can use the access map or header/body_checks FILTER action
("FILTER name-of-transport:", without a domain after the ":") to
choose delivery methods based on other message properties, with
some loss of elegance.
> I would like to have the user to decide if his mail to a specific domain
> should be TLS encrypted and then maybe bounce back but let other users
> mails to same destination domain go ahead with a may or none.
That should be possible: use the transport_maps to choose between
one Postfix SMTP client that requires TLS, and one Postfix SMTP
client that does not. This should even work when an encrypted
connection is reused (smtp_tls_connection_reuse = yes).
Wietse
Re: Host offered STARTTLS: [mxlb... without relation to destination domain
Stefan Bauer: > I like the option smtp_tls_note_starttls_offer = yes > but when a host is logged, it's hard to keep track to which recipient > domain that host belong without doing dns-lookups against all listed in > smtp_tls_policy_maps. > > Can this be improved to maybe also list the appropriate recipient domain? This information is logged then the TLS level is set to NONE. Why not set the default TLS level to 'may' (perhaps with appropriate default ciphers/protocols/etc) and automatically discover what recipients can really be delivered over TLS? The existence of a STARTTLS announcement does not mean that you will actually be able to interoperate with the server. Wietse
Re: smtp_tls_policy_maps on a per tls user basis
Thank you. Before diving deeper into this, you're saying it is possible
with postfix to setup a static routing (with maps / tables) in the form:
mails from Domain-A or specific SASL-user to DOMAIN Z with enforced TLS
mails from Domain-B or specific SASL-user to DOMAIN Z with none TLS
Is that correct?
Am So., 9. Sep. 2018 um 16:28 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:
> Stefan Bauer:
> > Hi,
> >
> > is there a way to specify on a per user basis (sasl authenticated user)
> if
> > TLS should be none or may or encrypted for a specific recipient domain?
>
> There is no "per-recipient map" version for Postfix SMTP client
> parameters (or most other parameters). It does not make sense,
> because
> - One message may have multiple recipients.
> - One connection may deliver multiple messages.
> - TLS is a connection property, not a recipient property.
>
> Instead, you can use transport_maps to choose between different
> Postfix SMTP clients (with different configurations) based on the
> recipient address or domain.
>
> You can use the access map or header/body_checks FILTER action
> ("FILTER name-of-transport:", without a domain after the ":") to
> choose delivery methods based on other message properties, with
> some loss of elegance.
>
> > I would like to have the user to decide if his mail to a specific domain
> > should be TLS encrypted and then maybe bounce back but let other users
> > mails to same destination domain go ahead with a may or none.
>
> That should be possible: use the transport_maps to choose between
> one Postfix SMTP client that requires TLS, and one Postfix SMTP
> client that does not. This should even work when an encrypted
> connection is reused (smtp_tls_connection_reuse = yes).
>
> Wietse
>
postfix does not bounce instantly when remote party does not offer TLS
Hi, delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host seems to me like a permanent error - postfix sees it as a temporary one. I would like to have instant bounce message for this case when TLS is not available. sending postfix is configured 'encrypted' os no fallback is wanted.
Re: postfix does not bounce instantly when remote party does not offer TLS
> On Sep 9, 2018, at 12:49 PM, Stefan Bauer wrote: > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but was > not offered by host > > seems to me like a permanent error - postfix sees it as a temporary one. I > would like to have instant bounce message for this case when TLS is not > available. This type of error is often fixed within the queue lifetime of a message. If TLS was working for a destination, and was misconfigured down, the miscreant administrator should notice and bring it back. If you're requiring TLS support from strangers who might never have offered TLS, and expect delivery or an immediate bounce, we don't yet support that. -- Viktor.
Re: postfix does not bounce instantly when remote party does not offer TLS
On Sun, Sep 09, 2018 at 06:49:07PM +0200, Stefan Bauer wrote: > Hi, > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but > was not offered by host > > seems to me like a permanent error - postfix sees it as a temporary one. I > would like to have instant bounce message for this case when TLS is not > available. > > sending postfix is configured 'encrypted' os no fallback is wanted. http://www.postfix.org/postconf.5.html#plaintext_reject_code ? -- Herbert
Re: postfix does not bounce instantly when remote party does not offer TLS
any way to inform my users about TLS fails via bounce without waiting queue lifetime? Am So., 9. Sep. 2018 um 18:58 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 12:49 PM, Stefan Bauer > wrote: > > > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but > was not offered by host > > > > seems to me like a permanent error - postfix sees it as a temporary one. > I would like to have instant bounce message for this case when TLS is not > available. > > This type of error is often fixed within the queue lifetime of a message. > If TLS was working for a destination, and was misconfigured down, the > miscreant administrator should notice and bring it back. > > If you're requiring TLS support from strangers who might never have > offered TLS, and expect delivery or an immediate bounce, we don't > yet support that. > > -- > Viktor. > >
Re: Host offered STARTTLS: [mxlb... without relation to destination domain
> On Sep 9, 2018, at 9:46 AM, Stefan Bauer wrote: > > I like the option smtp_tls_note_starttls_offer = yes > but when a host is logged, it's hard to keep track to which recipient > domain that host belong without doing dns-lookups against all listed > in smtp_tls_policy_maps. Well, TLS is by nexthop domain not recipient domain. Typically the nexthop domain is the recipient domain, but with "relayhost" or other transport overrides, they need not be the same. So if your goal is discover which policy got you there, then you want the nexthop logged. If you use the collate.pl script (which may need tweaks to match the initial boilerplate part of your syslog message format with the data, hostname, ...) included with the Postfix source you can see which deliveries correspond to the messages in question. We could log the nexthop domain in a future release, this is not an unreasonable request. -- Viktor.
Re: postfix does not bounce instantly when remote party does not offer TLS
seems to only work when postfix is server. I need this for postfix as client when remote site is not offering tls. Am So., 9. Sep. 2018 um 18:59 Uhr schrieb Herbert J. Skuhra < herb...@gojira.at>: > On Sun, Sep 09, 2018 at 06:49:07PM +0200, Stefan Bauer wrote: > > Hi, > > > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but > > was not offered by host > > > > seems to me like a permanent error - postfix sees it as a temporary one. > I > > would like to have instant bounce message for this case when TLS is not > > available. > > > > sending postfix is configured 'encrypted' os no fallback is wanted. > > http://www.postfix.org/postconf.5.html#plaintext_reject_code > > ? > > -- > Herbert >
Re: Host offered STARTTLS: [mxlb... without relation to destination domain
That would be great to have this as part of the log string! Thank you for considering my request. Am So., 9. Sep. 2018 um 19:03 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 9:46 AM, Stefan Bauer > wrote: > > > > I like the option smtp_tls_note_starttls_offer = yes > > but when a host is logged, it's hard to keep track to which recipient > > domain that host belong without doing dns-lookups against all listed > > in smtp_tls_policy_maps. > > Well, TLS is by nexthop domain not recipient domain. Typically the > nexthop domain is the recipient domain, but with "relayhost" or > other transport overrides, they need not be the same. So if your > goal is discover which policy got you there, then you want the > nexthop logged. > > If you use the collate.pl script (which may need tweaks to > match the initial boilerplate part of your syslog message format > with the data, hostname, ...) included with the Postfix source > you can see which deliveries correspond to the messages in > question. We could log the nexthop domain in a future release, > this is not an unreasonable request. > > -- > Viktor. > >
Re: postfix does not bounce instantly when remote party does not offer TLS
> On Sep 9, 2018, at 1:01 PM, Stefan Bauer wrote: > > any way to inform my users about TLS fails via bounce without waiting queue > lifetime? http://www.postfix.org/postconf.5.html#delay_warning_time In corporate systems I tend to split the mail plant into separate inbound and outbound systems, and only enable delay warnings on the outbound side. -- Viktor.
Re: postfix does not bounce instantly when remote party does not offer TLS
our system is only outbound but here when TLS fails so remote sites, we would be happy to have an option to instantly bounce as this is mostly a fixed state. Am So., 9. Sep. 2018 um 19:27 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 1:01 PM, Stefan Bauer > wrote: > > > > any way to inform my users about TLS fails via bounce without waiting > queue lifetime? > > http://www.postfix.org/postconf.5.html#delay_warning_time > > In corporate systems I tend to split the mail plant into separate inbound > and outbound systems, and only enable delay warnings on the outbound side. > > -- > Viktor. > >
postfix add warning message for all external incoming emails
Hello Friends, I would like to make postfix add a warning message for all external incoming emails - Something like this at the top of each mail. WARNING: This email originated outside of our organization. Do not click any links or open any attachments unless you recognize the sender and know the content is safe How is this possible in postfix? Thanks/DP
Re: postfix add warning message for all external incoming emails
On 9/9/18 1:35 PM, Durga Prasad Malyala wrote: > Hello Friends, > I would like to make postfix add a warning message for all external > incoming emails - Something like this at the top of each mail. > > WARNING: This email originated outside of our organization. Do not > click any links or open any attachments unless you recognize the > sender and know the content is safe > > How is this possible in postfix? > > Thanks/DP > I can't see any way for postfix to do this itself. As far as I know, it doesn't have any general changing of the content of an email message in it. The best is can probably do is route the messages through something to try and add it. The bigger issue is that due to the way mail is structured, It can be very difficult to actually do something like that. First, a message may actually not have ANY text in it to add the message to, but might be just something like a picture. Also, if the message is HTML formatted, it can be very tricky to figure out how to insert text into it to be displayed in a given manner. You could add a text section to the beginning of the document with MIME, but you would need to find out all the MUAs used internally, and make sure you add the message in a way that they all handle reasonably (some MUAs will take any multisection message and display all but the first part as attachments, and don't handle email messages as attachments well. -- Richard Damon
Re: smtp_tls_policy_maps on a per tls user basis
Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> Instead, you can use transport_maps to choose between different
> Postfix SMTP clients (with different configurations) based on the
> recipient address or domain.
>
> You can use the access map or header/body_checks FILTER action
> ("FILTER name-of-transport:", without a domain after the ":") to
> choose delivery methods based on other message properties, with
> some loss of elegance.
I see no way to combine both. I want to enforce tls for sender1 to
google.com but not for sender2 to google.com.
Re: smtp_tls_policy_maps on a per tls user basis
> On Sep 9, 2018, at 3:39 PM, Stefan Bauer wrote: > > I see no way to combine both. I want to enforce tls for sender1 to google.com > but not for sender2 to google.com. I assume you don't literally mean "google.com", since they support TLS, and you can just enforce TLS to "google.com" for both and be done. For domains where you're less certain of ongoing TLS support, you can try to deal with this by choosing different transports for mail from sender1 vs. mail from sender2, via sender_default_transport_maps. In sender1's instance of the smtp(8) transport, the TLS policy will be mandatory for "example.com" recipients, while in sender2'd instance of the smtp(8) transport it will be opportunistic. -- -- Viktor.
Re: smtp_tls_policy_maps on a per tls user basis
* Stefan Bauer :
> Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> > Instead, you can use transport_maps to choose between different
> > Postfix SMTP clients (with different configurations) based on the
> > recipient address or domain.
> >
> > You can use the access map or header/body_checks FILTER action
> > ("FILTER name-of-transport:", without a domain after the ":") to
> > choose delivery methods based on other message properties, with
> > some loss of elegance.
>
> I see no way to combine both. I want to enforce tls for sender1 to
> google.com but not for sender2 to google.com.
Use two Postfix instances to deal with it. Single messages out first, then
route them as desired:
The first instance accepts the message and uses a ?_destination_recipient_limit
of 1 to hand the message over to the second instance.
In the second instance create (at least) a second smtp service (e.g.
mandatorytls), which enforces TLS to any destination.
Use a suited map type, search for a sender or recipient and let the query
result "FILTER mandatorytls". It will tell Postfix to use the TLS only smtp
service.
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
Re: smtp_tls_policy_maps on a per tls user basis
> On Sep 9, 2018, at 3:51 PM, Viktor Dukhovni > wrote: > > In sender1's instance of the > smtp(8) transport, the TLS policy will be mandatory for > "example.com" recipients, while in sender2'd instance of > the smtp(8) transport it will be opportunistic. I should mention that this only scales when senders fall into a *small* number of broad "classes", with each "class" having a dedicated default transport and associated TLS policy. sender (many) -> sender class (a few) -> transport + TLS policy (for many recipient domains) What does not scale in Postfix is a large ad-hoc set of (sender, recipient domain, TLS policy) triples. You can class your users into three types: * Delivery at all costs: no expectation of security * Normal delivery: some tolerance for delays when security fails * Secure delivery: strong preference for security, mandatory TLS for many domains where opportunistic is observed to generally work. -- Viktor.
Re: postfix add warning message for all external incoming emails
Durga Prasad Malyala: > Hello Friends, > I would like to make postfix add a warning message for all external > incoming emails - Something like this at the top of each mail. > > WARNING: This email originated outside of our organization. Do not > click any links or open any attachments unless you recognize the > sender and know the content is safe > > How is this possible in postfix? Yes. http://www.postfix.org/postconf.5.html#smtpd_client_restrictions http://www.postfix.org/access.5.html smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_access.cidr /etc/postfix/client_access.cidr # An "internal" source. 127.0.0.0/8 dunno 192.168.0.0/16 dunno # Everyone else. 0.0.0.0/0 prepend WARNING: This email originated outside of our organization. Do not click any links or open any attachments unless you recognize the sender and know the content is safe. I suppose lawyers love this. Otherwise I think it is useless. Wietse
Re: postfix add warning message for all external incoming emails
> On Sep 9, 2018, at 8:38 PM, Wietse Venema wrote:
>
> smtpd_client_restrictions =
>check_client_access cidr:/etc/postfix/client_access.cidr
>
> /etc/postfix/client_access.cidr
># An "internal" source.
>127.0.0.0/8 dunno
>192.168.0.0/16 dunno
># Everyone else.
>0.0.0.0/0 prepend WARNING: This email originated outside of our
> organization. Do not click any links or open any attachments
> unless you recognize the sender and know the content is safe.
>
> I suppose lawyers love this. Otherwise I think it is useless.
Indeed, and the OP probably wanted to prepend message body content,
not a "WARNING:" header.
What I see much more often is organizations prepending "[EXTERNAL]"
to the subject lines of messages arriving from outside.
main.cf:
pcre = pcre:${config_directory}/
header_checks = ${pcre}header-checks.pcre
mime_header_checks = ... season to taste ...
nested_header_checks = ... typically best empty ...
header-checks.pcre:
if /^Subject:/
# Subject checks go here
/:(.*)/ REPLACE Subject: [EXTERNAL]$1
/^/ OK
endif
# Non-subject tests below
...
--
Viktor.
Re: postfix add warning message for all external incoming emails
On 9 Sep 2018, at 13:35 (-0400), Durga Prasad Malyala wrote: Hello Friends, I would like to make postfix add a warning message for all external incoming emails - Something like this at the top of each mail. WARNING: This email originated outside of our organization. Do not click any links or open any attachments unless you recognize the sender and know the content is safe How is this possible in postfix? It's not possible in Postfix itself. This can be done in a milter. The MIMEDefang milter has a function to add arbitrary MIME parts to a message before or after the existing content and if you are up to writing a few lines of Perl and learning how the MIME::Entity module works, you could even modify existing plaintext and/or HTML parts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Re: postfix add warning message for all external incoming emails
On 9 Sep 2018, at 20:38 (-0400), Wietse Venema wrote: Durga Prasad Malyala: Hello Friends, I would like to make postfix add a warning message for all external incoming emails - Something like this at the top of each mail. WARNING: This email originated outside of our organization. Do not click any links or open any attachments unless you recognize the sender and know the content is safe How is this possible in postfix? Yes. http://www.postfix.org/postconf.5.html#smtpd_client_restrictions http://www.postfix.org/access.5.html smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_access.cidr /etc/postfix/client_access.cidr # An "internal" source. 127.0.0.0/8 dunno 192.168.0.0/16 dunno # Everyone else. 0.0.0.0/0 prepend WARNING: This email originated outside of our organization. Do not click any links or open any attachments unless you recognize the sender and know the content is safe. I suppose lawyers love this. Otherwise I think it is useless. Won't that just add a "WARNING:" RFC822 header to the message? That would be more useless than the average boilerplate addition to email, since very few users see arbitrary headers. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Re: smtp_tls_policy_maps on a per tls user basis
So each sender's instance is an own smtp-line in master.cf ? If so - does it work like this? src_domain1 unix - - n - - smtp -o smtp_tls_policy_maps = hash:/etc/postfix/tls_policy -o syslog_name=src_domain1 tls_policy: domain-that-does-not-support-tls.tld none and in main.cf sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport sender_transport: @src_domain1src_domain1: Is that correct? If so - will all settings from main.cf be used as well for additional smtp-instances? like smtp_tls_security_level encrypt ? Am So., 9. Sep. 2018 um 21:51 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 3:39 PM, Stefan Bauer > wrote: > > > > I see no way to combine both. I want to enforce tls for sender1 to > google.com but not for sender2 to google.com. > > I assume you don't literally mean "google.com", since they support > TLS, and you can just enforce TLS to "google.com" for both and be > done. > > For domains where you're less certain of ongoing TLS support, you > can try to deal with this by choosing different transports for > mail from sender1 vs. mail from sender2, via > sender_default_transport_maps. In sender1's instance of the > smtp(8) transport, the TLS policy will be mandatory for > "example.com" recipients, while in sender2'd instance of > the smtp(8) transport it will be opportunistic. > > -- > -- > Viktor. > >
Re: smtp_tls_policy_maps on a per tls user basis
Stefan Bauer:
Am Sonntag, 9. September 2018 schrieb Wietse Venema :
Instead, you can use transport_maps to choose between different
Postfix SMTP clients (with different configurations) based on the
recipient address or domain.
You can use the access map or header/body_checks FILTER action
("FILTER name-of-transport:", without a domain after the ":") to
choose delivery methods based on other message properties, with
some loss of elegance.
I see no way to combine both. I want to enforce tls for sender1 to
google.com but not for sender2 to google.com.
you may route messages from sender1 to a second postfix instance
and configure that instance to enforce tls to $destination for _any_ sender
Andreas
