[Koha] Australian Koha User group - Melbourne/Online
Hello and Happy Friday, or almost Friday, wherever you may be. The Melbourne Athenaeum library have kindly offered to host a Koha user group, starting on the 29th of March, 6.00 - 7.30pm, in their beautiful Collins St building. The library will host and Catalyst will (remotely!) arrange the agenda. If you would like to attend, please let me know by email reply and delete the bits below that do not apply to you: *** YES I would like to come to the user group on 29 March at 6pm, hosted by the Melbourne Athenaeum library. I will join the meeting IN PERSON/ONLINE. Please keep me informed about future events. My accessibility requirements are... I would like it if the agenda included... I would like to present at a future meeting about... *** We will send further details to everyone who RSVPs. Best wishes for a lovely weekend ahead, Kathryn -- Kathryn Tyree Koha Services Manager Catalyst.Net Limited DDI: +64 4 803 2414 Tel: +64 4 499 2267 www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
On Mon, Feb 27, 2023 at 8:01 AM David Liddle wrote: > > Greetings, all! > > At the encouragement of one of the mailing list administrators, I > would like to present a situation and a proposal to you all. > > Normally, I would write from my work account, david.lid...@wycliff.de, > since one of the hats I wear is that of a Koha system administrator. > One of my other hats, however, is that of the email administrator for > our corporate domains. And the latter hat has precedence over the > former. > > To help protect our email domains from being used fraudulently, I have > implemented DMARC policies according to current recommendations. You > can read more about the Domain-based Message Authentication, Reporting > & Conformance protocol at https://dmarc.org/. The policies direct that > only messages from authorized sources should be allowed to send mail > from wycliff.de and our other domains; messages from all unauthorized > sources should be quarantined. > > With DMARC policies in place, messages that I send from my work > account to the Koha mailing list get quarantined by email providers > that comply with the policies' directives. Why? It happens because the > Koha mailing list spoofs the email address of the original sender. As > a result, there is a significant number of subscribers who did not > receive the messages at all or had to fetch them from quarantine. Some > unknown number will have been marked as spam. > > There are well-meaning reasons for this behavior within an honest, > friendly community such as the Koha mailing list. However, email > spoofing is one of the chief means by which fraudsters engage in > phishing, data exfiltration, and ransomware attacks. In my opinion, > the Koha community ought to avoid the practice of email spoofing. > Therefore, I have a proposal to make: > > -- The Koha Mailing List is based on the Mailman list system. > According to its release notes, Mailman 2.1 supports what the > developers call "DMARC mitigations". > -- Mailman DMARC Mitigations are described here: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html > ++ I PROPOSE that the mailing list subscribers support the > implementation of DMARC mitigations to the Koha mailing list. > -- The result of the implementation would be that messages submitted > to the list would no longer spoof the sender's address, but rather be > altered so that the messages come from the list's own address, > koha@lists.katipo.co.nz. They *should* be delivered successfully to > all recipients. A reply to the message would return to the list, and a > reply to all could include the original sender's address explicitly. > -- If you agree (or disagree) with this proposal, you'll need to > indicate that in your own clever way, because there's no voting > mechanism in a mailing list. > > Thank you for being so kind and forbearing as to read this far! I hope > that you'll give my proposal your earnest consideration. > > Greetings Most would consider your proposal as timely or 'contemporary'. A somewhat easy fix - - - good on you. Your suggestion to move to another system for connection - - - absolutely NOT interested. It would mean logging into one more location and using one more system to read emails. I would likely unsubscribe at that point. Keeping up with the very large number of listes that I'm already on takes far too much of my day and anything that adds to the time necessary - - - well - - - that function gets lopped off. If I were only following a few lists - - - not such an issue - - - - I have a LOT more than that. (Some are already on discourse - - - - its not at all equivalent in my opinion and is much more difficult to follow a large number of threads than a simple email list.) Regards ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
[Resending to correct accidental paste in my message but adding consideration of use of Discourse as a partial workaround.] I added to the meeting agenda some brief consideration of implementation if we adopt DMARC for the Koha mailing list. These issues have had some discussion on the Koha mailing list. There is no problem free way to implement DMARC for mailing lists in part because email and mailing lists were designed before authentication of senders was considered a sufficiently concerning problem. 1. Mailman. Two implementation approaches to consider are the following. Quotations below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC but there are matching parts in the Mailman 2 section. One option: "Munge the From: header - The obvious way to avoid a DMARC rejection [...]" Alternative option: "Wrap the message - This involves MIME wrapping the original message [...] Users of MUAs that can't unwrap this MIME decoration would suffer." The suffering would be some users of the very wide variety of email clients people use from console, to desktop, to some old mobile device may not see any body message and merely have an attachment requiring extra processing outside of the user's email program. See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner - https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on the complexities of mime use in messages and how every email client has an individual implementation to cope. Limiting scope to affected users. It is reportedly possible to configure Mailman to limit the scope of DMARC mitigations to affected users such that the mailing list messages are unaltered for others, "Enable dmarc mitigations" - https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/6MOITVJK4WFXALD6NKR6SJTEN7RMLZLK/ . My current understanding leads me to prefer "munging the from header" as an implementation despite some RFC non-compliance. As stated above; email, mailing lists, and their associated RFCs long preceded considerations of authentication. Having problematic email clients for "MIME wrapping" in the wild seems to me to be a worse problem than some otherwise unavoidable RFC non-compliance with the very diverse subscriber base for the mailing list. Diverse subscribers have diverse computer systems and frequently restrictions on changing them where they actually read and reply to email on work systems and other systems as opposed to some major proprietary webmail intermediaries through which email may pass for many people. 2. Discourse. Does Discourse mailing list mode avoid problems with DMARC in a manner that is still sensible for offline use? Mailing lists are good for offline use. Does discourse provide something similar to Mailman "munging the from header" so that the message poster is identified in the email from header originating from the Discourse server allowing email clients to display lists of messages helpfully including by message poster in addition to subject and time? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, March 3, 2023 17:43, David Liddle wrote: > Thank you for adding it to the discussion points! > > > On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer > wrote: > >> I have added the DMARC issue to the agenda for the next developer IRC >> meeting, but we might need the people running our mailservers to weigh >> in: >> >> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023 >> >> Hope this helps, >> >> Katrin >> >> On 27.02.23 15:49, Coehoorn, Joel wrote: >> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only >> for >> the >> > last couple of months. The list used to handle this correctly. >> > >> > *Joel Coehoorn* >> > Director of Information Technology >> > *York University* >> > Office: 402-363-5603 | jcoeho...@york.edu | york.edu >> > >> > >> > >> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle >> wrote: >> > >> >> Greetings, all! >> >> >> >> At the encouragement of one of the mailing list administrators, I >> >> would like to present a situation and a proposal to you all. >> >> >> >> Normally, I would write from my work account, >> david.lid...@wycliff.de, >> >> since one of the hats I wear is that of a Koha system administrator. >> >> One of my other hats, however, is that of the email administrator for >> >> our corporate domains. And the latter hat has precedence over the >> >> former. >> >> >> >> To help protect our email domains from being used fraudulently, I >> have >> >> implemented DMARC policies according to current recommendations. You >> >> can read more about the Domain-based Message Authentication, >> Reporting >> >> & Conformance protocol at https://dmarc.org/. The policies direct >> that >> >> only messages from authorized sources should be allowed to send mail >> >> from wycliff.de and our other domains; messages from all unauthorized >> >> sourc
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
I added to the meeting agenda some brief consideration of implementation if we adopt DMARC for the Koha mailing list. These issues have had some discussion on the Koha mailing list. There is no problem free way to implement DMARC for mailing lists in part because email and mailing lists were designed before authentication of senders was considered a sufficiently concerning problem. Two implementation approaches to consider are the following. Quotations below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC but there are matching parts in the Mailman 2 section. One option: "Munge the From: header - The obvious way to avoid a DMARC rejection [...]" Alternative option: "Wrap the message - This involves MIME wrapping the original message [...] Users of MUAs that can't unwrap this MIME decoration would suffer." The suffering would be some users of the very wide variety of email clients people use from console, to desktop, to some old mobile device may not see any body message and merely have an attachment requiring extra processing outside of the user's email program. See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner - https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on the complexities of mime use in messages and how every email client has an individual implementation to cope. My current understanding leads me to prefer "munging the from header" as an implementation despite some RFC non-compliance. As stated above; email, mailing lists, and their associated RFCs long preceded considerations of authentication. Having problematic email clients for "https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023MIME wrapping" in the wild seems to me to be a worse problem than some otherwise unavoidable RFC non-compliance with the very diverse subscriber base for the mailing list. Diverse subscribers have diverse computer systems and frequently restrictions on changing them where they actually read and reply to email on work systems and other systems as opposed to some major proprietary webmail intermediaries through which email may pass for many people. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, March 3, 2023 17:43, David Liddle wrote: > Thank you for adding it to the discussion points! > > > On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer > wrote: > >> I have added the DMARC issue to the agenda for the next developer IRC >> meeting, but we might need the people running our mailservers to weigh >> in: >> >> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023 >> >> Hope this helps, >> >> Katrin >> >> On 27.02.23 15:49, Coehoorn, Joel wrote: >> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only >> for >> the >> > last couple of months. The list used to handle this correctly. >> > >> > *Joel Coehoorn* >> > Director of Information Technology >> > *York University* >> > Office: 402-363-5603 | jcoeho...@york.edu | york.edu >> > >> > >> > >> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle >> wrote: >> > >> >> Greetings, all! >> >> >> >> At the encouragement of one of the mailing list administrators, I >> >> would like to present a situation and a proposal to you all. >> >> >> >> Normally, I would write from my work account, >> david.lid...@wycliff.de, >> >> since one of the hats I wear is that of a Koha system administrator. >> >> One of my other hats, however, is that of the email administrator for >> >> our corporate domains. And the latter hat has precedence over the >> >> former. >> >> >> >> To help protect our email domains from being used fraudulently, I >> have >> >> implemented DMARC policies according to current recommendations. You >> >> can read more about the Domain-based Message Authentication, >> Reporting >> >> & Conformance protocol at https://dmarc.org/. The policies direct >> that >> >> only messages from authorized sources should be allowed to send mail >> >> from wycliff.de and our other domains; messages from all unauthorized >> >> sources should be quarantined. >> >> >> >> With DMARC policies in place, messages that I send from my work >> >> account to the Koha mailing list get quarantined by email providers >> >> that comply with the policies' directives. Why? It happens because >> the >> >> Koha mailing list spoofs the email address of the original sender. As >> >> a result, there is a significant number of subscribers who did not >> >> receive the messages at all or had to fetch them from quarantine. >> Some >> >> unknown number will have been marked as spam. >> >> >> >> There are well-meaning reasons for this behavior within an honest, >> >> friendly community such as the Koha mailing list. However, email >> >> spoofing is one of the chief means by which fraudsters engage in >> >> phishing, data exfiltration, and ransomware attacks. In my opinion, >> >> the Koha community ought to avoid the practice of e
Re: [Koha] koha on virtualbox
Sounds like you need to check some VirtualBox forums as you question pertains to virtualbox and not Koha! I would recommend https://forums.virtualbox.org/ Kyle --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Mar 9, 2023 at 1:16 AM Tom Obrien wrote: > Hi all, > I have installed koha on ubuntu 22. I have used oracle virtualbox hosted on > windows 10 platform.There are other services running on the windows, how > can i make ubuntu server and virtualbox start automatically whenever > windows is restarted? > Kindly assist and thanks in advance. > ___ > > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] "[Suspected Spam]" Re: Modify Patron Transaction Invoices and Fee Receipts
You can get the dates for *current* checkouts, but not any that have been returned, at this time. [% credit.item.checkout.date_due | html %] should work for example. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Wed, Mar 8, 2023 at 11:48 PM Ms. Naveen Ali wrote: > Dear all. Good day to you! > > This is indeed a great forum and I would like to thank you all for the > great and prompt responses, > > A few more things: > > I am sharing the code of default payment slip (Code=ACCOUNT_CREDIT, > Library=All Libraries, Koha Module=Circulation)which I am trying to modify > > > [% USE Price %] > [% PROCESS 'accounts.inc' %] > > [% IF ( LibraryName ) %] > > > [% LibraryName | html %] > > > [% END %] > > > Fee receipt > > > > > [% Branches.GetName( credit.patron.branchcode ) | html %] > > > > > Received with thanks from [% credit.patron.firstname | html %] [% > credit.patron.surname | html %] > Card number: [% credit.patron.cardnumber | html %] > > > > Created > Updated > Description of charges > Note > Amount > > > > [% credit.date | $KohaDates %] > [% credit.timestamp | $KohaDates with_hours = 1 %] > > [% PROCESS account_type_description account=credit %] > [%- IF credit.description %], [% credit.description | html %][% END > %] > > [% credit.note | html %] > [% credit.amount | $Price %] > > > [% IF ( tendered ) %] > > Amount tendered: > [% tendered | $Price %] > > > Change given: > [% change | $Price %] > > [% END %] > > > > Total outstanding dues as on date: > [% IF ( credit.patron.account.balance >= 0 ) %][% > ELSE %][% END %][% credit.patron.account.balance | $Price > %] > > > > === > > [% LibraryName | html %] > [% Branches.GetName( credit.patron.branchcode ) | html %] > > Firstly, The above two lines of code do not generate any result, while the > rest of the code works fine. > > Secondly, the documentation says the substitution and template toolkit can > be used together. But when I tried using substitution <<>>, for library > branch name, that too did not not work > > Thirdly, I have made copies of the slip for two different libraries, on > the understanding that the library is where the transaction is being done > as shown in Accounting Tab of patrons, under Home Library. However I find > that only one of the modified slips is being used in both the libraries. > > Help will be most appreciated. > > With best regards, > > Naveen Ali > > ITM-JE (EAKL) > Inst Representative for > HEC Digital Library Resources. > NEDUET, Karachi. > > > - Original Message - > From: "Katrin Fischer" > To: koha@lists.katipo.co.nz > Sent: Friday, 3 March, 2023 8:05:18 PM > Subject: "[Suspected Spam]" Re: [Koha] Modify Patron Transaction Invoices > and Fee Receipts > > Hi, > > you might also want to have a look at these page in the wiki: > > https://wiki.koha-community.org/wiki/Notices_with_Template_Toolkit > > > https://wiki.koha-community.org/wiki/Notices_and_Slips_Library#Notices_and_slips_using_template_toolkit > > Hope this helps, > > Katrin > > > On 03.03.23 06:47, Ms. Naveen Ali wrote: > > Dear all, > > > > I am using Koha 22.05 and trying to modify the ACCOUNT_CREDIT pint slip. > > > > I would like to add the book information (biblio and lending such as due > date and return date ) of items included in the receipt. > > I am learning about the Template Toolkit used and have found the > following documentation > > https://wiki.koha-community.org/wiki/Template_Toolkit_Plugins > > but it is not complete. > > > > Is the documentation available and accessible? > > > > Could someone point me in the correct direction please. > > > > > > With best regards, > > > > Naveen Ali > > > > ITM-JE (EAKL) > > Inst Representative for > > HEC Digital Library Resources. > > NEDUET, Karachi. > > > > > > - Original Message - > > > > From: "MASTeR Library" > > To: "Ms. Naveen Ali" > > Cc: "Caroline Cyr La Rose" , "koha" < > koha@lists.katipo.co.nz> > > Sent: Wednesday, 1 March, 2023 12:52:57 PM > > Subject: Re: [Koha] Modify Patron Transaction Invoices and Fee Receipts > > > > Account payment invoice > > > https://libpowertech.blogspot.com/2022/03/how-to-create-email-receipt-template.html?m=1 > > > > On Wed, 1 Mar 2023, 11:26 am Ms. Naveen Ali, < nav...@neduet.edu.pk > > wrote: > > > > > > Hi Caroline, > > > > Thanks a lot for the information. > > > > I was looking for them in Tools->Notices and slips but was not able to > map the receipts and invoices. > > > > The link you mentioned is great. > > > > I tried using Help on the Koha interface. It took me t
