Is there any way to rewrite the TO: field on the mailer-daemons queue
warning message? Our management would like to hide the warning
messages from the users and redirect them to IT staff for resolution.
Brian
> Is there any way to rewrite the TO: field on the mailer-daemons queue
> warning message? Our management would like to hide the warning
> messages from the users and redirect them to IT staff for resolution.
Have you considered using you own scripts to notify IT staff about
messages staying in queue for more that (e.g.) 90 minutes or messages
with *two* or more failed delivery attempts?
By default "delayed delivery" warnings are generated after 4 hours.
I believe you ask for something that is a bad practice in most situations.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
My father, a good man, told me, "Never lose your ignorance; you cannot
replace it."
-- Erich Maria Remarque
----
http://groups.google.com/groups?selm=877ihssiam@robert.fsf.h obby-site.com
On 01/29/08 10:33, Andrzej Adam Filip wrote:
> Have you considered using you own scripts to notify IT staff about
> messages staying in queue for more that (e.g.) 90 minutes or messages
> with *two* or more failed delivery attempts? By default "delayed
> delivery" warnings are generated after 4 hours.
Rather than finding the messages in the mail queue that warrant
notification, why not have multiple queues. Have the general mail queue
like you have now and also have another mail queue that is messages that
have surpassed X delivery attempts or Y time (based on delivery attempts
and scheduling). This way, any messages in the new mail queue(s) will
all warrant investigation.
If you do not have a queue runner on this new ""Trouble, you could have
something (cron job?) move messages out of the ""Trouble queue and take
action on them. Said action could be to notify someone of the problem
(with details from the q/d file(s)) as well as moving the message to a
""Pending queue where your technicians could look for the message(s).
I'm suggesting the ""Pending queue so you don't get multiple
notifications on the same message.
> I believe you ask for something that is a bad practice in most
> situations.
Rather than altering what Sendmail sends, I'd be tempted to put a DSN /
MDN filter on select recipients mail boxes and redirect said DSN / MDN
to the IT staff. This could also be selectively applied.
Grant. . . .
On Jan 29, 10:58 am, Grant Taylor
> On 01/29/08 10:33, Andrzej Adam Filip wrote:
>
> > Have you considered using you own scripts to notify IT staff about
> > messages staying in queue for more that (e.g.) 90 minutes or messages
> > with *two* or more failed delivery attempts? By default "delayed
> > delivery" warnings are generated after 4 hours.
>
> Rather than finding the messages in the mail queue that warrant
> notification, why not have multiple queues. Have the general mail queue
> like you have now and also have another mail queue that is messages that
> have surpassed X delivery attempts or Y time (based on delivery attempts
> and scheduling). This way, any messages in the new mail queue(s) will
> all warrant investigation.
>
> If you do not have a queue runner on this new ""Trouble, you could have
> something (cron job?) move messages out of the ""Trouble queue and take
> action on them. Said action could be to notify someone of the problem
> (with details from the q/d file(s)) as well as moving the message to a
> ""Pending queue where your technicians could look for the message(s).
> I'm suggesting the ""Pending queue so you don't get multiple
> notifications on the same message.
>
> > I believe you ask for something that is a bad practice in most
> > situations.
>
> Rather than altering what Sendmail sends, I'd be tempted to put a DSN /
> MDN filter on select recipients mail boxes and redirect said DSN / MDN
> to the IT staff. This could also be selectively applied.
>
> Grant. . . .
That sounds like a plan, I didn't like the idea of hiding the warning
response from sendmail either. a second queue with a cron watch
script would work.
The only trouble I would see with the dsn/mdn filter is that mailer-
daemon sends a message back to the sender, who could be anybody so it
wouldn't match a specific filter would it?
On 01/29/08 12:19, Brian wrote:
> That sounds like a plan, I didn't like the idea of hiding the warning
> response from sendmail either. a second queue with a cron watch
> script would work.
*nod*
> The only trouble I would see with the dsn/mdn filter is that
> mailer-daemon sends a message back to the sender, who could be anybody
> so it wouldn't match a specific filter would it?
Also, Sendmail will send DSNs back to the envelope sender of the message
that the DSN is in response to.
The filtering will be in the local delivery chain after Sendmail. Thus
prior to the DSN being put in to the local recipients mail box, it will
be re-directed to IT support staff. In short, only DSNs that would
otherwise go in to a local recipients mail box will be redirected (via
the LDA) to the IT support staff.
I'm not quite understanding what you are asking, please try to
re-explain and I'll try to do the same.
Grant. . . .
On Jan 29, 1:56 pm, Grant Taylor
> On 01/29/08 12:19, Brian wrote:
>
> > That sounds like a plan, I didn't like the idea of hiding the warning
> > response from sendmail either. a second queue with a cron watch
> > script would work.
>
> *nod*
>
> > The only trouble I would see with the dsn/mdn filter is that
> > mailer-daemon sends a message back to the sender, who could be anybody
> > so it wouldn't match a specific filter would it?
>
> Also, Sendmail will send DSNs back to the envelope sender of the message
> that the DSN is in response to.
>
> The filtering will be in the local delivery chain after Sendmail. Thus
> prior to the DSN being put in to the local recipients mail box, it will
> be re-directed to IT support staff. In short, only DSNs that would
> otherwise go in to a local recipients mail box will be redirected (via
> the LDA) to the IT support staff.
>
> I'm not quite understanding what you are asking, please try to
> re-explain and I'll try to do the same.
>
> Grant. . . .
Apparently none of this will work, my management wants to completely
hide the fact that we even have queue warnings and NDR's and have them
exclusively handled by IT. My best guess so far has been procmail on
every mail, match the subject and formail it.. can you think of
anything better?
On 01/29/08 14:06, Brian wrote:
> Apparently none of this will work, my management wants to completely
> hide the fact that we even have queue warnings and NDR's and have
> them exclusively handled by IT. My best guess so far has been
> procmail on every mail, match the subject and formail it.. can you
> think of anything better?
Aside from a new PHB?
Aside from having all your email go through some sort of proxy type
routing that requires intervention?
Can I ask what the underlying motivation for the PHB's request is? It
sounds like there is a problem that could be better addressed than
patching the symptoms.
I believe you can turn off queue warnings for delayed messages, or at
least set it high enough that they don't happen.
You could use something like MIMEDefang to filter messages and alter
recipients for those that look like DSNs so that they go to IT. However
I'm not sure how you will handle locally generated DSNs.
Grant. . . .
On Jan 29, 2:58 pm, Grant Taylor
>
> Aside from a new PHB?
>
> Aside from having all your email go through some sort of proxy type
> routing that requires intervention?
>
> Can I ask what the underlying motivation for the PHB's request is? It
> sounds like there is a problem that could be better addressed than
> patching the symptoms.
>
> I believe you can turn off queue warnings for delayed messages, or at
> least set it high enough that they don't happen.
>
> You could use something like MIMEDefang to filter messages and alter
> recipients for those that look like DSNs so that they go to IT. However
> I'm not sure how you will handle locally generated DSNs.
>
> Grant. . . .
I may look into exim, it seems to have this feature built in.
Our IT management basically wants to hide all aspects of any failure
and have the opportunity to fix it before anybody notices, this came
up because one email got delayed while sending to aol because aol
blocked our relay before I setup their loopback system because someone
sent spam to our mail servers which then sent a NDR back to
someuser@aol.com who then clicked 'this is spam' and got our relays
blocked.
I thought about mimedefang as well, and along with procmail they seem
to have the same issue where you can't seem to modify a locally
generated dsn, so my choice is either to modify savemail.c or switch
mailers entirely.
Brian
> On Jan 29, 2:58 pm, Grant Taylor
>>
>> Aside from a new PHB?
>>
>> Aside from having all your email go through some sort of proxy type
>> routing that requires intervention?
>>
>> Can I ask what the underlying motivation for the PHB's request is? It
>> sounds like there is a problem that could be better addressed than
>> patching the symptoms.
>>
>> I believe you can turn off queue warnings for delayed messages, or at
>> least set it high enough that they don't happen.
>>
>> You could use something like MIMEDefang to filter messages and alter
>> recipients for those that look like DSNs so that they go to IT. However
>> I'm not sure how you will handle locally generated DSNs.
>>
>> Grant. . . .
>
> I may look into exim, it seems to have this feature built in.
>
> Our IT management basically wants to hide all aspects of any failure
> and have the opportunity to fix it before anybody notices, this came
> up because one email got delayed while sending to aol because aol
> blocked our relay before I setup their loopback system because someone
> sent spam to our mail servers which then sent a NDR back to
> someuser@aol.com who then clicked 'this is spam' and got our relays
> blocked.
> [...]
Senders (users) *SHOULD* know about delivery problems/delays.
IT *SHOULD* merely know *before* (e.g. 2 hours+) senders get
any "delay notification" (It is usually sent after 4 hours).
"Queue monitoring" tools for IT department should do the trick much
better without any need to change behavior users may expect.
IMHO you follow "sub optimal" (wrong) path :-)
P.
BTW 5+ years ago I lowered warning timeout from default 4h to 2h on
sendmail under my control.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Happiness isn't something you experience; it's something you remember.
-- Oscar Levant
----
http://groups.google.com/groups?selm=87myqopaye@julia.fsf.ho bby-site.com
On 1/29/2008 3:16 PM, Brian wrote:
> I may look into exim, it seems to have this feature built in.
*blink* (see below)
> Our IT management basically wants to hide all aspects of any failure
> and have the opportunity to fix it before anybody notices, this came
> up because one email got delayed while sending to aol because aol
> blocked our relay before I setup their loopback system because
> someone sent spam to our mail servers which then sent a NDR back to
> someuser@aol.com who then clicked 'this is spam' and got our relays
> blocked.
Oh, the ""management is with in your department. That changes things.
Is someone protecting their job or just trying to avoid problems??? I
had assumed that the ""management in question was out side of your
department as it is rare (in my experience) for inter department
management to be so (shall we say) silly. Good luck and for your sake I
hope that someone is trying to avoid problems rather than protecting
their job.
> I thought about mimedefang as well, and along with procmail they seem
> to have the same issue where you can't seem to modify a locally
> generated dsn, so my choice is either to modify savemail.c or switch
> mailers entirely.
*nod* Well, I don't like seeing people switching away from Sendmail (no
one likes to see someone leaving their preferred application), but at
least you seem to have some reasoning behind it. You seem to be looking
for information to make an informed decision. Good luck.
Grant. . . .
On Tue, 29 Jan 2008 07:33:35 -0800 (PST), Brian
wrote:
>Is there any way to rewrite the TO: field on the mailer-daemons queue
>warning message? Our management would like to hide the warning
>messages from the users and redirect them to IT staff for resolution.
You could try to insert an Error-to: header in each mail received from
the internal network. You probably have to use something like MIMEdefang
(or MailScanner with some configuration tweaks).
--
Peter Peters
On 01/29/08 09:33, Brian wrote:
> Is there any way to rewrite the TO: field on the mailer-daemons queue
> warning message? Our management would like to hide the warning
> messages from the users and redirect them to IT staff for resolution.
I guess an important question to ask is "Do you need to redirect DSNs
for both internally and externally generated DSNs or just internally
generated DSNs. I.e. what are you suppose to do when someone else's
Exchange 2000 server sends you a DSN because one of your users sent to
an invalid user (initial message was accepted and then bounced). What
about back scatter spam? Are those inbound DSNs suppose to be
redirected to IT too?
Grant. . . .
Brian wrote:
> Apparently none of this will work, my management wants to completely
> hide the fact that we even have queue warnings and NDR's and have them
> exclusively handled by IT. My best guess so far has been procmail on
> every mail, match the subject and formail it.. can you think of
> anything better?
It depends on your definition of "better", but here goes...
1) Configure a FallbackMX machine for outbound mail. The queue on
your main machine will be very small. Any queue warnings and
non-delivery notifications are almost certain to be generated by the
FallbackMX host.
2) When the FallbackMX host *does* generate queue warnings or
non-delivery notifications, they will arrive at your main MX machine
over SMTP, giving you a chance to inspect and redirect them with (for
example) MIMEDefang.
You need to be really really REALLY careful not to set up a mail loop
in this situation. Your primary MX host must either be the actual
host that receives mail for your domain(s) or must have mailertable
entries for those domains so it doesn't try to use the fallbck MX host
for "inbound" mail. Simlarly, the fallback MX host should route
"inbound" mail intelligently.
Please note that external systems may generate warnings or
non-delivery notifications totally out of your control. Whether or
not you choose to suppress those is up to you, but I sure wouldn't do
it. It's way too easy to screw up and either lose a non-delivery
notification or reveal private information to the wrong set of eyes.
Regards,
David.
>1) Configure a FallbackMX machine for outbound mail. The queue on
>your main machine will be very small. Any queue warnings and
>non-delivery notifications are almost certain to be generated by the
>FallbackMX host.
What is your oppinion of having the "FallbackMX" be a program that takes the original message and sends it as an rfc822/message MIME attachment to IT for them to parse and handle accordingly?
Grant. . . .
Grant Taylor wrote:
>>1) Configure a FallbackMX machine for outbound mail. The queue on
>>your main machine will be very small. Any queue warnings and
>>non-delivery notifications are almost certain to be generated by the
>>FallbackMX host.
> What is your oppinion of having the "FallbackMX" be a program that takes
> the original message and sends it as an rfc822/message MIME attachment to
> IT for them to parse and handle accordingly?
??
I do not think you correctly undestand the purpose and operation of
Fallback MX.
Regards,
David.
On 1/30/2008 8:08 PM, David F. Skoll wrote:
> I do not think you correctly undestand the purpose and operation of
> Fallback MX.
I do know what a Fallback MX is and what it is for. I was considering a
possibility to mis-use of a Fallback MX to try to help the OP.
Grant. . . .
Management wants to hide any potential mail delays to appear perfect
in all instances, probably for job security because our CEO will
supposedly fire someone if mail is more than 3 minutes delayed to his
blackberry.
We only need to handle the internally generated DSN's, preferably only
the ones with queue warnings because that is seen by my manager as our
problem 100% of the time. Invalid users and other messages should be
directed back to the users like usual so I can just match Subject's
with procmail (or mimedefang, but I know procmail better) on a 3rd
host.
Here is what I have now, and what appears like it world work.
mx01 - primary incoming (has an outgoing queue that basically sits on
NDR's that don't get delivered, usually 1500-5000 or so)
mx02 - secondary incoming, primary outgoing from exchange. this queue
is almost always 0
proposed
mx03 - mx02 relays to mx03 where certain DSN's are filtered by
procmail or mimedefang and then returned to the exchange environment.
Brian wrote:
> Management wants to hide any potential mail delays to appear perfect
> in all instances, probably for job security because our CEO will
> supposedly fire someone if mail is more than 3 minutes delayed to his
> blackberry.
Well... how's your resume coming? Your CEO sounds like a nightmare out
of "Dilbert".
> We only need to handle the internally generated DSN's, preferably only
> the ones with queue warnings because that is seen by my manager as our
> problem 100% of the time.
Ah, so your manager is an escapee from "Dilbert" also?
You do realize that you can simply prevent your local Sendmail from generating
queue warnings at all by setting confTO_QUEUE_WARN to a higher value than
confTO_QUEUE_RETURN? I believe this setting will meet all the idiot-PHB
criteria *and* piss off end-users as well, making it the perfect solution
for your company! (Well, you still need to nuke failure notifications, but
oh well...)
Regards,
David.
P.S. Let me know privately who you work for so I know not to do business
with them... :-)
On Thu, 31 Jan 2008 06:13:52 -0800 (PST), Brian
wrote:
>Management wants to hide any potential mail delays to appear perfect
>in all instances, probably for job security because our CEO will
>supposedly fire someone if mail is more than 3 minutes delayed to his
>blackberry.
When people don't get mail within a couple of minutes they will notice
some day. And even the stupiest people can come up with friends who can
read Received: headers and complain.
--
Peter Peters