All,
Thanks for the input, highly appreciated!
The solution of adding aliases to other domains than example.com and delivering
locally still would force me to have an alias for each and every actually used
target in the @example.com domain (and hence in real world cases it’s a
maintenance nightmare if this has to be pushed out to every firewall, webserver
etc.)
-> not an option for me
table(5) man page is interesting (hadn’t read that one yet, found a missing
link -> thanks!)
(while it is listed in the see also section of smtpd.conf(5), I hadn’t realized
is was specific to opensmtpd - my mistake)
I think so far the conclusion is that within the (current) capabilities of
opensmtpd:
- I need to give up on having no local delivery in order to have aliases.
- If I have local delivery I need to give up on having mailname set to
example.com
and use a subdomain in example.com so I can avoid having to have a list of
all possible real mail targets in @example.com
with a subdomain per server/set of servers I can make sure that nothing
gets delivered locally as I can alias away all users
on the system to off server email addresses.
I’ll look further into this to see what works in the end:
- Either I live without aliases on the originating server
-> guess the worst is root’s crontabs that need a [email protected] alias to
function externally on the mailserver - one more spam target …
-> In my case real users already will have some sort of [email protected]
alias/email address already
Hmm… Seems like crontab allows MAILTO configuration … might be an option to
fix that part without using aliases…
[need to run a full inventory of all current aliases in use out there, to see
if I can get rid of every last one]
- Either I live with header From: addresses that cannot be replied to (or
setting up email services for those addresses) for mail originating locally
like from crontabs, the mailx commands etc.
-> if sendmail -f works as I expect it would, this might still be an option.
[I have not tested it yet - just being (overly) cautious]
(crontabs etc.: I probably can live with them not being suitable for
replying to)
Hmm … mailx and crontab allow setting the from (sure is a per user setting,
but probably something I can live with on these servers s there’s
no non-administrative interactive users anyway in my case)
Still as a suggestion for improvement:
- why not allow alias processing on relaying [from local] ?
(would IMHO solve a lot for e.g. webservers, file servers, firewall, …)
- maybe an example on how to setup the simplest of configuration of smtpd.conf
for e.g. a webserver or a firewall …
(might make adoption much easier for those of us “new” to opensmtpd)
[I fully understand the development focus on mailservers as it’s by far the
more complex situation]
[and I do appreciate the simplicity of the configuration - esp. when compared
to a “bat-book”]
Swa
> On 22 Jun 2016, at 17:16, Edgar Pettijohn <[email protected]> wrote:
>
>
>
> Sent from my iPhone
>
>> On Jun 22, 2016, at 2:51 AM, Robert Klein <[email protected]>
>> wrote:
>>
>> On Tue, 21 Jun 2016 19:00:54 -0500
>> Edgar Pettijohn <[email protected]> wrote:
>>
>>> On 16-06-21 18:53:26, Edgar Pettijohn wrote:
>>>
>>> Sorry forgot this requirement. Easiest solution would be to have the
>>> users in alias file like so:
>>>
>>> user1: [email protected]
>>> user2: [email protected]
>>> etc.
>>
>> After some testing: it seems when I send to a user of my own domain (as
>> specified in /etc/mail/mailname), the user has to exist locally. When
>> I sent to another domain it works.
>>
>> (e.g. domain in /etc/mail/mailname is "example.org" and you alias
>>
>
> Look at table(5) userinfo tables
>
>> root: [email protected]
>>
>> it works.)
>>
>> When you start smtpd manually (smtpd -dv -T all) and send a mail you get
>> a lot of information to dig through. In my test [email protected] didn't
>> expand, so it couldn't send a mail to "[email protected]" (as per error
>> message).
>>
>> Best regards
>> Robert
>>
>>
>> --
>> Robert Klein UNIX Operations
>> Max Planck-Institut für Polymerforschung
>> Anschrift: Ackermannweg 10, 55128 Mainz
>>
>> --
>> You received this mail because you are subscribed to [email protected]
>> To unsubscribe, send a mail to: [email protected]
>>
>
>
> --
> You received this mail because you are subscribed to [email protected]
> To unsubscribe, send a mail to: [email protected]
>
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
