Hello Davide,=20 > > Suspend outgoing messages.
> Just set a long retry policy and take the Exchange server offline. Exchange is just one example; same applies if the internet connection is = down for some hours (for outgoing traffic). Retries eventually trigger = "temporary error"-messages. To detect line outages or other failures I have set "NotifyTryPattern" to "2, another value I don't remember now". But if I = and the users _know_ that the connection is down it makes more sense to = suspend sending until everything is fixed. Retries also are usually configured to become less frequent over time, = thus making delivery slower if the problem is solved. Of course one can flush = the queue but an interface "problem solved, now resume normal operation" = makes sense, IMO. > Did you take a look at the files inside the slog directories=20 > inside the=20 > spool? Yes, but the slogs are per message (very useful, but hard to find), but = IMO everything sending related should be logged in the SMAIL-Logs, including = non successfull sends, not different to SMTP. Also, the SLOG-Logs are lost if the message is removed after a permanent failure or to many retries (keeping frozen messages just for the sake of logging is a bit much). So, no trace of a message is left in the logs, which is bad bad bad. > > "pseudo log" of commands for Xmail-Postmaster > Usually SMTP messages, have all the necessary information to=20 > understand=20 > where the transaction broke. This is why there is some text after the=20 > status code ;) Hehe, I see you don't have to deal with ... not too ... you know what I = mean. Let's put it another way: reading and understanding what is written is = not a common thing. Also sometimes the info "after DATA" is missing (IIRC). You are right, more a nice-to-have, but nice nonetheless. :-) Regards, Manuel Martin - 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]
