The following bug has been CLOSED
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assigned
The following bug has been RESOLVED.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assign
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
Aaron Stone wrote:
DBMail's authldap was designed to work with three well-known and working
LDAP schemas: inetOrgPerson, qmail-ldap and Exchange. All three keep
aliases together with user accounts, as does DBMail, both now and at the
time I wrote the authldap module. So this is a natural. Separa
On Fri, Jan 14, 2005, Paul J Stevens <[EMAIL PROTECTED]> said:
> Why do we want to store alias information in the database: delivery
> Why do we want to store user information in the database: authentication
>
> Both are at present totally intertwined, both in the code, and in the
> perception of
Hi,
Is it really worth the effort to develop the aliasing in dbmail, with all
error handling etc.
Isn't it other issues that could use our attention better?
Howabout using your MTA.
What's going on here? Nobody is talking about new developments. There is
a bug in the *existing* dbmail func
Hello,
I agree fully with Paul. There are a lot of things to develop within
DBMail. MTAs are well documented and have done aliasing well for many
years, the MTAs also communicate with a lot of databases for alias lookup.
Is it really worth the effort to develop the aliasing in dbmail, with all
erro
Howabout using your MTA.
And yes, I know, people keep wanting to use dbmail to solve *all* their email
management problems. And I also know that was one of Roel and Eelco's original
design goals.
In my opinion the authsql user-management is already severely overloaded and in
serious need of
Hi,
What about that one: I have a user [EMAIL PROTECTED], no aliases. Then I go to
holiday and add an alias [EMAIL PROTECTED]>[EMAIL PROTECTED]
I would expect that I only get a copy and every mail still is in my
[EMAIL PROTECTED] INBOX.
But what if you want a temporary forward and *no* delive
Aaron Stone wrote:
> On Fri, Jan 14, 2005, Thomas Mueller <[EMAIL PROTECTED]> said:
>
> Currently:
> >> > if (address is username)
> >> > put username on delivery list
> >> > else
> >> > if (address has aliases)
> >> > resolve aliases into deliveries and forwards
>
> Aaron's Prop
On Fri, Jan 14, 2005, Thomas Mueller <[EMAIL PROTECTED]> said:
Currently:
>> > if (address is username)
>> > put username on delivery list
>> > else
>> > if (address has aliases)
>> > resolve aliases into deliveries and forwards
Aaron's Proposal:
>> > if (address has aliases)
>>
On Fri, Jan 14, 2005, Thomas Mueller <[EMAIL PROTECTED]> said:
> The clean way to close accounts would be to add a column for that to the
> database.
Yep, this is the right way to do it. We really should finish specifying
what we want out of these 'permissions' and gets it into 2.1.
Aaron
On Fri, Jan 14, 2005, Ondrej Sury <[EMAIL PROTECTED]> said:
> I think that whole problem is more deeper than it seems. Maybe it is
> silly to have alias for each username, but if you use postfix
> local_recipient_maps to prevent backscatter mail then it will broke when
> you don't add alias equal
On Fri, Jan 14, 2005, Michael Häusler <[EMAIL PROTECTED]> said:
>> I don't consider it silly to have one table with ALL valid email
>> addresses, so you don't have to do double lookups.
>
> Furthermore, I consider it a feature not to automatically deliver to
> users. This allows you to close acc
Hi,
> >I don't consider it silly to have one table with ALL valid email
> >addresses, so you don't have to do double lookups.
If that is required for external software it can easily be done with a
view that contains dbmail_aliases and dbmail_users.
> Furthermore, I consider it a feature not to a
Hi,
I think that whole problem is more deeper than it seems. Maybe it is
silly to have alias for each username, but if you use postfix
local_recipient_maps to prevent backscatter mail then it will broke when
you don't add alias equaling to username to alias table.
I don't consider it silly to
> Why not:
> if (address is username)
> put username on delivery list
> if (address has aliases)
> resolve aliases into deliveries and forwards
>
> The only difficulty is that double delivery should be prevented in case
> username is [EMAIL PROTECTED] and there is an alias
> [EMAIL PROTECT
Hi Aaron,
> > The change that we'd need is to check the aliases table, too, and abide by
> > it if the delivery address is a forward.
> >
> > I'll repost this on the mailing list, too -- but are there any semantics
> > that would be ruined if we changed from:
> >
> > if (address is username)
> >
I posted this response to the bug tracker, but really want to make sure it
gets read and thought about, so I'm re-posting it.
On Thu, Jan 13, 2005, [EMAIL PROTECTED] said:
> The change that we'd need is to check the aliases table, too, and abide by
> it if the delivery address is a forward.
>
>
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
The following bug has been SUBMITTED.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=159
==
Reported By:OutboundIndex
Assig
24 matches
Mail list logo
