Re: Query about restriction scenario in RESTRICTION_CLASS_README
On Tue, Jan 15, 2019 at 08:58:57PM -0500, Wietse Venema wrote: > Mayuresh: > > On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > > > This example can be simplified by using smtpd_relay_restrictions > > > (Posfix 2.10 and later). > > > > > > smtpd_relay_restrictions = > > > permit_mynetworks > > > permit_sasl_authenticated > > > reject_unauth_destination > > > ...other anti-spam things... > > > > > > smtpd_recipient_restrictions = > > >check_recipient_access hash:/etc/postfix/protected_destinations > > > > > > Otherwise everything has to be squeezed into smtpd_recipient_restrictions, > > > and that makes things ugly. > > > > Thanks for sharing the snippet. > > > > Comparing this with the README example of the OP, what is equivalent of > > insiders_only in your example i.e. the list of senders who are allowed to > > send to protected destination. > > > > My scenario is the sender restriction should apply only on the protected > > destination, not on others. > > Don't get confused by names. You can use the name 'list_members' > instead of 'insiders' if you like. The names don't change the > principle of how things work. Sure. Basically I see only one hash in your snippet - that of the protected destinations. I did not notice a hash of senders allowed to send to the protected destinations. Am I missing something? Mayuresh
Re: Query about restriction scenario in RESTRICTION_CLASS_README
Mayuresh: > On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > > This example can be simplified by using smtpd_relay_restrictions > > (Posfix 2.10 and later). > > > > smtpd_relay_restrictions = > > permit_mynetworks > > permit_sasl_authenticated > > reject_unauth_destination > > ...other anti-spam things... > > > > smtpd_recipient_restrictions = > > check_recipient_access hash:/etc/postfix/protected_destinations > > > > Otherwise everything has to be squeezed into smtpd_recipient_restrictions, > > and that makes things ugly. > > Thanks for sharing the snippet. > > Comparing this with the README example of the OP, what is equivalent of > insiders_only in your example i.e. the list of senders who are allowed to > send to protected destination. > > My scenario is the sender restriction should apply only on the protected > destination, not on others. Don't get confused by names. You can use the name 'list_members' instead of 'insiders' if you like. The names don't change the principle of how things work. Wietse
Re: Query about restriction scenario in RESTRICTION_CLASS_README
On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > This example can be simplified by using smtpd_relay_restrictions > (Posfix 2.10 and later). > > smtpd_relay_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject_unauth_destination > ...other anti-spam things... > > smtpd_recipient_restrictions = >check_recipient_access hash:/etc/postfix/protected_destinations > > Otherwise everything has to be squeezed into smtpd_recipient_restrictions, > and that makes things ugly. Thanks for sharing the snippet. Comparing this with the README example of the OP, what is equivalent of insiders_only in your example i.e. the list of senders who are allowed to send to protected destination. My scenario is the sender restriction should apply only on the protected destination, not on others. Mayuresh
Re: New SASL error when relaying through gmail
Wietse Venema: > Michael: > > On 1/14/19 11:19 AM, Wietse Venema wrote: > > > > > The 'invalid parameter supplied' is an error message the local SASL > > > library. This error happens while Postfix prepares to send the AUTH > > > command. > > > > > > Why does the Cyrus SASL library return 'invalid parameter supplied'? > > > I can only speculate that it does not like something about the SASL > > > mechanism list (which Postfix got from the Gmail server), or something > > > about the username or password (which it got from local file). > > > > > > It would be worthwhile to see the AUTH parameter in the server's > > > EHLO response before and after Postfix sends STARTTLS. > > > > > > Wietse > > > > > > Thanks Wietse, > > > > > > Using Angelo's testing methodology, I can see this: > > > > 250-smtp.gmail.com at your service, [68.226.113.229] > > 250-SIZE 35882577 > > 250-8BITMIME > > 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH > > Maybe it does not like the AUTH line. What happens when you > only keep the "250-AUTH LOGIN PLAIN" part? > >/etc/postfix/main.cf: >smtp_reply_filter = pcre:/etc/postfix/reply_filter > >/etc/postfix/reply_filter: >/^(250.AUTH LOGIN PLAIN)/ $1 > > Caution: this is a sharp tool that replaces server responses. Ignore this, Viktor's SASL mechanism filter is better. Wietse
Re: New SASL error when relaying through gmail
Michael: > On 1/14/19 11:19 AM, Wietse Venema wrote: > > > The 'invalid parameter supplied' is an error message the local SASL > > library. This error happens while Postfix prepares to send the AUTH > > command. > > > > Why does the Cyrus SASL library return 'invalid parameter supplied'? > > I can only speculate that it does not like something about the SASL > > mechanism list (which Postfix got from the Gmail server), or something > > about the username or password (which it got from local file). > > > > It would be worthwhile to see the AUTH parameter in the server's > > EHLO response before and after Postfix sends STARTTLS. > > > > Wietse > > > Thanks Wietse, > > > Using Angelo's testing methodology, I can see this: > > 250-smtp.gmail.com at your service, [68.226.113.229] > 250-SIZE 35882577 > 250-8BITMIME > 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH Maybe it does not like the AUTH line. What happens when you only keep the "250-AUTH LOGIN PLAIN" part? /etc/postfix/main.cf: smtp_reply_filter = pcre:/etc/postfix/reply_filter /etc/postfix/reply_filter: /^(250.AUTH LOGIN PLAIN)/ $1 Caution: this is a sharp tool that replaces server responses. Wietse
Re: tls_high_cipherlist with !SEED is ignored
> On Jan 15, 2019, at 3:39 PM, Stefan Bauer wrote: > > I just want to set allowed ciphers but can not enforce encryption generally. You cannot enforce encryption on the submission port? Why not? > this seems to be a limitation and not possible right? The ciphers are configurable, but the recommended interface for most users is to specify exclusions from the low level cipherlists, rather than deal with their non-trivial syntax. -- Viktor.
Re: tls_high_cipherlist with !SEED is ignored
now i got it. sorry and thank you for your help. Am Dienstag, 15. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 15, 2019, at 8:39 AM, Stefan Bauer wrote: >> >> -o smtpd_tls_mandatory_ciphers=high >> -o tls_preempt_cipherlist=yes >> -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S >> HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA > > Instead, try: > > master.cf: > submission inet ... smtpd > ... > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_mandatory_ciphers=high > -o smtpd_tls_exclude_ciphers=$msa_exclude_ciphers > > main.cf: > msa_exclude_ciphers = SEED > > See: http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers > > -- > Viktor. > >
Re: tls_high_cipherlist with !SEED is ignored
I just want to set allowed ciphers but can not enforce encryption generally. this seems to be a limitation and not possible right? Am Dienstag, 15. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 15, 2019, at 8:39 AM, Stefan Bauer wrote: >> >> -o smtpd_tls_mandatory_ciphers=high >> -o tls_preempt_cipherlist=yes >> -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S >> HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA > > Instead, try: > > master.cf: > submission inet ... smtpd > ... > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_mandatory_ciphers=high > -o smtpd_tls_exclude_ciphers=$msa_exclude_ciphers > > main.cf: > msa_exclude_ciphers = SEED > > See: http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers > > -- > Viktor. > >
Re: New SASL error when relaying through gmail
On 1/15/19 1:05 PM, Viktor Dukhovni wrote: On Jan 15, 2019, at 2:47 PM, Michael wrote: Using Angelo's testing methodology, I can see this: 250-smtp.gmail.com at your service, [68.226.113.229] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 I am not sure how to check from postfix. smtp_sasl_mechanism_filter = plain Awesome Viktor! With that in place, mail is now flowing again! I really appreciate everyones responses that help guide me to a solution. Michael
Re: New SASL error when relaying through gmail
> On Jan 15, 2019, at 2:47 PM, Michael wrote: > > Using Angelo's testing methodology, I can see this: > > 250-smtp.gmail.com at your service, [68.226.113.229] > 250-SIZE 35882577 > 250-8BITMIME > 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-CHUNKING > 250 SMTPUTF8 > > > I am not sure how to check from postfix. smtp_sasl_mechanism_filter = plain -- Viktor.
RE: New SASL error when relaying through gmail
It may be time to crank up debug level on Postfix or do tcpdump capture to see what you are sending over the wire when it works and when it doesn't ? -ANGELO FAZZINA ang...@uconn.edu University of Connecticut, ITS, SSG, Server Systems 860-486-9075 -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Michael Sent: Tuesday, January 15, 2019 2:48 PM To: postfix-users@postfix.org Subject: Re: New SASL error when relaying through gmail On 1/14/19 11:19 AM, Wietse Venema wrote: > The 'invalid parameter supplied' is an error message the local SASL > library. This error happens while Postfix prepares to send the AUTH > command. > > Why does the Cyrus SASL library return 'invalid parameter supplied'? > I can only speculate that it does not like something about the SASL > mechanism list (which Postfix got from the Gmail server), or something > about the username or password (which it got from local file). > > It would be worthwhile to see the AUTH parameter in the server's > EHLO response before and after Postfix sends STARTTLS. > > Wietse Thanks Wietse, Using Angelo's testing methodology, I can see this: 250-smtp.gmail.com at your service, [68.226.113.229] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 I am not sure how to check from postfix. Michael
Re: New SASL error when relaying through gmail
On 1/14/19 11:19 AM, Wietse Venema wrote: The 'invalid parameter supplied' is an error message the local SASL library. This error happens while Postfix prepares to send the AUTH command. Why does the Cyrus SASL library return 'invalid parameter supplied'? I can only speculate that it does not like something about the SASL mechanism list (which Postfix got from the Gmail server), or something about the username or password (which it got from local file). It would be worthwhile to see the AUTH parameter in the server's EHLO response before and after Postfix sends STARTTLS. Wietse Thanks Wietse, Using Angelo's testing methodology, I can see this: 250-smtp.gmail.com at your service, [68.226.113.229] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 I am not sure how to check from postfix. Michael
Re: New SASL error when relaying through gmail
On 1/14/19 11:09 AM, Fazzina, Angelo wrote:
Hi, can you manually use commands to test the U/P are working from your postfix
server ?
1. Run this to test connectivity to your server
openssl s_client -starttls smtp -connect your.host.name:587
Typical OUTPUT =
250 DSN
quit
221 2.0.0 Bye
closed
2. Run this to create a hash
python -c 'import base64,sys; u,p=sys.argv[1:3]; print
base64.encodestring("%s\x00%s\x00%s" % (u,u,p))' username password
OUTPUT = dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
Replace username and password with real ones
Once Steps 1 and 2 work, you can test authentication with the hash in Step 3
3. Run the openssl commands and connect to your server.
A. do and "ehlo domain" to see commands supported
EXAMPLE :
ehlo domain
250-localpart.domain.part
250-PIPELINING
250-SIZE 31457280
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
B. execute the AUTH PLAIN LOGIN command option using the HASH you made
in Step 3
AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
C. look for output
235 2.7.0 Authentication successful
Thanks Angelo. This is quite useful for debugging. I spent many
hours today not getting authentication successful messages. I ultimately
turned off 2FA on google and got rid of the app passwords. Then I
enabled insecure apps. Once that is done, I can now get a 235 2.7.0
Accepted message.
However, I am still getting these messages when postfix tries to relay.
Jan 15 12:43:35 deathstar postfix/smtp[32233]: A90511E0963:
to=, relay=smtp.gmail.com[74.125.142.109]:587,
delay=98478, delays=98477/0.04/0.94/0, dsn=4.7.0, status=deferred (SASL
authentication failed; cannot authenticate to server
smtp.gmail.com[74.125.142.109]: invalid parameter supplied)
Michael
Re: Query about restriction scenario in RESTRICTION_CLASS_README
Mayuresh: > I am using postfix 3.1.4 on NetBSD 8. > > I am trying the idea of setting up a mailing list for a fairly static > group of size not exceeding around 300, with postfix. I am doing this on a > VPS server and want a solution that is conservative on resource footprint, > hence considering doing it with MTA itself. [Please do comment whether > postfix is suitable for this purpose.] > > I am able to get the basic aliases functionality, Reply-To header > modification etc. working fine. > > I just need a recipe to restrict senders to the members of the mailing > list - only for the protected email id which is the list email id. > > The search led me to the following write up in > /usr/share/examples/postfix/RESTRICTION_CLASS_README: > >In the general case you need two lookup tables: one table that lists >destinations that need to be protected, and one table that lists domains >that are allowed to send to the protected destinations. > > > /etc/postfix/main.cf: > smtpd_recipient_restrictions = > ... > check_recipient_access hash:/etc/postfix/protected_destinations > ...the usual stuff... > > smtpd_restriction_classes = insiders_only > insiders_only = check_sender_access hash:/etc/postfix/insiders, reject > > /etc/postfix/protected_destinations: > all@my.domain insiders_only > all@my.hostname insiders_only > > /etc/postfix/insiders: > my.domain OK matches my.domain and subdomains > another.domain OK matches another.domain and subdomains > > > I am unable to follow this example, particularly due to the ellipsis part. > Would appreciate if someone could elaborate this a bit further. This example can be simplified by using smtpd_relay_restrictions (Posfix 2.10 and later). smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination ...other anti-spam things... smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/protected_destinations Otherwise everything has to be squeezed into smtpd_recipient_restrictions, and that makes things ugly. Wietse
Query about restriction scenario in RESTRICTION_CLASS_README
I am using postfix 3.1.4 on NetBSD 8. I am trying the idea of setting up a mailing list for a fairly static group of size not exceeding around 300, with postfix. I am doing this on a VPS server and want a solution that is conservative on resource footprint, hence considering doing it with MTA itself. [Please do comment whether postfix is suitable for this purpose.] I am able to get the basic aliases functionality, Reply-To header modification etc. working fine. I just need a recipe to restrict senders to the members of the mailing list - only for the protected email id which is the list email id. The search led me to the following write up in /usr/share/examples/postfix/RESTRICTION_CLASS_README: In the general case you need two lookup tables: one table that lists destinations that need to be protected, and one table that lists domains that are allowed to send to the protected destinations. /etc/postfix/main.cf: smtpd_recipient_restrictions = ... check_recipient_access hash:/etc/postfix/protected_destinations ...the usual stuff... smtpd_restriction_classes = insiders_only insiders_only = check_sender_access hash:/etc/postfix/insiders, reject /etc/postfix/protected_destinations: all@my.domain insiders_only all@my.hostname insiders_only /etc/postfix/insiders: my.domain OK matches my.domain and subdomains another.domain OK matches another.domain and subdomains I am unable to follow this example, particularly due to the ellipsis part. Would appreciate if someone could elaborate this a bit further. Mayuresh
Re: tls_high_cipherlist with !SEED is ignored
> On Jan 15, 2019, at 8:39 AM, Stefan Bauer wrote: > > -o smtpd_tls_mandatory_ciphers=high > -o tls_preempt_cipherlist=yes > -o > tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S > HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA Instead, try: master.cf: submission inet ... smtpd ... -o smtpd_tls_security_level=encrypt -o smtpd_tls_mandatory_ciphers=high -o smtpd_tls_exclude_ciphers=$msa_exclude_ciphers main.cf: msa_exclude_ciphers = SEED See: http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers -- Viktor.
Re: tls_high_cipherlist with !SEED is ignored
stefan Bauer: > Nessus reports for example TLS_RSA_WITH_SEED_CBC_SHA as weak on our > submission port. So i was using the following to disable all SEED ciphers > on submission port but it has no effect: > > -o smtpd_tls_mandatory_ciphers=high > -o tls_preempt_cipherlist=yes > -o > tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S > HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA I see no evidence that smtpd is using mandatory TLS, which I think is a prerequisite for the above settings to have an observable effect. Wietse
Re: pflogsumm milter patch
Hello, does anyone use pflogsumm and reject based on header/body checks? If so, can you test or provide me (privately) same logs of those rejections? On 11.01.19 15:43, Matus UHLAR - fantomas wrote: I have made a small patch for counting milter rejections in pflogsumm. I put it on http://test.fantomas.sk/pflogsumm-milter-test.patch pflogsumm now displays erors below when using amavisd-milter refusals. I would strip the "from ", but first I would like to ask people who use header and body checks to reject messages, and use pflogsumm, to confirm whether they need the "from ", and possibly send me (personally, please) the part output where "cleanup" rejections are shown. -- 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. Chernobyl was an Windows 95 beta test site.
tls_high_cipherlist with !SEED is ignored
Nessus reports for example TLS_RSA_WITH_SEED_CBC_SHA as weak on our submission port. So i was using the following to disable all SEED ciphers on submission port but it has no effect: -o smtpd_tls_mandatory_ciphers=high -o tls_preempt_cipherlist=yes -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA after postfix restart, nmap --script ssl-enum-ciphers -p 587 mailserver still reports SEED ciphers: $ nmap --script ssl-enum-ciphers -p 587 mailserver | grep SEED | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A What am i missing?
Re: DSN behavior unclear - clarification needed
Awesome. Thank you. That did the trick. Am Di., 15. Jan. 2019 um 13:22 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > i would like that postfix always sends DSN, when requested by client and > > mail got forwarded to next-hop / final destination. > > Postfix implements a published RFC, and according to that RFC, > Postfix will send a 'relayed' DSN if: > > 1 - The sender requested DSN notification. > > And: > > 2 - The next-hop MTA does not announce DSN support, or you turn off > DSN support (smtp_discard_ehlo_keywords = dsn, silent-discard). > > Additionally, you can tweak the SMTP conversation with > smtpd_command_filter, smtp_reply_filter, and smtp_delivery_status_filter. > There are examples in the documentation of those parameters. > > Wietse >
Re: DSN behavior unclear - clarification needed
Stefan Bauer: > Hi, > > i would like that postfix always sends DSN, when requested by client and > mail got forwarded to next-hop / final destination. Postfix implements a published RFC, and according to that RFC, Postfix will send a 'relayed' DSN if: 1 - The sender requested DSN notification. And: 2 - The next-hop MTA does not announce DSN support, or you turn off DSN support (smtp_discard_ehlo_keywords = dsn, silent-discard). Additionally, you can tweak the SMTP conversation with smtpd_command_filter, smtp_reply_filter, and smtp_delivery_status_filter. There are examples in the documentation of those parameters. Wietse
DSN behavior unclear - clarification needed
Hi, i would like that postfix always sends DSN, when requested by client and mail got forwarded to next-hop / final destination. Thats works on some recipients, but not on all. postfix always sends DSN on specific destinations (e.g. web.de) : delivery via mx-ha02.web.de[212.227.17.8]:25: 250 Requested mail action okay, completed: id=1N0YD0-1hUYlq3qCq-00wNxk But when mail is send to some other foreign postfix servers, the foreign mailserver sends DSN. How can we specifiy, that only "our" postfix server sends DSN. Reason is, we have custom bounce messages and would like to only present our users our custom DSN text. Thank you. Stefan
