On Mon, 10 Jul 2006, Robert Millan wrote:
> Ok. Please keep me informed.
Your new patch has convinced me that the code should be included with
the message. Why? Consider your own example:
userredirect:
driver = redirect
check_local_user
require_files = $home/.redirect
condition = ${if !exists {$home/.forward}}
verify_only
allow_fail
data = :fail: User not local; please try <${readfile{$home/.redirect}{}}>
smtp_code = 551
This forces the same smtp_code for all redirect failures. It doesn't
permit a file of "aliases" of the form:
user1: :fail: 551 ....
user2: :fail: 55x ....
user3: :defer: 4xx ...
which can be handled with a single redirect router. Before I thought of
this I was thinking of going the other way to make non-SMTP error
handling easier. Now I think I'll just have to parse off the SMTP code
for a non-SMTP error.
What I'm thinking of doing is this:
1. See if the message matches ^\d\d\d\s(\d\.\d{1,3}\.\d{1,3}\s)?
FOR SMTP MESSAGES:
2. If not, add the code as now.
3. Otherwise, if the first digit is the same as the first digit of the
default code, use the provided code instead.
4. Otherwise, log an error, and replace with the current code.
FOR NON-SMTP MESSAGES:
2. If it matches, remove the code from the message.
COMPATIBILITY
This change is not backwards compatible. However, how much does this
actually matter in practice? The only times it will cause a problem is
if an existing configuration is using messages that start with 3 digits.
This does not seem very likely.
There could, of course, be a global option to disable this. I propose
not to implement such a thing because I don't think it would ever be
used.
What do other people think?
Philip
--
Philip Hazel, University of Cambridge Computing Service.