Größenbeschränkung E-Mail nach Usern/Gruppen

[savage]

Aktuell kann man bei Notes die Größe von E-Mail (outgoing) nur für all User einheitlich festlegen. Wir suchen eine Möglichkeit, die Maximale E-Mailgröße für User und Gruppen festlegen zu können.

z.B. Gruppe A: 5 MB outgoing und Gruppe B: 1 MB outgoing

Das ganze sollte, wenn möglich, realtime laufen. Also der User kann erst gar keine so großen Mail verschicken. Dafür ist sicherlich eine Templateänderung notwendig. Toll wäre auch ein rein serverseitiges System. Und am besten für outgoing und incomming mails. :-)

Hat jemand eine Idee oder kennt ein fertige Tool?

[Wolfgang]

Hallo,
ich meine, von Group gibts da was ...
Schau mal auf http://www.group-technologies.com/

Gruß
Wolfgang

[savage]

Hi,
hm, die Tools kenne ich. Da gibt es zwar was für incomming traffic, aber ich habe noch nichts für den outgoing gefunden. Ich werde es aber nochmals durchschauen.

Danke.

[sotonic]

ND.Cerberus von inform/notesdev kann das (ist aber kostenpflichtig).
Allerdings kann der User erst verschicken & bekommt dann einen Zustellfehler.

sotonic

[savage]

@ sotonic
Werde ich mir mal anschauen. Im web steht von denen nicht viel. Scheint Scherpunkt auf Virenschutz zu sein. Vielleicht zu überdimensioniert. Ich suche eigentlich nur eine Lösung für das o.g. Problem. Ohne weiteren Schnickschnack, wenn möglich.

[hallo.dirk]

Klar kann der Watchdog (Group) das auch !

Aber billig oder umsonnst ist der auch nicht......


Ich kenne keine möglichkeit die Kostenlos zu haben ist........


Gruss

Dirk

[Hardy]

Hi,

Ich habe in die Mail-Schablone ein Feld eingebaut, das die Größe
der zu sendenden Mail prüft und je nach Bedarf eine Info-Box aufmacht.

Die habe ich dann mit den Gruppen aus dem NAB gekoppelt.

Klappt ganz gut und die übergrossen Mails gehen garnicht erst auf den Server.

Der Code muß auch irgendwo im Forum zu finden sein.
Da meine Datenbank in der Firma ist kann ich den Code erst am Montag posten.

Gruß
Hardy

[savage]

Hi Hardy,

kannst Du mir den Code verraten? Wäre supi. Hört sich an, als wenn es genau das ist, was ich suche. *freu*

Hab den Code leider hier nicht finden können. Als in Deinen Postings ist er nicht und unter verschiedenen Stichworten war ich auch erfolglos.  

[Hardy]

Hier nun der Code:

MailCheckSize
In der Memo Maske ein Feld erstellen und in der Eingabevalidierung den Code reinkopieren

REM "========================================" ;
REM "Fehlermeldung anzeigen, wenn Dokument grösser als die erlaubten KB sind" ;
REM "========================================" ;

lz := @NewLine + @NewLine ;
nz := @NewLine ;

REM die Gruppe die trotzdem Zugriff hat;
GruppenName:="Mail-UNL";

REM hier steht die max Grösse der Mail;
MaxKB := 10000 ;
UserCN := @Name([CN] ; @UserName) ;
UserAB := @UserName ;
WerDarf := @DbLookup("Notes" : "NoCache"; "Dein LN-Server" : "NAMES"; "Groups"; GruppenName; "Members");

DocSize := @Sum( @If ( @Attachments > 0 ; @DocLength / 1024 ; 0)) ;
Text := "Das Memo kann nicht versendet werden, da es grösser als " + @Text(MaxKB;"F,0") + " KB ist. Aktuelle Memogrösse: " +      @Text(DocSize;"F,0") + " KB." ;

@If ( DocSize > MaxKB & @IsDocBeingMailed & @IsNotMember(UserAB;WerDarf) ;
      @Failure(Text) ;
      @Success )

[savage]

Herzlichen Dank.
Werde ich mir mal genauer ansehen und versuchen das dynamisch zu machen. Also ne zentrale DB die die Größenbeschränkungen verwaltet und mit dem NAB abgleicht. :-)

[Rob Green]

@savage, das ist keine zentrale Lösung, die den Mailverkehr überwacht und dabei die Mailschablone unangetastet läßt.
Das ist genau das Umgekehrte: es ist eine dezentrle Lösung über eine Anpassung des Postkorbs. Warum sagste nicht einfach Deinem Kunden, daß es momentan nix Zentrales gibt und nur eine kleine Mailschablonenänderung vorzunehmen ist? Wenn er sich dann immer noch jungfräulich anstellt, ist ihm die Lösung auch nicht so wichtig.

