<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffff99" text="#000000">
<font size="+1"><font face="Helvetica, Arial, sans-serif">Thanks,
Jorey, this was the missing link! Now it works as I expected it to
(good work, Andrew!).</font></font><br>
<pre class="moz-signature" cols="72">Kind regards,

Edwin Boersma
Lead Developer Web Applications

SecureOffice Europe AB
Ideon Science Park B2 floor 2
Scheelev&auml;gen 17
22363 Lund
Sweden

W: <a class="moz-txt-link-freetext" href="http://www.secureoffice.net">http://www.secureoffice.net</a>
T: +46 462868773
M: +46 709726431</pre>
<br>
<br>
Jorey Bump wrote:
<blockquote cite="mid:49A2A150.80106@joreybump.com" type="cite">
  <pre wrap="">Edwin Boersma wrote, at 02/23/2009 07:43 AM:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,

Just to make it clear: the problem only occurs with the default domain,
not with other virtual domains. All user are in the SQL database, and
cyrus does a correct translation to the mailbox for all the others. The
only problem is that the default domain is replaced with the local
computer name.
    </pre>
  </blockquote>
  <pre wrap=""><!---->[snip]
  </pre>
  <blockquote type="cite">
    <pre wrap="">In my opinion (can you give me yours, Andrew?), cyrus should not rewrite
the default domain when using %r, but internally redirect to the local
mailbox (so after login). Or provide a mechanism where the local mailbox
is transformed into a virtual domain box.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">2009/2/18 Edwin Boersma <a class="moz-txt-link-rfc2396E" href="mailto:edwin.boersma@secureoffice.net">&lt;edwin.boersma@secureoffice.net&gt;</a>:
  
      </pre>
      <blockquote type="cite">
        <pre wrap="">Hi,

To be able to have user names like &lt;user&gt;@&lt;our.domain&gt; and
&lt;sameuser&gt;@&lt;another.domain&gt;, I have changed our IMAP config to use virtual
domains. To be able to access the existing mailboxes, I added the
"defaultdomain" option to imapd.conf.
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
You will probably also want to set servername to prevent cyrus from
using gethostname:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Here's the imapd.conf:
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">defaultdomain: secureoffice.net
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  servername: secureoffice.net


Is there a problem you are trying to solve with user@domain logins? In
most cases, this is done to support similar logins across multiple
domains (<a class="moz-txt-link-abbreviated" href="mailto:support@example.com">support@example.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:support@example.net">support@example.net</a>, etc.). However, I
find that this confuses clients, who will try to use alias addresses as
logins, and prefer to assign unique logins across all domains
(foosupport, barsupport, etc.). This way, I don't need to enable
virtdomains in Cyrus IMAPd, and just put everyone in the same realm (a
single arbitrary domain, it doesn't even need to exist in DNS or accept
email). Then I set defaultdomain and servername to that realm in
imapd.conf along with smtpd_sasl_local_domain in the Postfix main.cf. As
a result, all lookups are done against this single realm and users can
authenticate with a bare login without appending the realm. This
approach still supports multiple email domains, but simplifies
configuration and may even improve portability (but I'm using sasldb,
not SQL, so there may be other issues I'm not considering). The only
caveat is that all logins must be unique; two users of different
accounts can't each login as "support". On the other hand, this
arrangement has come in handy when we've had to replace heavily spammed
public addresses like <a class="moz-txt-link-abbreviated" href="mailto:info@example.com">info@example.com</a> with <a class="moz-txt-link-abbreviated" href="mailto:information@example.com">information@example.com</a>,
because it isn't necessary to change login credentials in the client. I
only mention this as an alternative, in case you really don't need to
support full user@domain logins.


  </pre>
</blockquote>
</body>
</html>