Re: Configurable replies for hardcoded REJECTS?

[Dabrien 'Dabe' Murphy]

Wietse Venema wrote:

I was thinking of adding a second line to the antispam reject
messages. For example:

 550-5.7.1 The existing reject message
 550 5.7.1 Please see http://foo.example.com/ for support.
   


Nice.

One catch-all banner is infinitely better than nothing, and it's a good 
first step.  If, in ANOTHER four months, somebody ELSE requests 
per-error customization, THEN maybe the foundation will have already 
been put in place, so it won't be as dramatic a change.



I don't think that it makes sense to do fine-grained customizations
for each possible reject reason


Counter argument: By making it configurable (ergo, more flexible) then 
that decision is left up to each site's administrator.  *Shrug*


In my case, I just want to help people help themselves.  I desperately 
need for folks to understand that this particular problem isn't on our 
end, rather, they need to work with their IT department and/or ISP to 
either straighten out their forward <=> reverse DNS mappings, or simply 
relay through their upstream MSA or Authenticated SMTP server, if 
available (preferred).


I don't, yet, have multiple "example.com/error-one.html" and 
"error-two.html" landing pages, but the forward-thinking software 
engineer in me thinks, "Maybe I, or somebody else, WILL want that 
someday..."  If the more prudent approach is to wait and cross jump that 
bridge when we come to it, that's fine, too.  I don't know enough about 
Postfix's internals to appreciate the level of effort involved (ie, 
whether it's easier/harder to go: Zero -> One -> Many, or Zero -> Many.)


I appreciate your-all's willingness to explore the issue, though!  Even 
if we only end up with Wietse's general-purpose error banner, I still 
think we've made progress.


PS - Here's an updated patch 
 that includes 
manpage/documentation updates as well:


  http://Parabon.com/pub/postfix-unk_client_why.patch

Cheers,

--
:- Dabe

--
:- Dabrien "Dabe" Murphy
:- Sr. Solutions Engineer
:- Parabon Computation, Inc.
:- Frontier® Grid Support Operations Center
--
:- www.Parabon.com
:- "Computing Outside the Box"
--
:- Email: d...@parabon.com

Re: Configurable replies for hardcoded REJECTS?

[Wietse Venema]

Dabrien 'Dabe' Murphy:
> Wietse Venema wrote:
> > Instead of having to maintain a bazillion different reply parameters,
> > would not it be sufficient to have one generic reply line that
> > gets appended to all those reject commands?
> >
> 
> Hi Wietse,
> 
> If the dilemma is between:

I was thinking of adding a second line to the antispam reject
messages. For example:

550-5.7.1 The existing reject message
550 5.7.1 Please see http://foo.example.com/ for support.

I don't think that it makes sense to do fine-grained customizations
for each possible reject reason.

Wietse

Re: Configurable replies for hardcoded REJECTS?

[Charles Marcus]

On 8/13/2009, Dabrien 'Dabe' Murphy (d...@parabon.com) wrote:
>> Instead of having to maintain a bazillion different reply parameters,
>> would not it be sufficient to have one generic reply line that
>> gets appended to all those reject commands?

> * Implementing your proposed work-around quickly, or
> * Waiting several months (or longer) for the "ideal" solution
> 
> then yes, I could make do with one global error message.  Heck,
> Microsoft has been doing that for years: "A General Error has
> occurred.  Press any key to reboot."

Maybe I'm wrong, but I took it to mean you could do something like:

reject_unknown_hostname "here's the reason I rejected your message"

-- 

Best regards,

Charles

Re: Configurable replies for hardcoded REJECTS?

[Dabrien 'Dabe' Murphy]

Wietse Venema wrote:

Instead of having to maintain a bazillion different reply parameters,
would not it be sufficient to have one generic reply line that
gets appended to all those reject commands?
   


Hi Wietse,

If the dilemma is between:

   * Implementing your proposed work-around quickly, or
   * Waiting several months (or longer) for the "ideal" solution

then yes, I could make do with one global error message.  Heck, 
Microsoft has been doing that for years: "A General Error has occurred.  
Press any key to reboot."


