Resources consumed by filters generally depend on your hardware and = platform. Maybe such implementation should be made customizable, e.g. if the event = fires after each RCPT or enable/disable this or that event ...
I aim to be as flexible as possible. So if you have many hooks and you = can use them on demand, they don't eat more resources than fewer ones ... According to being hammered by huge traffic: With a clever coded filter, you can limit bandwith on SMTP protocol = level by forcing the sender to try again later or by pushing him into a delay. = This would also relieve long running filter.in.tab filters like e.g. AV or = SPAM filters. --Harald > -----Urspr=FCngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Rob Arends > Gesendet: Dienstag, 3. Februar 2004 23:59 > An: [EMAIL PROTECTED] > Betreff: [xmail] Re: AW: Re: AW: Re: AW: Re: SMTP Dialog Filter Hooks >=20 >=20 > Very good, > But wouldn't you have after_rcpt fire each time [crlf] is=20 > received (on a rcpt to line)? It may be more efficient to=20 > fire once, rather than each time, but you couldn't return=20 > custom error for each address. I think it would be better to=20 > process it one at a time. >=20 > Rob :-) >=20 > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Harald Schneider > > Sent: Wednesday, February 04, 2004 12:55 AM > > To: [EMAIL PROTECTED] > > Subject: [xmail] AW: Re: AW: Re: AW: Re: SMTP Dialog Filter Hooks > >=20 > > DATA terminates the envelope. > > AFTER_HEADER should be fired after the blank line, which > > terminates the > > header: > >=20 > > MAIL FROM: ... > > --> AFTER_MAIL_FROM > > RCPT TO: ... > > --> AFTER_RCPT_TO > > DATA > > From: ... > > To: ... > > Subject: ... > > --> AFTER_HEADER > > [blank line] > > Mail body > > .. [dot] > >=20 > > Each event hook should submit its preceeding data to the script:=20 > > AFTER_MAIL_FROM submits the MAIL FROM line AFTER_RCPT_TO=20 > submits the=20 > > RCPT TO line. AFTER_HEADER submits all lines between DATA=20 > and [blank=20 > > line] > >=20 > > There is one special thing:=3D20 > > Since there can be multiple RCPT TO lines, the event should=20 > fire with=20 > > the last RCPT TO, submitting all lines before. > >=20 > > --Harald > >=20 > >=20 > > > -----Urspr=3DFCngliche Nachricht----- > > > Von: [EMAIL PROTECTED] =20 > > >[mailto:[EMAIL PROTECTED] Im Auftrag von Rob Arends > > > Gesendet: Dienstag, 3. Februar 2004 14:28 > > > An: [EMAIL PROTECTED] > > > Betreff: [xmail] Re: AW: Re: AW: Re: SMTP Dialog Filter Hooks = =3D20 > > >=3D20 > > > Harald, > > > How would you propose that AFTER_HEADER be pre-emted.=3D20 > > > I can follow how the other hooks would work, but the after=3D20 > > > header one would have to be called when DATA command is=3D20 > > > issued. Otherwise how would you know when ALL the header=3D20 > > > commands were sent. You would not be able to=3D20 > > > terminate/reject/et before DATA, only an abrupt termination=3D20 > > > of the session. Comments??? > > >=3D20 > > > Rob :) > > >=3D20 > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Harald > > Schneider > > > > Sent: Tuesday, February 03, 2004 6:41 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [xmail] AW: Re: AW: Re: SMTP Dialog Filter Hooks =3D20 > > > > AFTER_MAIL_FROM, AFTER_RCPT_TO, AFTER_HEADER (=3D3D3Dbefore = data) > > > > would be =3D3D > > > > cool. > > > >=3D20 > > > > --Harald > > > >=3D20 > > > > > -----Urspr=3D3DFCngliche Nachricht----- > > > > > Von: [EMAIL PROTECTED] =3D20=20 > > > > >[mailto:[EMAIL PROTECTED] Im Auftrag von Rob Arends > > > > > Gesendet: Dienstag, 3. Februar 2004 01:41 > > > > > An: [EMAIL PROTECTED] > > > > > Betreff: [xmail] Re: AW: Re: SMTP Dialog Filter Hooks =3D3D20 > > > > >=3D3D20 > > > > > I agree, you should only implement these sort of hooks=20 > > on the=3D3D20 =3D > > =3D20 > > > > >header. But would you call the filter at the end of = the=3D3D20=3D20 > > > header,=3D20 > > > > >or after each line? =3D3D20 > > > > > Rob :-)=3D3D20 > > > > >=3D3D20 > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Harald > > > > Schneider > > > > > > Sent: Monday, February 02, 2004 11:16 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: [xmail] AW: Re: SMTP Dialog Filter Hooks > > > > > >=3D3D20 > > > > > > OK .. this is true for checking the data part.=20 > Under the=3D3D20 > > > > > aspect of =3D3D3D=3D3D20 > > > > > > decoding mime mails, it isn't a trivial thing at all. > > > > > >=3D3D20 > > > > > > But Hooks for the envelope lines and the start of data > > > > would be=3D3D3D20 =3D3D > > > >=3D20 > > > > > > comparable easy to implement and very valuable for future > > > > script =3D3D3D =3D3D > > > >=3D20 > > > > > > extensions. > > > > > >=3D3D20 > > > > > > --Harald > > > > > >=3D3D20 > > > > > >=3D3D20 > > > > > > > -----Urspr=3D3D3DFCngliche Nachricht----- > > > > > > > Von: [EMAIL PROTECTED] =3D3D20=3D20 > > > > > > >[mailto:[EMAIL PROTECTED] Im Auftrag von T. > > > > Mike Howeth > > > > > > > Gesendet: Montag, 2. Februar 2004 07:39 > > > > > > > An: [EMAIL PROTECTED] > > > > > > > Betreff: [xmail] Re: SMTP Dialog Filter Hooks > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > I add this functionality to xmail myself and it does > > > > not=3D3D3D20 =3D3D20 > > > > > > >inordinately =3D3D3D3D impair performance if 1) other =3D > > changes=3D3D20 > > > > > are=3D3D3D20 made=3D3D20 > > > > > > >to xmail to improve its =3D3D3D3D intrinsic=20 > > performance, 2)=3D3D20 > > > > > the=3D3D3D20 checks=3D3D20 > > > > > > >are aborted on messages that are long and 3)=20 > binary=3D3D3D20 =3D > > =3D3D20 > > > > > messages are=3D3D20 > > > > > > >correctly identified and not handled by the=3D3D3D20 =3D > > filter.=3D3D20 > > > > > However, it=3D3D20 > > > > > > >is not as simple as looking at each line=3D3D3D20 =20 > > presented=3D3D20 > > > > > after the DATA=3D3D20 > > > > > > >command: to correctly interpret=3D3D3D20 input, the = code=3D20 > > > must deal =3D3D > > > > with=3D3D20 > > > > > > >=3D3D3D3D message decoding on the fly=3D3D3D20 > > > > (quoted-printable, base64 =3D3D > > > > are=3D3D20 > > > > > > >trivial, but MIME must =3D3D3D3D be=3D3D3D20 dealt=20 > with too)=3D20 > > > and, at=3D3D20 > > > > > a minimum,=3D3D20 > > > > > > >support a scrolling-window=3D3D3D20 type of =3D3D3D3D = buffer =3D > > (DATA=3D3D20 > > > > > lines do not=3D3D20 > > > > > > >correspond to actual=3D3D3D20 message lines). Although I = =3D > > am=3D3D20 > > > > > =3D3D3D3D glad that=3D3D20 > > > > > > >I can reject=3D3D3D20 messages as they come in now, the = =3D > > amount=3D3D20 > > > > > of work =3D3D3D3D=3D3D20 > > > > > > >involved=3D3D3D20 was substantial and unless Davide is = a=3D20 > > > complete=3D3D20=3D20 > > > > > > >masochist,=3D3D3D20 there are probably features that would = =3D > > be=3D3D20 > > > > > better uses=3D3D20 > > > > > > >of=3D3D3D20 development time. (And, naturally, about a > > > > month after I=3D3D20 > > > > > > >got=3D3D3D20 it basically-where-i-wanted-it, I = =3D3D3D3D=3D20 > > > moved and no =3D3D > > > > longer=3D3D20 > > > > > > >have=3D3D3D20 adequate connectivity to host my own=20 > MTA box. =3D > > Ha.)=3D20 > > > > > > >=3D3D3D20 (and BTW, if you stop accepting a message=20 > during=3D20 > > > > > > >receipt,=3D3D3D20 you're telling =3D3D3D3D the other=20 > > end exactly =3D > > what=3D20 > > > > > > >they > > > > did that=3D3D3D20 > > > > > > > tripped the wire. It's best to =3D3D3D3D accept the rest = =3D > > -=3D3D3D20=3D20 > > > > > > > discarding it as you go - even after the decision is > > > > made to=3D3D3D20 > > > > > > > reject the message). > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > -----Original Message----- > > > > > > > From: [EMAIL PROTECTED] =3D20 > > > > > > >[mailto:[EMAIL PROTECTED] =3D3D3D3D On > Behalf > > > > Of Harald =3D3D > > > > =3D3D3D > > > > > > Schneider > > > > > > > Sent: Sunday, 1 February 2004 8:07 AM > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Subject: [xmail] SMTP Dialog Filter Hooks > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > Hi Davide, > > > > > > >=3D3D3D20 > > > > > > > is there a chance to see SMTP dialog filter hooks in > > > > the next=3D3D3D20 =3D3D > > > > =3D3D20 > > > > > > >release? =3D3D3D3D This would make the filtering=20 > > engine more=3D3D20 > > > > > flexible: =3D3D3D20 > > > > > > > You could check the RCPT_TO and act before the=3D20 > > > message is=3D3D3D20=3D20 > > > > > > > accepted. E.g. checking a forwarding target server,=3D20 > > > if the=3D3D3D20=3D20 > > > > > > > user exists there, before accepting and forwarding=3D20 > > > the whole =3D3D3D > > > > > > mail.=3D3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > Hooks after each SMTP command and after each data=20 > line=3D3D20 > > > > > would=3D3D3D20 be=3D3D20 > > > > > > >a nice=3D3D3D3D20 thing, e.g.: =3D3D3D20 > > > > > > > HOOK_HELO > > > > > > > HOOK_MAIL_FROM > > > > > > > HOOK_RCPT_TO > > > > > > > HOOK_DATALINE > > > > > > >=3D3D3D20 > > > > > > > So a script could also do anti spam and anti virus=3D20 > > > checking=3D3D3D20 =3D20 > > > > > > >on the fly,=3D3D3D3D20 aborting conversation without=20 > > accepting =3D > > =3D3D > > > > the=3D3D3D20 > > > > > > > whole message.=3D3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > What do you think? > > > > > > >=3D3D3D20 > > > > > > > All the best, > > > > > > > Harald > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > - > > > > > > > To unsubscribe from this list: send the line=3D20 > > > "unsubscribe=3D3D3D20 =3D20 > > > > > > >xmail" in the =3D3D3D3D body of a message to =3D3D > > > > [EMAIL PROTECTED] > > > > > > > For general help: send the line "help" in the body=20 > > of a=3D3D3D20 =3D > > =3D20 > > > > > > >message to [EMAIL PROTECTED] =3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > >=3D3D3D20 > > > > > > > - > > > > > > > To unsubscribe from this list: send the line =3D > > "unsubscribe=3D3D3D20 > > > > > > > xmail" in the body of a message to=3D20 > > > [EMAIL PROTECTED] > > > > > > > For general help: send the line "help" in the body=20 > > of a=3D3D3D20 > > > > > > > message to [EMAIL PROTECTED] > > > > > > >=3D3D3D20 > > > > > >=3D3D20 > > > > > > - > > > > > > To unsubscribe from this list: send the line "unsubscribe > > > > xmail" in=3D3D20 > > > > > > the body of a message to [EMAIL PROTECTED] For > > > > general help:=3D3D20 > > > > > > send the line "help" in the body of a message to=3D3D20 = =3D20 > > > > > >[EMAIL PROTECTED] =3D3D20 > > > > >=3D3D20 > > > > > - > > > > > To unsubscribe from this list: send the line=3D20 > > > "unsubscribe=3D3D20 xmail"=3D20 > > > > >in the body of a message to [EMAIL PROTECTED] = =3D20 > > > For general=3D20 > > > > >help: send the line "help" in the body of a=3D3D20 message = to=3D20 > > > > >[EMAIL PROTECTED] =3D3D20 > > > >=3D20 > > > > - > > > > To unsubscribe from this list: send the line "unsubscribe=20 > > xmail" in=3D20 > > > > the body of a message to [EMAIL PROTECTED] For=20 > > general help:=3D20 > > > > send the line "help" in the body of a message to=3D20 > > > > [EMAIL PROTECTED] > > > >=3D20 > > >=3D20 > > > - > > > To unsubscribe from this list: send the line "unsubscribe=3D20 > > > xmail" in the body of a message to [EMAIL PROTECTED] > > > For general help: send the line "help" in the body of a=3D20 > > > message to [EMAIL PROTECTED] > > >=3D20 > >=20 > > - > > To unsubscribe from this list: send the line "unsubscribe xmail" in > > the body of a message to [EMAIL PROTECTED] > > For general help: send the line "help" in the body of a message to > > [EMAIL PROTECTED] > >=20 > >=20 >=20 > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] >=20 - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
