Re: HTML bounces
Am 17.10.2014 um 07:49 schrieb Andre Rodier: I have a few users who don't understand bounced messages, and consider them as an error from our system. I won't even try to educate them. I would like to know if there is a way to use HTML messages to send "beautiful" bounces messages (internally) but continue to send standard text format externally. it don't matter if they are "beautiful", the point is not that users don#t understand bounces, they just don't try it especially internally: educate them and leave the world in peace with HTML bounces, each time i get such one i'd like to seek and destroy the admin on the other side (also for the backscattering, other topic)
How to do whitelisting with milter_header_checks?
Hello, the documentation states: The milter_header_checks mechanism could also be used for whitelisting. For example it could be used to skip heavy content inspection for DKIM-signed mail from known friendly domains. I want to do that for mail that passes DMARC checks (with 2.11.2 DMARC became easy to implement thanks to the milter change). But looking at header_checks(5) I can't see a good ACTION for doing it. PERMIT is not listed, OK is treated at DUNNO... Can someone point me in the right direction? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: HTML bounces
Andre Rodier: > Hi, > > I have a few users who don't understand bounced messages, and consider > them as an error from our system. I won't even try to educate them. > > I would like to know if there is a way to use HTML messages to send > "beautiful" bounces messages (internally) but continue to send standard > text format externally. So this is a double request: 1) HTML format in addition to text. Different formats for different recipients. Neither is supported. The harder you try, the fewer people will read your bounce message. Wietse > I already configured my bounce_template_file, but it only allows me to > do it as text. > > If you have a perl/python/... scripted solution, I am interested as well. > > Thanks, > Andr?. >
Re: How to do whitelisting with milter_header_checks?
Sebastian Wiesinger: > Hello, > > the documentation states: > > The milter_header_checks mechanism could also be used for > whitelisting. For example it could be used to skip heavy content > inspection for DKIM-signed mail from known friendly domains. > > I want to do that for mail that passes DMARC checks (with 2.11.2 DMARC > became easy to implement thanks to the milter change). > > But looking at header_checks(5) I can't see a good ACTION for doing > it. PERMIT is not listed, OK is treated at DUNNO... Ihe action is to be implemented IN THE HEAVY CONTENT FILTER. Wietse
Re: DROP not a Postfix problem!!: OT: can anybody tell me what is wrong here
John: > > On 14/10/2014 11:14 PM, Claus Assmann wrote: > > On Tue, Oct 14, 2014, John wrote: > >> host MX.cogeco.ca[216.221.81.26] said: 451 > >> Postmaster > >> Code 5 - #4.1.8 Domain of sender address does not > >> resolve. > > Try again, it's just a temporary error. > > > > BTW: cool error message with those 8 bit chars in it: > > utilis? pour envoyer le courriel, ne se r?sout pas Some REMOTE MAIL SERVER is not accepting your mail. If you want to know why, ask the people who are responsible for the REMOTE MAIL SERVER. Wietse
Re: How to do whitelisting with milter_header_checks?
Wietse Venema: > Sebastian Wiesinger: > > Hello, > > > > the documentation states: > > > > The milter_header_checks mechanism could also be used for > > whitelisting. For example it could be used to skip heavy content > > inspection for DKIM-signed mail from known friendly domains. > > > > I want to do that for mail that passes DMARC checks (with 2.11.2 DMARC > > became easy to implement thanks to the milter change). > > > > But looking at header_checks(5) I can't see a good ACTION for doing > > it. PERMIT is not listed, OK is treated at DUNNO... > > Ihe action is to be implemented IN THE HEAVY CONTENT FILTER. Another option is to have: /etc/postfix/main.cf: content_filter = smtp:input-of-after-queue-content-filter /etc/postfix/milter_header_checks: /^flagged as authentic/ content_filter = smtp:after-filter-smtp-service Where after-filter-smtp-service is the SMTP service that follows the after-queue-content-filter. Thus, allowing authentic mail to skip the content filter. Wietse
Milter header position semantincs
(This message is mostly of interest to Claus Assmann) This week I fixed a problem or PREPEND actions in access maps or policy server reponses that was giving problems with DMARC setups that combine of SPF policy server with a DKIM Milter. Meanwhile, Christian R??ner has pointed out that there still is a different problem with header insert requests, this time in Milter responses. Here is a quote from the Milter API documentation, on-line at https://www.milter.org/developers/api/smfi_insheader int smfi_insheader( SMFICTX *ctx, int hdridx, /* header position */ char *headerf, /* header label */ char *headerv /* header value */ ); * A filter will receive only headers that have been sent by the SMTP client and those header modifications by earlier filters. It will not receive the headers that are inserted by sendmail itself. This makes the header insertion position highly dependent on the headers that exist in the incoming message and those that are configured to be added by sendmail. For example, sendmail will always add a Received: header to the beginning of the headers. Setting hdridx to 0 will actually insert the header before this Received: header. However, later filters can be easily confused as they receive the added header, but not the Received: header, thus making it hard to insert a header at a fixed position. Thus, the first Milter in a list of Milters sees a message header like this: Headers from SMTP client When the first Milter issues header insert requests with index 0, the resulting message looks like this with Postfix and Sendmail: Header2 inserted with index 0 (internal header index 0) Header1 inserted with index 0 (internal header index 1) Received: header from receiving MTA (internal header index 2) Headers from SMTP client(internal header index 3...) With Sendmail, the second etc. Milters see the following header: Header2 inserted with index 0 (internal header index 0) Header1 inserted with index 0 (internal header index 1) Headers from SMTP client(internal header index 3...) While with Postfix they see something different: Header1 inserted with index 0 Received: header from receiving MTA Headers from SMTP client A naive workaround is to put "index 0" headers under Postfix's own Received header. Then, Milters see the same headers as they would see with Sendmail. But the problem is that the internal header indices would differ from those with Sendmail: Header2 inserted with index 0 (internal header index 1) Header1 inserted with index 0 (internal header index 2) Headers from SMTP client (internal header index 3...) These header index differences complicate life for Milter users. To avoid this difference with Sendmail, Postfix would have to implement the same behavior as Sendmail: ignore the MTA's own received header when reporting headers to Milters, but don't ignore the MTA's own received header when receiving Milter requests with a header index. That is, ignore the header based on its name, not on its position. If we do that, then we can also roll back this week's patch that placed access/policy PREPENDed headers after the MTA's own received header. Wietse
Re: Milter header position semantincs
Am 17.10.2014 um 16:48 schrieb Wietse Venema: > (This message is mostly of interest to Claus Assmann) > > This week I fixed a problem or PREPEND actions in access maps or > policy server reponses that was giving problems with DMARC setups > that combine of SPF policy server with a DKIM Milter. > > Meanwhile, Christian R??ner has pointed out that there still is a > different problem with header insert requests, this time in Milter > responses. > > Here is a quote from the Milter API documentation, on-line at > https://www.milter.org/developers/api/smfi_insheader > > int smfi_insheader( > SMFICTX *ctx, > int hdridx, /* header position */ > char *headerf,/* header label */ > char *headerv /* header value */ > ); > > * A filter will receive only headers that have been sent by the > SMTP client and those header modifications by earlier filters. > It will not receive the headers that are inserted by sendmail > itself. This makes the header insertion position highly dependent > on the headers that exist in the incoming message and those > that are configured to be added by sendmail. For example, > sendmail will always add a Received: header to the beginning > of the headers. Setting hdridx to 0 will actually insert the > header before this Received: header. However, later filters can > be easily confused as they receive the added header, but not > the Received: header, thus making it hard to insert a header > at a fixed position. > > Thus, the first Milter in a list of Milters sees a message header > like this: > > Headers from SMTP client > > When the first Milter issues header insert requests with index 0, > the resulting message looks like this with Postfix and Sendmail: > > Header2 inserted with index 0 (internal header index 0) > Header1 inserted with index 0 (internal header index 1) > Received: header from receiving MTA (internal header index 2) > Headers from SMTP client(internal header index 3...) > > With Sendmail, the second etc. Milters see the following header: > > Header2 inserted with index 0 (internal header index 0) > Header1 inserted with index 0 (internal header index 1) > Headers from SMTP client(internal header index 3...) > > While with Postfix they see something different: > > Header1 inserted with index 0 > Received: header from receiving MTA > Headers from SMTP client > > A naive workaround is to put "index 0" headers under Postfix's own > Received header. Then, Milters see the same headers as they would > see with Sendmail. But the problem is that the internal header > indices would differ from those with Sendmail: > > Header2 inserted with index 0 (internal header index 1) > Header1 inserted with index 0 (internal header index 2) > Headers from SMTP client (internal header index 3...) > > These header index differences complicate life for Milter users. > > To avoid this difference with Sendmail, Postfix would have to > implement the same behavior as Sendmail: ignore the MTA's own > received header when reporting headers to Milters, but don't ignore > the MTA's own received header when receiving Milter requests with > a header index. That is, ignore the header based on its name, not > on its position. > > If we do that, then we can also roll back this week's patch that > placed access/policy PREPENDed headers after the MTA's own received > header. > > Wietse > Thank you Wietse Christian and Claus for loooking to a code solution at that milter stuff !!! Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: HTML bounces
On 17 Oct 2014, at 04:51 , Wietse Venema wrote: > The harder you try, the fewer people will read your bounce message. Honestly, I do not think it is possible for there to be fewer people who read bounces. Customized LOCAL bounce messages would be nifty. I don't want HTML ones but customizing the messages for local users would be nice. Some extensibility to the variables available might be nice too, to allow more customizations to the bounce message. Not a feature request, per se, but if it showed up somewhere down the line it's a feature I'd use. -- 'I think, if you want thousands, you've got to fight for one.'
Re: HTML bounces
On Fri, 17 Oct 2014 10:49:15 -0600 LuKreme wrote: > On 17 Oct 2014, at 04:51 , Wietse Venema wrote: > > The harder you try, the fewer people will read your bounce message. > > Honestly, I do not think it is possible for there to be fewer people > who read bounces. > > Customized LOCAL bounce messages would be nifty. I don't want HTML > ones but customizing the messages for local users would be nice. Some > extensibility to the variables available might be nice too, to allow > more customizations to the bounce message. > > Not a feature request, per se, but if it showed up somewhere down the > line it's a feature I'd use. > > That would be a bit more helpful to end users who have no idea how things work. Otherwise... Local FAQ re bounces? A custom error message to direct local users to said FAQ? A monthly user newsletter reminding local users to peruse the FAQ for useful information? A monthly user newsletter periodically containing a FAQ topic or three? Cluehammer as a last resort? (not a feature request?) jd?
Re: HTML bounces
On 10/17/2014 12:32 PM, jdebert wrote: > On Fri, 17 Oct 2014 10:49:15 -0600 > LuKreme wrote: > >> On 17 Oct 2014, at 04:51 , Wietse Venema wrote: >>> The harder you try, the fewer people will read your bounce message. >> >> Honestly, I do not think it is possible for there to be fewer people >> who read bounces. >> >> Customized LOCAL bounce messages would be nifty. I don't want HTML >> ones but customizing the messages for local users would be nice. Some >> extensibility to the variables available might be nice too, to allow >> more customizations to the bounce message. >> >> Not a feature request, per se, but if it showed up somewhere down the >> line it's a feature I'd use. >> >> > > That would be a bit more helpful to end users who have no idea > how things work. > > Otherwise... > > Local FAQ re bounces? > > A custom error message to direct local users to said FAQ? > > A monthly user newsletter reminding local users to peruse the FAQ for > useful information? > > A monthly user newsletter periodically containing a FAQ topic or three? > > Cluehammer as a last resort? (not a feature request?) > > jd? > For bounces created by your own system (which is all you can control), you can use the smtpd_reject_footer feature to add a web link to helpful information (in your local language). Few people will bother clicking on it, but it might help a little. I'm always a little surprised when people really do contact me through this. http://www.postfix.org/postconf.5.html#smtpd_reject_footer -- Noel Jones
Re: HTML bounces
On October 17, 2014 7:49:34 AM Andre Rodier wrote: I have a few users who don't understand bounced messages, and consider them as an error from our system. I won't even try to educate them. So thay understand more if it was html ?, hmm I would like to know if there is a way to use HTML messages to send "beautiful" bounces messages (internally) but continue to send standard text format externally. Text msgs is beautiful, no ? I already configured my bounce_template_file, but it only allows me to do it as text. You can show a link in bounce to bugzilla on own domain, and hope users will use it, but historical postfix is not a webmaster If you have a perl/python/... scripted solution, I am interested as well. -1000
PATCH: Milter header position semantics
Wietse Venema: > This week I fixed a problem or PREPEND actions in access maps or > policy server reponses that was giving problems with DMARC setups > that combine of SPF policy server with a DKIM Milter. > > Meanwhile, Christian R??ner has pointed out that there still is a > different problem with [visibility of headers inserted with Milter > requests] > > To avoid [incompatibility] with Sendmail, Postfix would have to > implement the same behavior as Sendmail: ignore the MTA's own > received header when reporting headers to Milters, but don't ignore > the MTA's own received header when receiving Milter requests [...]. I have patches for evaluation: Postfix 2.12 released 20140918 or later: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.patch ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.patch.asc ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.patch.sig Postfix 2.8, 2.9. 2.10, 2.11, and Postfix 2.12 released before 20140918: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.11.patch ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.11.patch.asc ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.11.patch.sig This just shows how little the Postfix Milter implementation has changed over time. Wietse
Re: PATCH: Milter header position semantics
wietse: I have patches for evaluation: Postfix 2.12 released 20140918 or later: just compiling ... Postfix 2.8, 2.9. 2.10, 2.11, and Postfix 2.12 released before 20140918: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.11.patch this link is broken BTW: I played with SMTPUTF8. Debian Wheeze is the minimum Debian version required. Maybe that should/could be noted on http://www.postfix.org/SMTPUTF8_README.html#building Andreas
Re: PATCH: Milter header position semantics
A. Schulze: > > wietse: > > > I have patches for evaluation: > > Postfix 2.12 released 20140918 or later: > just compiling ... > > > Postfix 2.8, 2.9. 2.10, 2.11, and Postfix 2.12 released before 20140918: > > ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20141017-milter-auto-header-hide-2.12.11.patch > this link is broken Should be 2.11.2-patch. Wietse > BTW: > I played with SMTPUTF8. Debian Wheeze is the minimum Debian version required. > Maybe that should/could be noted on > http://www.postfix.org/SMTPUTF8_README.html#building > > Andreas > >
Re: PATCH: Milter header position semantics
Wietse Venema: > > To avoid [incompatibility] with Sendmail, Postfix would have to > > implement the same behavior as Sendmail: ignore the MTA's own > > received header when reporting headers to Milters, but don't ignore > > the MTA's own received header when receiving Milter requests [...]. > > I have patches for evaluation: > > Postfix 2.12 released 20140918 or later: no difference to 2.12-20141011 the milterchain "spf-milter, amavisd-milter, opendkim + opendmarc" produce the same header chain: ... Authentication-Results: from opendmarc-milter Authentication-Results: from opendkim-milter X-Spam-foo: added by amavisd-milter from amavisd + spamassassin Received: from MTA Authentication-Results: from spf-milter ... in short: no problem here (as before ...) Andreas
Re: PATCH: Milter header position semantics
Andreas Schulze: > Wietse Venema: > > > To avoid [incompatibility] with Sendmail, Postfix would have to > > > implement the same behavior as Sendmail: ignore the MTA's own > > > received header when reporting headers to Milters, but don't ignore > > > the MTA's own received header when receiving Milter requests [...]. > > > > I have patches for evaluation: > > > > Postfix 2.12 released 20140918 or later: > > no difference to 2.12-20141011 > > the milterchain "spf-milter, amavisd-milter, opendkim + opendmarc" produce > the same header chain: > > ... > Authentication-Results: from opendmarc-milter > Authentication-Results: from opendkim-milter > X-Spam-foo: added by amavisd-milter from amavisd + spamassassin > Received: from MTA > Authentication-Results: from spf-milter > ... > > in short: no problem here (as before ...) I changed the algorithm that decides what headers are VISIBLE to a Milter. I did not change the header ORDER. Wietse