[savage]

@Robert
Hm, ich weiss das die keine zentrale Lösung ist. Aber ne statische Größenbeschränkung hilft auch nicht viel. Da muss ich ja jedesmal wieder die Schablone ändern, wenn sich der Wert für einen User/Gruppe ändert. Dat hilft mir nicht weiter bei 5.000 Usern. Besser wäre es doch, wenn man einen dynamischen Wert hätte, der von der Schablone zentrals ausgelesen wird. Dann kann ich zentral den Wert ändern und der Client holt sich die neuen Werte von Zeit zu Zeit oder bei der Anmeldung etc.

[Hardy]

Hi,

Wenn man verhindern möchte, dass die grossen Mails erst über den Server laufen, wär das doch die einzige Lösung.

Warum muß der Wert denn ständig geändert werden ?

Einige dürfen Mails nur bis zur einer bestimmten Grösse senden und die anderen eben alles.

Man könnte ja die Beschränkung über die Gruppen definieren. Ist der User in einer bestimmten Gruppe, kann er eine bestimmte Mailgrösse versenden.

Man sollte beachten, das das auch für Notebooks passen sollte, die auch mal von lokal arbeiten und dann eben kein Zugriff auf das Server NAB haben. Hier wäre dann der Verzeichniskatalog angebracht. Weiß jetzt garnicht , ob der auch Gruppen auflöst.

So Long

Hardy

[Rob Green]

@savage, aber das ist doch genau so wie ich Dir damals zugemailed habe   *Donk* á la Änderung der Mailschablone, ein kleines Script, das Größenangaben aus den Gruppendocs des NAB ausliest, wenn der Absender zu einer Gruppe gehört. Dazu ist natürlich auch ein Feld incl. Wert im NAB einzutragen, was auch zur Änderung der NAB Schablone führt (wenn man es im NAB haben will, was aber net unbedingt sein muß, denn es geht auch über eine Non-NAB Db über eine eingehende Replizierung von Gruppen/Personendocs aus dem NAB in die Non-NAB-DB). Und das kann man dann zentral administrieren. Da haste mir gesagt, geht net, weil no Änderungen sein dürfen.   *weißt Du was Du willst, Du Weib?

[Meff]

Zu dem Thema Geld ausgeben :

Ist euch eigentlich klar, dass das Entwickeln, ausrollen und Administrieren (incl. Usersupport etc.) auch Geld kostet. Rechnet euch das mal aus und stellt dann den EK mit allen Kosten dagegen, welches ein fertiges Tool incl. Support sind.

Meff

[MOD]

@ Meff

Grundsätzlich gebe ich Dir Recht.
Die Preispolitik von Group Technologies kann ich jedoch nicht nachvollziehen.

  MOD

[Meff]

Hi MOD,

warum ? Seit diesem Jahr wird das ganze nach Anwendern berechnet. Für Umgebungen mit vielen Servern ist das durchaus von Vorteil, da Du ab jetzt die gekauften Tools auf allen Servern einsetzten kannst.

Meff

[MOD]

@ Meff
jetzt:
sequriQ.watchdog 4.364,00 €
sequriQ.wall          2.456,00 €
Vorjahr:
sequriQ.watchdog    771,03 €
sequriQ.wall             400,34 €

Müsste als Begründung reichen.
Auch wenn ich es auf jeden Server einsetzen kann, habe ich dadurch trotzdem nur zwei Kommunikationsserver.

  MOD

[savage]

@Meff.
Also ich finde die Preise von Group auch etwas happig. Und das habe ich von eigentlich allen Kunden gehört, dass sie nicht gerade amused sind über die Umstellung. Auch wenn Group die Kohle in der aktuellen wirtschaftlichen Lage sicherlich gebrauchen kann.  

@MOD
Genaus ist die Preisentwicklung dort. Leute kauft die Aktien, wenn die das System flächendeckend umgesetzt bekommen.  

@All
Zurück zum Thema. Ich brauch nur ein winizges Tool und nicht eine ganze Sammlung von 1.000 Funktionen von denen ich nur 1 verwenden will. Notfalls bauen wir die selber. Die Systeme die ich mir angeschaut habe, sind einfach zu umfangreich. Es muss doch ein System nur mit dieser odern ein paar mehr Funktionen geben. Kann doch nicht sein, dass wenn ich eine Dose Ravioli haben will, ich gleich den ganzen Supermarkt kaufen muss.