Sorry, I did mean that it seems to delay all SMTP processes.
hmm, then it's implemented wrong. The delay should be after each of multiple RCPT TO in a msg starting with the second one, but if there is only one RCPT TO:, then no delay.
> Applied to all SMTP session, "should" not be a pb since 99+% of all SMTP > sessions have one RCTP TO: so there's nothing to apply the delay to.
... except if we endup in the DoS situation again, where other SMTP connections will now be affected instead of the Web mail and other processes on the server. Not a big deal, but it degrades the service.
STMPD receiving delays is plumbing, no user will ever see that. I'd be very surprised if it ever approached DoS levels.
> ok, that's another benefit of IMGate doing the same. Note that big doses > of mail from your SMTP gateway will cause IMail to "refuse connection" > temporarily, actually mixing "accept connection" with "refuse connection", > causing the SMTP gateway to defer. It msg will probably be accepted by > Imail next attempt.
I'll have to investigate this... we're pumping a light load of 14k/day of messages into it, and I cant say I've noticed a problem with queueing yet.
that's not very many. how about 15+ k/hour?
> Bennett Todd's pop-before-smtp works well. This avoids exporting the > passwords from Imail to the SMTP gateway.
Mmm, there are the usual issues with using pop-before-smtp, such as mail clients sending before downloading POP mail - it doesnt look good for the customers getting error messages.
This only affects the roamers, and an immediate re-send goes through. No big deal.
Also, what if it's a server sending messages
servers are not roamers, they are fixed IPs that you whitelist.
and a separate fetchmail-like client? Getting them co-ordinated is a fiddle for customers.
You can always dream up gotchas, or you can try it and see, including user education.
Also, you'd have to run the log scanner on the IMail server and somehow export the cached logins to the Auth SMTP processes on another server or SQL database.
no, you set Imail POP to log to IP of your outbound relay gateway. Nothing else needs to be done in IMail.
> >It would require some form of > >daemon to authenticate against the registry entries. > > nah, too complicated.
It's actually pretty simple - especially if you've ever read the bugtraq thread on how to decode IMail passwords ;-)
extractusers.exe does the whole thing, but I'd rather not sling passwords around and store them in multiple, need-to-by-synchronized locations if it can be avoided, and it can.
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
