Limitierung der Anzahl zu konvertierender Notes-Elemente in Header

    Hallo,

    hier mal eine etwas spezielle Frage: gibt es einen notes.ini Eintrag, mit dem man die Limitierung der Anzahl umzuwandelnder Header heraufsetzen kann?
    Meine Erfahrung sagt, daß hier sinngemäß so etwas zur Anwendung kommt (mal in Formelsprache Notation :-))
    @subset(@sort(headerliste);60)

    Sprich, die Namen in der Liste werden alphabetisch sortiert und aus dieser Liste werden die ersten 60 Einträge auf vorbeikommende Mails angewendet.
    Die Einträge für mein aktuelles Projekt fallen dadurch teilweise aus dem Raster. Ich könnte meine Header zwar umbenennen und mich vordrängeln :-), das ist aber nicht zielführend ...


    Bin für jeden Tip dankbar.

    Meine Links zu den notes.ini Referenzen sind leider alle "tot".


    Versuche mit Wildcard-Headern (feld-name-*) haben auch nicht funktioniert. Kennt da von Euch jemand zufällig einen Trick?


    MfG lodsnods

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

    Moin,


    mir erschließt sich (spontan) kein praktischer Nutzen aus einer solchen Limitierung.


    Technisch macht das auch wenig Sinn, da die Konvertierung im Normalfall vom im Client integrierten Mail Agent vorgenommen wird auf den obige Einstellungen keine Auswirkung haben. Der Server kann zwar bei der Übertragung (anschließend!) gezielt noch weitere Header hinzufügen oder löschen aber die Konvertierung an sich ist da schon gelaufen. Ausnahmen gibt es natürlich wenn man Mails gezielt nicht im MIME Format versendet - aber wer macht das schon?


    Außerdem könnten dadurch, gerade bei alphabetischer Sortierung, sinnvolle oder sogar notwendige Header wie 'principal', 'subject' oder gar 'recipients' unter den Tisch fallen, da diese im Alphabet weiter hinten stehen und z.B. schon eine simple Mail mit ca. 25 kleinen Anhängen plötzlich unroutbar werden würde.


    Daher: mehr Input - mehr Output


    Carsten

    Hallo Carsten,


    die "nativen" Mailheader wie from, to und subject sind davon ja auch nicht betroffen - es geht hier nur um die zusätzlichen Notesfelder, die in X-Header konvertiert werden sollen. Zumal die von Dir angesprochenen Header ja auch klassische Header (also ohne X-...) bleiben.


    Ggf. könnten Deine Befürchtungen aber dennoch wahr werden, wenn sich die RFC 6648 Deprecating "X-" einmal durchsetzen sollte - aber das ist schon wieder eine andere Geschichte =O. Keine Ahnung, ob HCL da mal in einer aktuellen/neuen Domino-Version Rücksicht nimmt.


    Hintergrund meiner Anfrage ist, daß ein externes Fachverfahren Mails entgegennimmt, die - neben ein paar Stammdaten - zu jedem Anhang einen Header mit Metainformationen zu dem jeweiligen Anhang erwartet. Bedauerlicherweise ist die maximale Anzahl erlaubter Anhänge in dem Verfahren auf 200 reglementiert <X. Ob und wie häufig das praktisch relevant ist, steht auf einem anderen Blatt - und ob der Nutzer in so einem Fall ggf. einach mehrere Mails senden kann/will/darf ...


    LG

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

    Zitat von lodsnods

    ...ein externes Fachverfahren Mails entgegennimmt, die - neben ein paar Stammdaten - zu jedem Anhang einen Header mit Metainformationen zu dem jeweiligen Anhang erwartet.

    Moin,


    ich halte den gedanklichen Ansatz einer nachträglichen Limitierung an dieser Stelle für ungünstig, in der Mailmaske hat man vor dem Versand noch am ehesten Möglichkeiten einzugreifen. Wenn es dann um die Anzahl der Anhänge geht und die Mails ganz normal mit Clients versendet werden kann man das z.B. mit einer Policy machen: https://help.hcltechsw.com/dom…its_for_sending_mail.html


    Anderenfalls müsste man ja die Mail später am Server wieder auseinandernehmen und neu zusammensetzen da die Anhänge ja in den MIME-Parts stecken und wenn zu jedem Anhang tatsächlich ein X-Metainfo-Feld existiert muss man die richtigen Felder und die dazu passenden Anhänge rausnehmen und was mit den "überzähligen" Headern und Anhängen machen...? Verwerfen und die Mail mit weniger Daten weiter laufen lassen? Das klingt nicht nach einem gewollten Fachverfahren ;) Gibt es dazu ein öffentliches "Papier", das man mal lesen kann um die Absicht dahinter zu verstehen? Insbesondere wie der Zusammenhang zwischen bis zu 200 Anhängen und einer (beispielhaften?) Limitierung auf 60 Header zustande kommt.


    HTH

    Carsten