-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement new DELIVERY config parameter. #125
base: master
Are you sure you want to change the base?
Conversation
This allows dma to support three modes of delivery: local-only, remote-only, and local + remote (the default). It supersedes the NULLCLIENT directive, which is equivalent to the remote-only mode. Fixes: corecode#121
I'm a bit puzzled by: remote address + |
Note that the Renaming it to |
I see. Still |
If we went with If you had We could fix the delivery code to allow Or instead of having a
This would also require some changes to the delivery code, however. |
Doesn't having a And I think it might make more sense to invert the logic on the other 2: This way "everything off" is still "normal" behavior and it doesn't break peoples configs on upgrade. Then:
|
@@ -255,8 +254,10 @@ add_recp(struct queue *queue, const char *str, int expand) | |||
endpwent(); | |||
} | |||
} | |||
} else { | |||
} else if (config.features & DELIVERY_REMOTE) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you made this check down in deliver()
where deliver_remote
is called you can use bounce
on the email which might be better behavior if local delivery is allowed. Of course if both local and remote delivery are disabled we probably want to catch that at configuration time.
Yes, I'm not keen on that semantic redundancy.
That seems like a reasonable approach. Between those two keywords and
I think that's everything... please comment if you see other examples. ( For brevity, I would suggest shortening the new keywords to
Note that @corecode, what are your thoughts on this? I think we're all in agreement on what we want to make possible in dma; it is just a matter of articulating the configuration for it in as clear a manner as possible. |
I keep getting confused, it's not obvious how things work. If I only set So Can we do something like:
Absolutely. What do you think about my suggestion? Seems like we had this before, but it also feels new? |
Not necessarily. There are [at least] two exception cases when
That wouldn't cover smarthost + local, or local + MX (both reasonable scenarios), and |
How do you send mail from a MUA? Usually delivery to a smarthost is configured in a way to accept all locally originating mails, and the smarthost does masquerading, etc.
No, that makes no sense. Smarthost is used when you never want to do direct MX delivery.
Maybe then we could also do |
Traditionally, MUAs would invoke
Typically, the first message would never leave the system. Why would it? You're already at the destination. That said, if you do want even local addresses to go to the smarthost, this can be specified with the
It's conceivable to have MX fallback as a resiliency measure (which can be opted out of with
|
Implementation of the feature discussed in #121.
Some remarks:
I shortened "DELIVERYMODE" to "DELIVERY" for brevity;
I fixed one unrelated bug along the way: specifying
FINGERPRINT
without an argument led to a segfault instead of an error;NULLCLIENT
remains recognized in the config file, but I removed mention of it from the documentation asDELIVERY REMOTEONLY
supersedes it.Between this new parameter, use/absence of a smarthost, and a local (
user
) vs. remote (user@host
) e-mail recipient address, there are a number of permutations of operation. The table below summarizes them, and the result:I used a script to test the various cases, which you might find useful for that purpose: dma-delivery-test.sh.txt