Anybody know of a way to disable sendmail for all mail that is not within our specified “domains” ?
i.e. - we process tickets to webmaster from yahoo, hotmail blah blah blah and it tries to autoreply
To them with the ticket creation. Obviously we still want to send the mail internally for our own users.
Any information on how I could od this would be very helpful!
Thanks,
T.J. Maciak
Internet/Intranet Developer
Department of IT
City of Grand Rapids
P: (616)456-3713
F: (616)456-3448
At Friday 8/19/2005 01:07 PM, tmaciak@ci.grand-rapids.mi.us wrote:
Anybody know of a way to disable sendmail for all mail that is not within
our specified “domains” ?
i.e. - we process tickets to webmaster from yahoo, hotmail blah blah blah
and it tries to autoreply
To them with the ticket creation. Obviously we still want to send the
mail internally for our own users.Any information on how I could od this would be very helpful!
If I understand the problem correctly, a quick & dirty solution would be to
replace the Autoreply scrip with new scrip having a custom condition. The
condition would check the requestor email and would succeed only for the
email addresses you wanted to reply to.
Steve
Hi Stephen,
I am testing that right now using this in Scrip #3:
=== START
my $requestor_address = $self->TicketObj->RequestorAddresses;
my @user = split(‘@’, $requestor_address);
if ($user[1] eq ‘ci.grand-rapids.mi.us’) {
$RT::Logger->debug( "COGR - user is local to ci.grand-rapids.mi.us domain - autoreply is ok!"); return 1; } else {
$RT::Logger->debug( "COGR - user belongs to the $user[1] domain - ABORT autoreply!!!!"); return undef; }
=== END
However, it states: (Use these fields when you choose ‘User Defined’ for a condition or action)
And Scrip #3 is using “Autoreply to Requestors” and not “User Defined”. If I change it to user
Defined I think it will not autoreply to the requestor, right?
T.J. Maciak
Internet/Intranet Developer
Department of IT
City of Grand Rapids
P: (616)456-3713
F: (616)456-3448From: Stephen Turner [mailto:sturner@MIT.EDU]
Sent: Friday, August 19, 2005 1:51 PM
To: Maciak, TJ; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Sendmail - outgoing mail
At Friday 8/19/2005 01:07 PM, tmaciak@ci.grand-rapids.mi.us wrote:
Anybody know of a way to disable sendmail for all mail that is not
within our specified “domains” ?
i.e. - we process tickets to webmaster from yahoo, hotmail blah blah
blah and it tries to autoreply To them with the ticket creation.
Obviously we still want to send the mail internally for our own users.Any information on how I could od this would be very helpful!
If I understand the problem correctly, a quick & dirty solution would be to replace the Autoreply scrip with new scrip having a custom condition. The condition would check the requestor email and would succeed only for the email addresses you wanted to reply to.
Steve
At Friday 8/19/2005 01:53 PM, tmaciak@ci.grand-rapids.mi.us wrote:
However, it states: (Use these fields when you choose ‘User Defined’ for a
condition or action)
And Scrip #3 is using “Autoreply to Requestors” and not “User
Defined”. If I change it to user
Defined I think it will not autoreply to the requestor, right?
It’s only the condition you need to fill in and set to UserDefined. You
should leave the action set to “Autoreply to Requestors”
Steve
Hello:
We’re using RT 3.4.1 for our internal trouble ticket system
We have several monitoring programs doing SNMP monitoring. When they
detect problems, they generate an e-mail, which hits the RT box, which
hits sendmail, then an alias that hits rt-mailgate. We also have a
scrip (ExtractCustomFieldValues, from the Wiki) running that populates
custom fields (so the body of the messages are parsed). The messages
are short.
But there can be lots of them. Which tends to kill the box: memory
exhaustion.
The problem is, lots of messages come in at once, sendmail obliges, and
forks off an rt-mailgate for each one, and then moves on. Even
throttling sendmail (telling it to only accept x messages concurrently)
causes the problem, because sendmail just forks off the rt-mailgate and
goes on. It only launches x at a time, but it doesn’t care that x! are
still running. 
So, I’m wondering if anyone else has this problem. I see several
solutions. One would be to see if there’s any way I can make sendmail
actually WAIT for the rt-mailgate to finish. If anyone out there knows
how to do that, that would be nice (and might be nice to put in the Wiki
too). Barring that, I’m seeing a real queue mechanism, where sendmail
just receives all the mail and saves it (possibly in a maildir, so I can
process them one at a time easier) and I’ll use that as a queue, and
right a queue processor that submits those one at a time to rt-mailgate.
Has anyone written anything like that? If not, well, I’ll probably be
announcing it at some point in the future.
Thanks,
Kevin
This communication may contain privileged and/or confidential information. It
is intended solely for the use of the addressee. If you are not the intended
recipient, you are strictly prohibited from disclosing, copying, distributing
or using any of this information. If you received this communication in error,
please contact the sender immediately and destroy the material in its entirety,
whether electronic or hard copy. You may not directly or indirectly reuse or
redisclose such information for any purpose other than to provide the services
for which you are receiving the information.
Telsource Corporation
8237 Dow Cir, Strongsville, OH 44136
Hello:
We’re using RT 3.4.1 for our internal trouble ticket system
We have several monitoring programs doing SNMP monitoring. When they
detect problems, they generate an e-mail, which hits the RT box, which
hits sendmail, then an alias that hits rt-mailgate. We also have a
scrip (ExtractCustomFieldValues, from the Wiki) running that populates
custom fields (so the body of the messages are parsed). The messages
are short.But there can be lots of them. Which tends to kill the box: memory
exhaustion.The problem is, lots of messages come in at once, sendmail obliges, and
forks off an rt-mailgate for each one, and then moves on. Even
throttling sendmail (telling it to only accept x messages concurrently)
causes the problem, because sendmail just forks off the rt-mailgate and
goes on. It only launches x at a time, but it doesn’t care that x! are
still running.So, I’m wondering if anyone else has this problem. I see several
solutions. One would be to see if there’s any way I can make sendmail
actually WAIT for the rt-mailgate to finish. If anyone out there knows
how to do that, that would be nice (and might be nice to put in the Wiki
too). Barring that, I’m seeing a real queue mechanism, where sendmail
just receives all the mail and saves it (possibly in a maildir, so I can
process them one at a time easier) and I’ll use that as a queue, and
right a queue processor that submits those one at a time to rt-mailgate.
Has anyone written anything like that? If not, well, I’ll probably be
announcing it at some point in the future.
If you change
O DeliveryMode=background
to
O DeliveryMode=queued
in sendmail.cf, sendmail will queue all messages when received instead
of starting a background delivery process for each. However, then you
move the problem to the queue runs - if you start them often enough to
get timely delivery you may have several overlapping runs if they
can’t process the whole queue before the next one starts. You might
set sendmail’s timer based runs to go less frequently and have a
script that starts a run with only a short delay after the last one
finishes.
You can also have sendmail queue only when the load reaches a certain
level - and it can take the value in the Precedence: header into account
when deciding when to queue.
Les Mikesell
les@futuresource.com
If you change
O DeliveryMode=background
to
O DeliveryMode=queued
in sendmail.cf, sendmail will queue all messages when received instead
of starting a background delivery process for each. However, then you
move the problem to the queue runs - if you start them often enough to
get timely delivery you may have several overlapping runs if they
can’t process the whole queue before the next one starts. You might
set sendmail’s timer based runs to go less frequently and have a
script that starts a run with only a short delay after the last one
finishes.
Thanks! We can try that.
The thing is, it should only be in pathological cases that I get this
many messages all at once: last time, I wrote a script that tried to
create about 70 tickets all at once. I know better now, and in that
case, I’d put in a delay. This time, it was a misconfigured process
that started sending 8*600 messages, once every 15 minutes, for 8 hours.
Pathological…but I’d like the box to live through it.
You can also have sendmail queue only when the load reaches a certain
level - and it can take the value in the Precedence: header into account
when deciding when to queue.
Cool: I’ll have to look into that. That kind of sounds like what I
really want.
Thanks for the response.
Kevin
This communication may contain privileged and/or confidential information. It
is intended solely for the use of the addressee. If you are not the intended
recipient, you are strictly prohibited from disclosing, copying, distributing
or using any of this information. If you received this communication in error,
please contact the sender immediately and destroy the material in its entirety,
whether electronic or hard copy. You may not directly or indirectly reuse or
redisclose such information for any purpose other than to provide the services
for which you are receiving the information.
Telsource Corporation
8237 Dow Cir, Strongsville, OH 44136
So, I’m wondering if anyone else has this problem. I see several
solutions. One would be to see if there’s any way I can make sendmail
actually WAIT for the rt-mailgate to finish. If anyone out there knows
how to do that, that would be nice (and might be nice to put in the Wiki
too). Barring that, I’m seeing a real queue mechanism, where sendmail
just receives all the mail and saves it (possibly in a maildir, so I can
process them one at a time easier) and I’ll use that as a queue, and
right a queue processor that submits those one at a time to rt-mailgate.
Has anyone written anything like that? If not, well, I’ll probably be
announcing it at some point in the future.
My approach would be to shim it:
Instead of piping directly to rt-mailgate, pipe to your own script,
which simply drops the message in a directory. Then have a background
process running which lifts those messages out one at a time, and hands
them to mailgate directly.
The only problem would be scanning the queue in the appropriate fashion
so as to make sure it’s roughly FIFO; the proper arguments to ls in
your unqueue script are probably the magic there.
Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
"NPR has a lot in common with Nascar... we both turn to the left."
- Peter Sagal, on Wait Wait, Don't Tell Me!