However, I'm not sure I understand where the additional burden comes in; 
nine times out of ten, a site administrator can simply accept the 
defaults, and override only the specific messages he or she deems 
necessary (so SHE doesn't have to maintain a bazillion different reply 
parameters); and smtpd_check.c already *HAS* the bazillion different 
reply strings burned in.  This would simply[*] be a matter of extracting 
those hard-coded strings from the source, and moving them into the 
configuration file.


* - It seems "simple" to my untrained eye, anyway...  If the regression 
process makes adding new configuration parameters onerous, or there's 
something else going on behind the scenes that I'm not aware of, then by 
all means, please feel free to enlighten me.


Is it because of the "%s" placeholders?  I'd be fine with a set of 
optional "_why" strings that are /appended/ to the current error 
messages, but ideally, I'm sure I'd want the ability to customize each 
message, rather than one catch-all 'Press any key to continue' blanket 
statement.


Another consideration, I suppose, is if the ";" semicolon separator 
between the error code and the from=<> and to=<> diagnostics is 
"magic".  In that case, users should avoid using semicolons in their 
"_reason" lines, and I'm sure the "correct" thing to do would be to spit 
out a warning (which, yeah, is a lot of work...)


Anyway, I didn't feel like holding my breath waiting for these changes 
to propagate upstream; I just went ahead and voided my warranty, editing 
the source from the OpenBSD 4.5 ports.tgz.  Attached is a patch that 
adds support for an "unknown_client_reject_reason" parameter (char 
*var_unk_client_why).  Similar params should be pretty straightforward, 
methinks.


Thanks Wietse!  :-D

--
:- Dabe

--
:- Dabrien "Dabe" Murphy
:- Sr. Solutions Engineer
:- Parabon Computation, Inc.
:- Frontier® Grid Support Operations Center
--
:- www.Parabon.com
:- "Computing Outside the Box"
--
:- Email: d...@parabon.com


diff -ur w-postfix-2.6.20090125/postfix-2.6-20090125/src/global/mail_params.h 
DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/global/mail_params.h
--- w-postfix-2.6.20090125/postfix-2.6-20090125/src/global/mail_params.h
Thu Jan 22 16:16:34 2009
+++ DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/global/mail_params.h  
Thu Aug 13 01:02:01 2009
@@ -1945,6 +1945,10 @@
 #define DEF_UNK_CLIENT_CODE450
 extern int var_unk_client_code;
 
+#define VAR_UNK_CLIENT_WHY "unknown_client_reject_reason"
+#define DEF_UNK_CLIENT_WHY ""
+extern char *var_unk_client_why;
+
 #define PERMIT_INET_INTERFACES "permit_inet_interfaces"
 
 #define PERMIT_MYNETWORKS  "permit_mynetworks"
diff -ur w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd.c 
DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd.c
--- w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd.c   Fri Jan 
 9 20:36:15 2009
+++ DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd.c Thu Aug 
13 01:03:02 2009
@@ -1058,6 +1058,7 @@
 char   *var_data_checks;
 char   *var_eod_checks;
 int var_unk_client_code;
+char   *var_unk_client_why;
 int var_bad_name_code;
 int var_unk_name_code;
 int var_unk_addr_code;
@@ -4974,6 +4975,7 @@
VAR_MILT_DAEMON_NAME, DEF_MILT_DAEMON_NAME, &var_milt_daemon_name, 1, 0,
VAR_MILT_V, DEF_MILT_V, &var_milt_v, 1, 0,
VAR_STRESS, DEF_STRESS, &var_stress, 0, 0,
+   VAR_UNK_CLIENT_WHY, DEF_UNK_CLIENT_WHY, &var_unk_client_why, 0, 0,
VAR_UNV_FROM_WHY, DEF_UNV_FROM_WHY, &var_unv_from_why, 0, 0,
VAR_UNV_RCPT_WHY, DEF_UNV_RCPT_WHY, &var_unv_rcpt_why, 0, 0,
0,
diff -ur w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd_check.c 
DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd_check.c
--- w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd_check.c Fri Jan 
 9 18:15:08 2009
+++ DABE__w-postfix-2.6.20090125/postfix-2.6-20090125/src/smtpd/smtpd_check.c   
Thu Aug 13 00:59:29 2009
@@ -948,8 +948,8 @@
return (smtpd_check_reject(state, MAIL_ERROR_POLICY,
state->name_status >= SMTPD_PEER_CODE_PERM ?
   var_unk_client_code : 450, "4.7.1",
-   "Client host rejected: cannot find your hostname, [%s]",
-  state->addr));
+   "Client host rejected: cannot fin

