Using ISPconfig 3.1 I setup a mail forward, [email protected], which forwards to an offsite mail account. I then setup a mailbox (because I need to use smtp auth) of [email protected] which copies my address and [email protected]. Emailing that mailbox copies me but fails with 'user unknown' for the [email protected] forward. The workaround is to create [email protected] as a mailbox, not a forward, although I really don't want an [email protected] mailbox (ie. I don't want to store any mail locally). I tried to change [email protected] to a forward, and create another mailbox [email protected] solely for smtp auth, but I can't send mail 'From' [email protected] if I auth as [email protected] (it says, 'Sender address rejected: not owned by user [email protected]'), and I don't want to send 'From' [email protected] as I don't want people replying to that (and eventually filling up the mailbox). It seems simple, I just want to send email from an address that forwards offsite, and doesn't save mail into a local mailbox. Is this a bug or a known limitation to live with? Or am I missing something in the setup? Thanks
In ISPConfig 3 versions before 3.1, an authenticated user could use any FROM address for sending, a lot of users complained that we did not restrict the from address and so we added a restriction in ISPConfig 3.1 that the from address has to match the authenticated account or one of its aliases. Personally, I'm not a big fan of this limitation but I can understand that many users need it to prevent misuse. I guess there are two options, either change the postfix configuration back to the setup that ispconfig used before 3.1 or you do the forwarding with a line of sieve script in the custom rules box of the mailbox instead of using a email forward.
How will this affect users who have forwards set up and then I upgrade to 3.1? Will it only prevent future attempts to do the forwarding the new way or will it screw up already established forwarders set up before 3.1?
My post above was about the smtp-auth part only. Forwarding is a global postfix setup in main.cf, so it will affect all accounts of an updated system. I use several forwarders myself and I'm not affected by any forwarding issue on my system in ISPConfig 3.1. I tried to reproduce it here but I can forward without issues. 1) Created domains domain1.com and domain2.com 2) Created 2 mailboxes [email protected] and [email protected] 2) Created a forward [email protected] which forwards do [email protected] and [email protected] When I send an email to [email protected], it arrived in both mailboxes. Aug 15 09:50:04 server1 postfix/smtp[4439]: BC72F340147: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.42, delays=0.06/0/0.01/0.36, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 284763406FA) Aug 15 09:50:04 server1 postfix/qmgr[13827]: BC72F340147: removed Aug 15 09:50:04 server1 dovecot: lda([email protected]): sieve: msgid=<[email protected]>: stored mail into mailbox 'INBOX' Aug 15 09:50:04 server1 postfix/pipe[4875]: 284763406FA: to=<[email protected]>, orig_to=<[email protected]>, relay=dovecot, delay=0.05, delays=0.01/0/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service) Aug 15 09:50:04 server1 dovecot: lda([email protected]): sieve: msgid=<[email protected]>: stored mail into mailbox 'INBOX' Aug 15 09:50:04 server1 postfix/pipe[4870]: 284763406FA: to=<[email protected]>, orig_to=<[email protected]>, relay=dovecot, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot service)
Looking at /etc/postfix/mysql-virtual_sender_login_maps.cf it looks like the sender login setup is quite sane, in your example you should be able to login as either [email protected] or [email protected] and send from (envelope sender) [email protected] (as long as that forward has the 'Send as' checkbox enabled). For anyone needing it, the 'Reject sender and login mismatch' checkbox under Server Config should restore the old behavior. In checking my original findings I must have had something wrong the other day, as having a mailbox copy to a mail forward seems to work correctly now. The other concern of having an account type/option that can send but doesn't have a mailbox has valid use cases. I can do a sieve filter for now, but that seems worth an rfe.
The question that I have is how often it is used and if it is not ok in such a case to create just a cryptic email account name if one really needs such a send only account. It is possible to implement such a special account type off course or split smtp accounts and mailboxes, but it makes the setup more complicated and adding more and more features can make the setup unstable or unmaintainable on the long run. In my opinion, we have to be careful to not overload ISPConfig with too many features. I receive more and more requests from ISP's to reduce the functionality instead of extending it as their clients don't know how to use all these features that ISPConfig offers.
While plenty of things send and don't receive (printers, websites, routers and misc. IoT devices, ...), I can appreciate the feature creep concern, and just create a sieve filter. Maybe introduce a simplified vs. full mode in the ui, and hide some of the less common features ?
FYI on my initial mailbox -> forward problems, I couldn't recreate any problem scenarios, but my actual mailbox/forward still failed - the cause seems to be a bad mailbox creation on the mail server, and the solution was to delete it and recreate with same settings. Even emailing to the mailbox failed with dovecot lda errors, and this is just goofy: Code: # doveadm user [email protected] field value uid 5000 gid 5000 home /var/vmail/d1.com/webmaster mail :/var/vmail/d1.com/webmaster/ quota_rule *:storage=104857600B sieve /var/vmail/d1.com/webmaster/.sieve The 'mail' line is broken, after recreating it looks like: Code: # doveadm user [email protected] field value uid 5000 gid 5000 home /var/vmail/d1.com/webmaster mail maildir:/var/vmail/d1.com/webmaster/Maildir quota_rule *:storage=104857600B sieve /var/vmail/d1.com/webmaster/.sieve
Please check the database record of the affected mailbox in case that this happens again, maybe the mailbox format settings was missing there.
I do have an sql backup from the most recent ispconfig update (8/15). This is the mail_user INSERT INTO record on the ispconfig master server: Code: (6,7,6,'riud','riud','',2,'[email protected]','[email protected]','$1$1WHW3vzm$M7M.8NcGxSaaJDHzI.idO.','Some Name',5000,5000,'/var/vmail/d1.com/webmaster','',104857600,'[email protected]','','/var/vmail','n',NULL,NULL,'Out of office reply',NULL,'n',NULL,'y','y','y','n','n','n','n','n','n','n','n','n',NULL,'none',1) And comparing that to another record for a working mailbox (different domain) does show the 'maildir' is missing from the maildir_format column: Code: (7,6,5,'riud','riud','',2,'[email protected]','[email protected]','$1$MFOtgzjE$Zq7333gRqzVEav4w24mk1/','',5000,5000,'/var/vmail/d2.org/user','maildir',524288000,'','','/var/vmail','n',NULL,NULL,'Out of office reply','','n',NULL,'y','n','y','n','n','n','n','n','n','n','n','n',NULL,'none',1) Checking my db right now, all other mail_user records are set, so I'll just ignore this unless you need more info. The system has been running 3.1 through a lot of updates, and I've had to fix a few things directly in the database at times, so I could have even manually/accidentally wiped that column out by mistake. Who knows...
The empty column explains the issue. It might also be that there was an issue in one of the first 3.1 pre-releases.