Hi,
The exceptions I talked about were not due to james (probably a
misconfiguration or thunderbird bug).
Current trunk is thus operational as such (no need to change
ValidRcptHandler). Sorry for the noise about potential james bug.
The API/Impl remains subject to discussion (see [1] impl in
AbstractVirutalUserTable and [2] which is the management API).
There are tests in [1] to validate params as null, there is no
management method to create domain and regexp mapping (or you need to
use prefix with null params), I'm confusing with the "james user" and
the "email user part".
Yes, we don't need only "link between users" (I forgot the regex,
aliasdomain,...).
So a RecipientRewriteTable (RRT) makes also sense to me.
I will propose an update on the management to better reflect the
functionality (just feed me if you've got some ideas).
Tks,
Eric
[1]
if (map.startsWith(VirtualUserTable.ERROR_PREFIX)) {
addErrorMapping(user,domain,map.substring(VirtualUserTable.ERROR_PREFIX.length()));
} else if (map.startsWith(VirtualUserTable.REGEX_PREFIX)) {
addRegexMapping(user,domain,map.substring(VirtualUserTable.REGEX_PREFIX.length()));
} else if (map.startsWith(VirtualUserTable.ALIASDOMAIN_PREFIX)) {
if (user != null) throw new VirtualUserTableException("User
must be null for aliasDomain mappings");
addAliasDomainMapping(domain,map.substring(VirtualUserTable.ALIASDOMAIN_PREFIX.length()));
} else {
addAddressMapping(user,domain,map);
}
[2]
public void addRegexMapping(String user, String domain, String
regex) throws Exception;
public void removeRegexMapping(String user,String domain, String
regex) throws Exception;
public void addAddressMapping(String user, String domain, String
address) throws Exception;
public void removeAddressMapping(String user,String domain, String
address) throws Exception;
public void addErrorMapping(String user, String domain, String
error) throws Exception;
public void removeErrorMapping(String user,String domain, String
error) throws Exception;
public Collection<String> getUserDomainMappings(String user, String
domain) throws Exception;
public void addMapping(String user, String domain, String mapping)
throws Exception;
public void removeMapping(String user, String domain, String
mapping) throws Exception;
public Map<String,Collection<String>> getAllMappings() throws
Exception;
On 27/01/2011 08:43, Norman Maurer wrote:
2011/1/26 Stefano Bagnara<[email protected]>:
Il 26 gennaio 2011 10.00.39 UTC+1, Eric Charles<[email protected]> ha scritto:
Hi,
So we've got the api: "alias maps to existinguser" :)
1. Should alias always exist as user?
1.1 no => we need to update ValidRecipientHandler (and maybe other smtp
handlers) to make it work, otherwise users will be sorry.
1.2 yes => we could automatically create the alias user if it does not
exists (but with which password ?) or throw an exception asking to create
the user beforehand.
1.1
IIRC we ValidRecipientHandler also supports an additional regex to
match further addresses (in case you want to deal with them with
mailets): do I remember correctly? Otherwise I think we should support
this someway, so we get the benefits of fast fail during SMTP
conversation also when people wants to write mailet based processors.
2. Can we map to a non-existing user (for further processing but
mailets,...)
2.1. no => we could automatically create the user if it does not exist (but
with which password ?) or throw an exception asking to create the user
beforehand.
2.2 yes => we need to update ValidRecipientHandler (and maybe other smtp
handlers) to make it work, otherwise users will be sorry.
2.2
3. Should we stricly follow the other MTAs working
3.1. no => this may be confusing for users used to other MTAs (btw we
already diverge with the virtualhosting enabled by default)
3.2. yes => we benefit from all the experience of those MTAs, but we may be
3.2
My preference goes to 1.2, 2.1 and 3.1.
I see virtualusers more like "links between existing users". The link can be
set or can be removed, users are there and remain.
Maybe "virtual user" is not a good name. I see it as a generic rewrite method.
With a single map I can add aliases, custom errors, 1-to-many
recipients, domain mappings and much more.
I agree...
I think the old 2.3 behaviour was not good nor intuitive WRT user
aliasing and forwarding (that required fake users to create aliases)
and in fact we agreed to remove aliasing and forwarding from core
because it was a weird/unexpected behaviour.
I know I'm not a good target user for this because I used sendmail
since '96 so much that I've been used to Eric Allman language for
rewriting (but thanks God I forgot the language now!) but I don't know
any MTA using virtual users as mapping between users like you explain
in this mail.
You should be very happy you forgot about the language ;)
That said we can even have both behaviours supported by different
implementations. Maybe the behaviour I propose is better reflected by
a "RecipientRewriteTable" name instead of "VirtualUserTable" name.
Stefano
I like the name.. I think it would be much better explain the usage :)
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