Re: Configurable replies for hardcoded REJECTS?

[Wietse Venema]

OneTrueDabe:
> As Patrick mentioned, it would be nice to have, e.g.:
> 
>   unknown_address_reject_reason
>   unknown_hostname_reject_reason
>   unknown_client_reject_reason
>   ... etc.

And I will also repeat my reply.

Instead of having to maintain a bazillion different reply parameters,
would not it be sufficient to have one generic reply line that
gets appended to all those reject commands?

Wietse

Re: Configurable replies for hardcoded REJECTS?

[OneTrueDabe]

Patrick Ben Koetter wrote:
> 
> a customer asked me to help them customize Postfix replies, so clients
> (better: users) can get a hint why their message is being rejected.
> 
> The idea is to refer to an URL in the reply where (generic) verbose
> explanations on the reject reason can be found. Something along these
> lines:
> 
>   5xx REJECT: See http://www.example.com/plaintext_reject_code
> 

Sorry for dredging up a months-old thread, but I was searching for a similar
answer myself.

We implement the full gamut of "reject_unknown_sender_domain"-type checks,
and therefore end up blocking mail from misconfigured sites whose IP
addresses don't reverse-resolve back to valid hostnames, etc. 
Unfortunately, this means that certain legitimate-but-broken customers have
trouble sending us email.

I'd like to include a link in the "554" message, directing people to the "
http://parabon.com/reverse-dns.html reverse-dns.html " explanation we have
on our website, just as a first-line defense to provide their IT departments
the requisite information to solve the problem.

As Patrick mentioned, it would be nice to have, e.g.:

  unknown_address_reject_reason
  unknown_hostname_reject_reason
  unknown_client_reject_reason
  ... etc.

to go along with:

  unknown_address_reject_code
  unknown_hostname_reject_code
  unknown_client_reject_code
  ... etc.

I'm sure there are more important features than this seemingly simple
request, but I just wanted to voice my own +1 vote for this "diagnostic
enhancement".

Thanks, all!  :-D

-- 
:- Dabe
-- 
View this message in context: 
http://www.nabble.com/Configurable-replies-for-hardcoded-REJECTS--tp23096401p24928488.html
Sent from the Postfix mailing list archive at Nabble.com.

Re: Configurable replies for hardcoded REJECTS?

[Ralf Hildebrandt]

* Wietse Venema :

> I don't think it is a good idea to tweak each individual reject
> message. It makes perhaps more sense to append the same "for support
> please (call xxx|see http://mumble/)" text to all reject messages.

That was my proposal when he called me.

> Of couse no-one ever reads such text, so it is mainly CYA stuff.

I can confirm that :)

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
When asked68% of corporate execs said a corporation
"Who owns the Internet?": 23% said it was Microsoft
  98% of 6th graders said: no one.

Re: Configurable replies for hardcoded REJECTS?

[Patrick Ben Koetter]

* Wietse Venema :
> > a customer asked me to help them customize Postfix replies, so clients
> > (better: users) can get a hint why their message is being rejected.
> > 
> > The idea is to refer to an URL in the reply where (generic) verbose
> > explanations on the reject reason can be found. Something along these lines:
> > 
> >   5xx REJECT: See http://www.example.com/plaintext_reject_code
> > 
> > I can customize replies for access(5) maps and for RBL maps.
> > 
> > What I miss is a way to append text to the following rejects that currently
> > only allow to set a code:
> > 
> >   access_map_reject_code
> >   defer_code
> >   invalid_hostname_reject_code
> >   multi_recipient_bounce_reject_code
> >   non_fqdn_reject_code
> >   plaintext_reject_code
> >   reject_code
> >   relay_domains_reject_code
> >   unknown_address_reject_code
> >   unknown_client_reject_code
> >   unknown_hostname_reject_code
> >   unknown_local_recipient_reject_code
> >   unknown_relay_recipient_reject_code
> >   unknown_virtual_alias_reject_code
> >   unknown_virtual_mailbox_reject_code
> >   unverified_recipient_reject_code
> >   unverified_sender_reject_code
> > 
> > Did I miss something? If not, do you believe its worth to be added? (Of 
> > course
> > not now while 2.6 is on its way and while other work ... and ...).
> 
> If it isn't documented, then you cannot use it.

