How to receive only to mail alias, not mailbox

Discussion in 'General' started by TonyG, Dec 10, 2020.

  1. TonyG

    TonyG Active Member

    When we send email from an alias, the headers include the login/authenticated ID of the sender. So when I login as foo@domain and send as bar@domain, the recipient still sees foo in the header. I don't think it's appropriate to reveal the login name to recipients. And while we can easily disable some alias addresses, if a spammer gets the primary mailbox ID, we're stuck processing more spam on that account over time.

    So when creating mailboxes, I'd like to use internal names, and only expose external names in headers. In the Mailbox screen we have a checkbox for "Enable receiving", but I believe this is a master switch to disable that mailbox and all associated aliases. I would just want to disable receiving on the mailbox name, but continue receiving on all aliases.

    I believe one way to do this would be to create sieve filters to reject all mail sent directly to a mailbox ID. To avoid having to update that manually it would be necessary to create a lookup table which gets upated from ISPConfig. This gets complicated, so I'd prefer a better way.

    Suggestions?
    Thanks!
     
  2. TonyG

    TonyG Active Member

    Hmm, this might be easily solved from Mailbox > Mail Filter > Add new filter : TO : Localpart "foo" (actual mailbox name) : Reject.
    OR... TO : Contains "foo" : Reject.
    Will try this... Other suggestions are welcome of course.
     
  3. TonyG

    TonyG Active Member

    The Email Filter "To:Contains" does solve this problem. However I reported a problem in this area that can be fixed for now with a bit of file editing.

    Again, other suggestions are welcome, but if no one comments on this for a while I'll mark it Solved.
     
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    From hazy memory: it is possible to configure ISPConfig so the e-mail login is not the e-mail address. This would solve the "revealing login name" -part.
     
  5. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    You can try the alternative login name as @Taleman mentioned, I'm not sure what shows in header in that case. Just set 'smtpd_sasl_authenticated_header = no' if you don't want it showing up.

    You can change the address of a mailbox just as easily as you do an alias in ISPConfig; you of course then have to adjust the username in your mail client(s).

    Add another lookup to smtpd_sasl_authenticated_header that returns REJECT for those. The query should be something like "select distinct('REJECT') from mail_forwarding where destination = '%u' and type = 'alias' and active = 'y' and server_id = 1;"
     
  6. TonyG

    TonyG Active Member

    That is correct, but due to an issue with identity display in Roundcube, I had to switch from login with the login ID to using the mailbox address. As noted in this Roundcube/ISPConfig plugin, I got some insight into how Roundcube uses Identities rather than Aliases. With that understanding I'll try login now with the login ID and see if I can fix up the Identity display. Many environments allow login with either ID or address. It would be nice to see Roundcube do this I'm guessing there are options. I need to do more research. *sigh*

    Again, to be clear, if we need to use a mailbox ID for a login, no matter the MUA, I'm looking at creating a generic mailbox address, filtering to reject mail to that address, and then creating aliases for all expected inbound mail. That's an acceptable solution. The only difference between that and using a pure unique login ID is the @domain added in the login. That's not a bad requirement anyway for people who login to multiple domains.
     
  7. TonyG

    TonyG Active Member

    That's actually the best solution. My initial thinking is that I don't want to display an email address, and that the alternative is to display the login, or block mail to that mailbox. But not displaying the header at all takes care of this and avoids having to mess with how a user does their login. Thanks Jesse - I'll look into this too!
     

Share This Page