mmh, I replayed it and found some strange behaviour, but prolly coming
from my thunderbird client.
So I finally think james's behaviour is safe when creating virtualusers
(no failure on validrcphandler,...)
Sorry for the noise...
Reviewing code, I found a hardcoded value in
AbstractVirtualUserTable:213. I will open an jira.
The question is still open for the API : having
aliasUser/aliasDomain/account can make sense when virtual hosting is
disabled and you need to define an alias on only one domain, and not all
domains.
The naming could be changed: now it is user, which is not really the
"james user". It's more the "user part of the email".
What about "aliasEmailUserPart/aliasEmailDomainPart/toJamesAccount" ?
Tks,
Eric
On 26/01/2011 13:13, Norman Maurer wrote:
Ok just tried it with current trunk.. if there is an alias which maps
to an non exist address it accept the mail via ValidRcptHandler.
Bye,
Norman
2011/1/26 Norman Maurer<[email protected]>:
If thats the case its a bug we should fix..
Bye,
Norman
2011/1/26 Eric Charles<[email protected]>:
With current trunk, I defined a virtualuser, and ValidRecipientHandler
rejected the mail because it does not exist as a "user/recipient".
I don't have the exception anymore cause I finally added the virtualuser as
a user.
I'm also fine with the option to update the ValidRecipientHanlder and have
alias that don't exist as real user.
Tks,
Eric
On 26/01/2011 10:46, Norman Maurer wrote:
Comments inside..
2011/1/26 Eric Charles<[email protected]>:
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.
Could you explain why we need to update the ValidRecipientHandler ? I
think if a mapping exist it should accept the email. If later in the
mailet pipeline we see that there is no real user for the email and it
is not "consumed" by a matcher we will send a bounce. Thats what qmail
+ patches and postfix does and I think thats the correct way of
handling it..
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.
See above..
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
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.
Tks,
Eric
On 25/01/2011 20:15, Norman Maurer wrote:
Hi,
comments inside..
2011/1/25 Stefano Bagnara<[email protected]>:
2011/1/25 Norman Maurer<[email protected]>:
2011/1/25 Eric Charles<[email protected]>:
[...]
2.- Since we enabled the SMTP ValidRcptHandler, we need to really
create the
user, before using it as an virtual user. This was not the case
before.
The
need to previously create a user does not worry me, but I find
strange
that,
depending on smtp configuration, we would or not need to create a
user
to
define a virtualuser.
I think the need of having the existing user before add the mapping is
a good think. We also would need to check if there is a mapping when
deleting a user and remove it too.
I don't agree. I usually think at aliasing as "rewriting" so I expect
to write aliases like this
alias@mydomain maps to existinguser@mydomain
At least this is what I was used to do in sendmail (are other MTA
different from this??)
It's like "search&replace" you usually put "search" on the left and
replace on the "right".
I see your point and I checked other mailservers which seems to behave
like you descripted..
3.- JIRA-1126 Disallow the creation of alias from non-existing
username: I
think this is needed so we don't arrive to situation where mails are
no
more
delivered in case a bad usage of the API (reversing the method
params).
+1
Not sure. I often use aliasing to "virtual addresses". THen I have
matchers to match this virtual addresses and do something.
So they are not users.
In my James I usually have 1 single user that is used from my
webapplication to submit messages, no other james users. Still I use
aliasing.
Sendmail also allow bounces to be generated by virtusertable, e.g:
*@your-comapny.com maps to "error:5.1.1:550 No such user."
(I don't know what aliasing is supported by trunk VUTs, so maybe I'm
completely wrong)
That works for james too ;)
Stefano
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]
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]
---------------------------------------------------------------------
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]
