in that case why should the empty file check, right from the
beginning, cause any problem? You just add an extra verification in
your existing tasks. If the file is empty do nothing and if the file
isn't empty continue with your regular checking!
On Thu, Jul 5, 2018 at 2:01 PM, Gilles Chehade <gil...@poolp.org> wrote:
> On Thu, Jul 05, 2018 at 01:22:50PM +0200, Teno Deuter wrote:
>> how does it work right now if I update the files at runtime and I make
>> a syntax error? How will I take notice of this error?
>>
>
> it depends what kind of error.
>
> files are not reloaded by smtpd when you edit them, they are loaded at
> startup and they are reloaded throught 'smtpctl update table <foo>' so
> if you don't reload it will error the next time you restart smtpd, and
> if you reload... it depends on what you put in the file:
>
> a- if it is completely broken, smtpctl will refuse to update memory so
> you will still have your previous table used until you fix
>
> b- if it is valid but not what smtpd expects at runtime it will just
> fail lookups.
>
>
>
>> On Thu, Jul 5, 2018 at 10:51 AM, Gilles Chehade <gil...@poolp.org> wrote:
>> > On Thu, Jul 05, 2018 at 10:07:32AM +0200, Teno Deuter wrote:
>> >> wouldn't be more reasonable to check if the file is of 0KB and just
>> >> skip the rest of the tests? The way you do it right now sounds quite
>> >> good to me. You just introduce the empty check before anything else.
>> >>
>> >> Thank you
>> >>
>> >
>> > im not sure the test is relevant since you can update files at runtime.
>> >
>> > maybe this check should only be done when a table is statically declared
>> > in smtpd.conf
>> >
>> >
>> >> On Thu, Jul 5, 2018 at 9:18 AM, Gilles Chehade <gil...@poolp.org> wrote:
>> >> > On Wed, Jul 04, 2018 at 07:43:59PM +0200, Teno Deuter wrote:
>> >> >> yep, that was the case! Actually the syntax was correct. From the
>> >> >> beginning. The problem was the empty blacklist file!
>> >> >>
>> >> >> Thank you for your help
>> >> >>
>> >> >
>> >> > The issue is that to determine if table blacklistRecipients is usable as
>> >> > a parameter to 'recipient' we need to check if it is a list or a mapping
>> >> > and we detect either one because of the first entry.
>> >> >
>> >> > Since you have an empty file, this check fails.
>> >> >
>> >> > Now, maybe we need to reassess if we still need to do that and if we can
>> >> > simply use whatever file was provided and fail at runtime.
>> >> >
>> >> > Initially we didn't want to do that because with the old syntax the name
>> >> > of the table was written in the envelope and if you got things wrong, it
>> >> > would not be fixable for all accepted envelopes.
>> >> >
>> >> > This is no longer true, I'll talk with eric@ and see what he thinks
>> >> >
>> >> >
>> >> >> On Wed, Jul 4, 2018 at 3:36 PM, Reio Remma <r...@mrstuudio.ee> wrote:
>> >> >> > It seems empty equals broken. You need actual content in the file.
>> >> >> >
>> >> >> > Reio
>> >> >> >
>> >> >> >
>> >> >> > On 04.07.2018 12:25, Teno Deuter wrote:
>> >> >> >>
>> >> >> >> unfortunately, in my case, the blacklist file is empty! :(
>> >> >> >>
>> >> >> >> could have something to do with the permissions? Here is my current
>> >> >> >> status:
>> >> >> >>
>> >> >> >> -rw-r--r-- 1 root wheel
>> >> >> >>
>> >> >> >> On Wed, Jul 4, 2018 at 11:00 AM, Reio Remma <r...@mrstuudio.ee>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> On 04.07.2018 11:35, Teno Deuter wrote:
>> >> >> >>>>
>> >> >> >>>> here is what I have changed:
>> >> >> >>>>
>> >> >> >>>> accept from any \
>> >> >> >>>> for domain <domains> recipient !<blacklistRecipients> \
>> >> >> >>>> virtual <users> \
>> >> >> >>>> deliver to maildir "/var/mail/%{user.username}/Inbox"
>> >> >> >>>>
>> >> >> >>>> and I still get the error:
>> >> >> >>>>
>> >> >> >>>> invalid use of table "blacklistRecipients" as RECIPIENT parameter
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> The only way I can duplicate that error is by intentionally
>> >> >> >>> breaking the
>> >> >> >>> blacklist file.
>> >> >> >>>
>> >> >> >>> Recipients file/table should have one e-mail address per line I
>> >> >> >>> suspect.
>> >> >> >>>
>> >> >> >>> Good luck!
>> >> >> >>> Reio
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> You received this mail because you are subscribed to
>> >> >> >>> misc@opensmtpd.org
>> >> >> >>> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
>> >> >> >>>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > You received this mail because you are subscribed to
>> >> >> > misc@opensmtpd.org
>> >> >> > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> You received this mail because you are subscribed to misc@opensmtpd.org
>> >> >> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
>> >> >>
>> >> >
>> >> > --
>> >> > Gilles Chehade
>> >> >
>> >> > https://www.poolp.org @poolpOrg
>> >>
>> >> --
>> >> You received this mail because you are subscribed to misc@opensmtpd.org
>> >> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
>> >>
>> >
>> > --
>> > Gilles Chehade
>> >
>> > https://www.poolp.org @poolpOrg
>
> --
> Gilles Chehade
>
> https://www.poolp.org @poolpOrg
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
