Re: [exim] SMTP-time rewriting

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] SMTP-time rewriting
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.


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.