I knew you were going to say that...


> I don't think it is a good idea to tweak each individual reject
> message. It makes perhaps more sense to append the same "for support
> please (call xxx|see http://mumble/)" text to all reject messages.
> Of couse no-one ever reads such text, so it is mainly CYA stuff.

I agree on the end users, but think it would be helpful to postmasters (at
least it was to me).

AOL uses something like this when they block you. As a postmaster this was
helpful to me figuring out what had gone wrong on a customers machine.


> This text woud have to be spliced into the output stream in function
> smtpd_chat_reply(). Couple hours work for implementing testing,
> documenting, making sure it handles 421 and 521 replies, etc., and
> making sure that nothing calls smtpd_chat_reply() multiple times
> for one reply, and considering what happens with Simon's multiple
> replies patch.

Yeah, I thought so (concering the time and efforts it would take). Sounds like
low priority to me at the moment.

Thanks,

p...@rick


-- 
The Book of Postfix

saslfinger (debugging SMTP AUTH):

Re: Configurable replies for hardcoded REJECTS?

[Wietse Venema]

Patrick Ben Koetter:
> Wietse,
> 
> a customer asked me to help them customize Postfix replies, so clients
> (better: users) can get a hint why their message is being rejected.
> 
> The idea is to refer to an URL in the reply where (generic) verbose
> explanations on the reject reason can be found. Something along these lines:
> 
>   5xx REJECT: See http://www.example.com/plaintext_reject_code
> 
> I can customize replies for access(5) maps and for RBL maps.
> 
> What I miss is a way to append text to the following rejects that currently
> only allow to set a code:
> 
>   access_map_reject_code
>   defer_code
>   invalid_hostname_reject_code
>   multi_recipient_bounce_reject_code
>   non_fqdn_reject_code
>   plaintext_reject_code
>   reject_code
>   relay_domains_reject_code
>   unknown_address_reject_code
>   unknown_client_reject_code
>   unknown_hostname_reject_code
>   unknown_local_recipient_reject_code
>   unknown_relay_recipient_reject_code
>   unknown_virtual_alias_reject_code
>   unknown_virtual_mailbox_reject_code
>   unverified_recipient_reject_code
>   unverified_sender_reject_code
> 
> Did I miss something? If not, do you believe its worth to be added? (Of course
> not now while 2.6 is on its way and while other work ... and ...).

If it isn't documented, then you cannot use it.

I don't think it is a good idea to tweak each individual reject
message. It makes perhaps more sense to append the same "for support
please (call xxx|see http://mumble/)" text to all reject messages.
Of couse no-one ever reads such text, so it is mainly CYA stuff.

This text woud have to be spliced into the output stream in function
smtpd_chat_reply(). Couple hours work for implementing testing,
documenting, making sure it handles 421 and 521 replies, etc., and
making sure that nothing calls smtpd_chat_reply() multiple times
for one reply, and considering what happens with Simon's multiple
replies patch.

Wietse

Configurable replies for hardcoded REJECTS?

[Patrick Ben Koetter]

Wietse,

a customer asked me to help them customize Postfix replies, so clients
(better: users) can get a hint why their message is being rejected.

The idea is to refer to an URL in the reply where (generic) verbose
explanations on the reject reason can be found. Something along these lines:

  5xx REJECT: See http://www.example.com/plaintext_reject_code

I can customize replies for access(5) maps and for RBL maps.

What I miss is a way to append text to the following rejects that currently
only allow to set a code:

  access_map_reject_code
  defer_code
  invalid_hostname_reject_code
  multi_recipient_bounce_reject_code
  non_fqdn_reject_code
  plaintext_reject_code
  reject_code
  relay_domains_reject_code
  unknown_address_reject_code
  unknown_client_reject_code
  unknown_hostname_reject_code
  unknown_local_recipient_reject_code
  unknown_relay_recipient_reject_code
  unknown_virtual_alias_reject_code
  unknown_virtual_mailbox_reject_code
  unverified_recipient_reject_code
  unverified_sender_reject_code

Did I miss something? If not, do you believe its worth to be added? (Of course
not now while 2.6 is on its way and while other work ... and ...).

  p...@rick

-- 
The Book of Postfix

saslfinger (debugging SMTP AUTH):