Re: [exim] SMTP-time rewriting

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Nikita Koshikov
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] SMTP-time rewriting
On Tue, 22 Jun 2010 16:29:12 -0400
W B Hacker wrote:

> Nikita Koshikov wrote:
> > On Tue, 22 Jun 2010 09:51:08 -0400 W B Hacker wrote:
> >
> >> May one ask where an address of that form is originating - how it is
> >> getting into Exim's environment, and whether it really is at 'smtp time' (a
> >> submission session with a correspondent).
> >>
> >> as in:
> >>
> >> - MUA with 'experimental' settings
> >>
> >> - On-box (binary invocation, queue injection, smtp session) MLM,
> >>
> >> - script or web-app
> >>
> >> - *prior* address-rewrite
> >>
> >> or, perchance, is the '*' in your example actually a wildcard that does not
> >> itself exist, but rahtehr represents a variety of other possible strings?
> >>
> >> I ask because, *as shown* the right side is not a legal/recognizable
> >> domain.tld format, with a literal '*' in it, never mind .admin' not being
> >> any tld or country I'm aware of...
> >>
> >> More to the point, if you can share what the end goal is, the 'why you need
> >> it' situation, perhaps someone here may have another way that is already
> >> proven.
> >>
> >
> > I have setup Exim with Dovecot as imap server. Dovecot has such feature as
> > "master users" - such users can login as "other-user" account, so if you want
> > login as user 'test@???' you enter
> > 'test@???(separator)master_user'. Separator is configurable. When you
> > logged in as master user, MUA (in my setup webmail) set headers from, sender,
> > etc in format user@domain*master_user. This prevent exim from sending mail
> > originating by master_users. More often became situation - when I got ticket
> > in helpdesk - "Please send mail as sender X, because he is in vacation to
> > client Y", "Or forward e-mail from mailbox X to Y, owner of X is not
> > available now" etc. I want exim to solve this issues, and master_user can
> > handle such requests. With S flag added to rewrite I'm able to send e-mail,
> > but headers still contain identity of master_user - this should be fixed.
> >
>
> Ah So!
>
> OK - Probably many ways to solve the problem - no re-write required:
>
> Given:
>
> A shared 'role' ID (helpdesk@, support@, info@, sales@) - is just one more
> virtual account, actually has login credentials of its own, and can send as that
> rolename *if required*. 'reply-to' change optional.
>
>
> A)
>
> The simplest is sharing the password for the role at the team-member level and
> adding the 'helpdesk@' or other role account settings and credentials to each
> user MUA as an extra identity. IMAP sync handles the rest.
>


I'll use this scheme for now, but I need to implement group functionality for correcting this. When 1-2 people can handle all domain mailboxes - it's ok, but when team-leaders can send e-mail not only from their team-group - it must be prevented.

>
> B) Where that is not as secure or manageable as you like, another way has worked
> for us:
>
> - 'team' members supporting a role do not ordinarily login as the role ID, but
> one or more supervisors may do so (password shared only among Managers) [1].
>
> - Inbox, Sent, and any subfolders of each role ID are softlinked in the
> mailstore such that each assigned team member 'sees' the folder-set for that
> role. Some staff may have multiple roles.
>
> The way we use it, Exim's daemon ID is Mailstore owner, Dovecot a member of the
> same group. Owner and group have rwx privs, world has NO privs.
>
> User and role accounts have no 'system' ID or file ownership of their own, all
> that is managed by the virtualization scheme. (PostgreSQL here - but it
> shouldn't matter).
>
> Response to incoming by team members MAY be personalized with their own address
> and subsequent correspondence go 'one-on-one'. Or not. Manipulate 'Reply-To:'
>
> One may use an 'unseen' router/transport to insure copying role-specific traffic
> back to the group folders AND/OR make a separate archive for management in case
> of unwanted deletions by staff.
>
> Setting up the softlinks is a minor PITA [2], but probably not changed very often.
>
> NB: Dovecot may be doing something similar behind the scenes, and we do use
> Dovecot, but prefer a more portable solution.
>
> HTH,
>
> Bill
>
> [1] A virtualization scheme can also support multiple access to the same folders
> by multiple ID's with unique passwords.
>
> [2] One can do it in the virtualization DB, but softlinks seemed simpler when
> there are only a few roles and small teams.


Thanks, for sharing your experience, but this is to complex to administer. This requires modification on server side, and that is the last what I'll choose. I prefer to create scheme where changes will be added to user-database(ldap here).