| Author |
|
solkmaaker
Senior Member
Joined: 28 June 2020
Online Status: Offline
Posts: 154
|
| Posted: 06 March 2021 at 10:05am | IP Logged
|
|
|
Hi
Seems that if user has configured aliases (identities), aurora will use main identity address as envelope-from address passing mail to MTA.
And since envelope-from gets passed from MTA to MTA, it will end up as mail header (if some of those MTA's log envelope-from address)
Further more, header Return-Path will also be set as main identity, not alias.
In example:
User Joe has main identity as joe@domain.com
He also answers support email address support@domain.com which is configured as alias (identity) in aurora.
Now, when replying to support@domain.com e-mails header will be added by aurora Return-Path: joe@domain.com
Joe has couple of days off, but customer answers from previous messages will end up only in Joe's inbox, not support@domain.com inbox (which is distributed other support personnel as well)
This is aurora behavior, we also have aliases configured in Thunderbird and there everything works as expected (envelope from and return-path are set as alias address).
Aurora version 8.6.0
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 08 March 2021 at 12:51am | IP Logged
|
|
|
Hi,
The problem with the suggested approach is that it's simply not working with some mail servers. Originally identities mechanism in our product was implemented the same way you described. However, it assumes that the mail server is OK with the situation when the client submits return-path different from username which was used for authenticating this SMTP session. Some servers are OK with it, some servers are not. So we had to revert to the current behavior - it has its drawbacks but it's more consistent across multiple mail server configurations.
If you need to make sure Aurora uses some specific return-path, you can add a new account rather than an identity. This will in fact be the same account but with its own set of creds.
Regards,
Alex
|
| Back to Top |
|
| |
solkmaaker
Senior Member
Joined: 28 June 2020
Online Status: Offline
Posts: 154
|
| Posted: 08 March 2021 at 2:04am | IP Logged
|
|
|
Hi Alex
This is now going to more or less philosophical discussion.
Anyway, i see why you did what you did, to get more compatibility with different (misconfigured) mail servers.
Correct way to configure mail server for alias use is to make reverse lookup on MTA side if logged in user has right to send mail as alias address.
And this is a MUST anyway, because if you do not do that, it would mean that any of your users are able to send mail with any From header out of your mail system.
In postfix this is not difficult to do, due to lack of experience i have no idea how difficult it is to implement this on other MTA's.
I understand that no software is perfect, and no admin is perfect, but...
SW development seems to move towards "child care", by that i mean protecting less experienced users/admins. I'm not talking this case specifically, but overall direction of developments.
For example, postfix refuses to make raw TCP lookup to any other server than 127.0.0.1. According to Wietse Venema it is to "protect", because in postfix side there is no way to implement any protocol security for raw TCP lookups and therefore it is hard coded to not to allow any other connection than 127.0.0.1
Now, in that case, IMHO is admins job to set up security mechanism for this connection (VPN for example) if he wishes to use raw TCP lookups to any other address, but Wietse Venema (author of postfix) denied to make changes to code to allow that.
This is what i call "child care", because IMHO developer should provide functionality, rather than to become nanny for inexperienced users/admins. In that raw TCP lookup case, IMHO, if you are dumb admin, and do not set up secure channel for your raw TCP lookup, then it is your fault and you must suffer. Besides, learning from mistakes is what creates more experienced people, that is why it is wrong to deny people to make mistakes.
Once more about postfix raw TCP lookup: i have seen case where admin created inetd wrapper, so postfix was doing raw TCP lookup indeed to 127.0.0.1 and inetd wrapper (proxy) did lookup to public IP address, and this lookup was not over encrypted channel. So result for this "child care" situation was that "child" was not "protected" and "protection" attempt failed anyway.
Back to aurora case:
Do you think it is possible to make this as configurable option?
I mean, those who have desire to privacy and therefore have configured their MTA's to achieve that may wish to do so.
|
| Back to Top |
|
| |
Igor
AfterLogic Support
Joined: 24 June 2008
Location: United States
Online Status: Offline
Posts: 6038
|
| Posted: 09 March 2021 at 11:58pm | IP Logged
|
|
|
We've discussed this with the developes, it's fairly easy to implement this behavior and add a setting, let's say, UseIdentityEmailAsSmtpMailFrom. We'll have it enabled by default, and administrator of the installation can always turn it off if mailserver they use has a problem with this approach.
Most likely, the feature will be added in the next release.
--
Regards,
Igor, Afterlogic Support
|
| Back to Top |
|
| |
solkmaaker
Senior Member
Joined: 28 June 2020
Online Status: Offline
Posts: 154
|
| Posted: 10 March 2021 at 1:20am | IP Logged
|
|
|
Hi Igor
Thank you, looking forward to next version.
|
| Back to Top |
|
| |
MailBee.NET Objects 
MailBee.NET Queue 
MailBee Objects 
WebMail Pro PHP 
AfterLogic Aurora 
MailSuite Pro for Linux 
Unified Messaging Solution 
Search
Register
Login
Topic: information disclosure (sort of)
Privacy policy |
Refund policy