Now that would be a great thing! Never have liked how my front end server just has to accept everything @localdomain before forwarding to my backend server. I end up with a lot of undeliverables to bogus accounts.
I currently use custdomains to smtprelay mail to my backend server. Wish xmail could check some local recipients file even when using custdomains. Then I could setup a scheduled job to pull a userlist from the backend server and keep the local recipients file updated on my gateway. The setup I'm using is the same as you would do for a secondary MX server so the problem applies to in two cases. Having communication between X1 and X2 on the fly as mail comes in will be a problem if X1 is your secondary MX server and X2 is down. Bill >---------- >From: Harald Schneider[SMTP:[EMAIL PROTECTED] >Sent: Tuesday, February 03, 2004 12:11 PM >To: [EMAIL PROTECTED] >Subject: [xmail] AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: SMTP Dialog Filter >Hooks > >The original idea was the constellation of 2 XMail servers: > >X1 ---- smtpfwd --> x2 > >X1 could use AFTER_RCPT_TO to query X2 via control protocol, if the >user exists before forwarding. The most elegant way to solve this, >would be on SMTP protocol level.=20 > >There is also the fact of reducing bounced mails and notificatons >to a minimum. Especially when the next virus attack swaps over .. > >--Harald > > > >> -----Urspr=FCngliche Nachricht----- >> Von: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] Im Auftrag von Davide Libenzi >> Gesendet: Dienstag, 3. Februar 2004 20:51 >> An: XMail mailing list >> Betreff: [xmail] Re: AW: Re: AW: Re: AW: Re: AW: Re: SMTP=20 >> Dialog Filter Hooks >>=20 >>=20 >> On Tue, 3 Feb 2004, Harald Schneider wrote: >>=20 >> > I see .. reading incoming DATA (including the header) and passing=20 >> > control to an extenal thread while buiffers are still=20 >> receiving can be=20 >> > tricky. YOu're right. this one should be skipped and filtes should=20 >> > generally be implemented after each server reply, except data: >> >=20 >> > EHLO >> > --> AFTER_EHLO >> > MAIL FROM: ... >> > --> AFTER_MAIL_FROM >> > RCPT TO: ... >> > --> AFTER_RCPT_TO >> > DATA >> > From: ... >> > To: ... >> > .. >> > .. >> > .. >> >=20 >> > Genrally, filters must not consume more time than a return from a=20 >> > subroutine, which checks if a filter is plugged in. Filters should=20 >> > also be able to overwrite XMail's resonses. >> >=20 >> > Davide, what do you think about that ? >>=20 >> Honestly, I do not like it becuase I think it does not buy=20 >> enough to us=20 >> to balance the intrisic "crappyness" of running external=20 >> commands at SMTP=20 >> level. We do have filters, and IMO this should be enough.=20 >> Repeat me again=20 >> what this does buy to us ... >>=20 >>=20 >>=20 >> - Davide >>=20 >>=20 >> - >> To unsubscribe from this list: send the line "unsubscribe=20 >> xmail" in the body of a message to [EMAIL PROTECTED] >> For general help: send the line "help" in the body of a=20 >> 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] > > - 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]
