RT sends it’s mail out with a mail header specifying the Precedence as
being “bulk.” We’re now running into issues where customer’s mail
server (and all EZMLM lists by default) drop any mail with the
precedence set to bulk as being junk mail or in the case of EZMLM
autoresponders.
I’d like to override the precedence. I found the relevant code, but I
had a couple of questions:
-
Is there any problem with changing the precedence? I see several
places that look like RT evaluates the precedence of incoming email.
I’m concerned that RT may be expecting it’s own mail to have precedence
or bulk as a safeguard against mail loops or something. Am I being
paranoid?
-
Is there a way to set the precedence without editing a local copy of
the mail subroutine? Is it a configuration option somewhere I missed?
Can I set it in the scripts?
-
Has anyone done this before who can share with me how you set it up?
I apologize if this has been answered in the past. HTDig doesn’t appear
to be working right now so I was unable to search the mailing list
archives.
Thank You,
Jason
- Is there any problem with changing the precedence? I see several
places that look like RT evaluates the precedence of incoming email.
I’m concerned that RT may be expecting it’s own mail to have precedence
or bulk as a safeguard against mail loops or something. Am I being
paranoid?
RT, ironically, does the same thing as EZLM – it uses the Precedence:
header to drop mail from autoresponders and the like. It uses a
separate flag for loop detection, X-RT-Loop-Prevention. Hence, changing
the precedence of outgoing mail won’t break anything.
- Is there a way to set the precedence without editing a local copy of
the mail subroutine? Is it a configuration option somewhere I missed?
Can I set it in the scripts?
It can be set in the templates; simply add a Precedence: line to the
headers. This will override the default value of “bulk” that is set in
RT::Actions::SendMail. This is probably preferable to having to apply a
local patch to the code.
Networking – one letter away from not working
- Is there any problem with changing the precedence? I see several
places that look like RT evaluates the precedence of incoming email.
I’m concerned that RT may be expecting it’s own mail to have precedence
or bulk as a safeguard against mail loops or something. Am I being
paranoid?
RT, ironically, does the same thing as EZLM – it uses the Precedence:
header to drop mail from autoresponders and the like. It uses a
separate flag for loop detection, X-RT-Loop-Prevention. Hence, changing
the precedence of outgoing mail won’t break anything.
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act on
it. Setting the precedence header to “bulk” is a pretty widely honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a loop.
- Is there any problem with changing the precedence? I see several
places that look like RT evaluates the precedence of incoming email.
I’m concerned that RT may be expecting it’s own mail to have
precedence
or bulk as a safeguard against mail loops or something. Am I being
paranoid?
RT, ironically, does the same thing as EZLM – it uses the Precedence:
header to drop mail from autoresponders and the like. It uses a
separate flag for loop detection, X-RT-Loop-Prevention. Hence,
changing
the precedence of outgoing mail won’t break anything.
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act on
it. Setting the precedence header to “bulk” is a pretty widely honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a loop.
Jesse, to clarify, are when you say “Other than that it continues to
act on it” are you saying that Alex’s statement that RT will use the
X-RT-Loop-Prevention header is incorrect? Or are you saying that it
doesn’t respond to the messages but it still puts them in the queue?
The core question for me is whether changing the precedence header to
“Normal” will cause problems. Unfortunately, it appears that I’ve got
both EZMLM and a customer’s MTA that are silently dropping mail with
the bulk precedence.
Alex: Thanks for the tips on the templates! I much prefer that to
localizing the routine.
Thank You,
Jason
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act on
it. Setting the precedence header to “bulk” is a pretty widely honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a loop.
Jesse, to clarify, are when you say “Other than that it continues to
act on it” are you saying that Alex’s statement that RT will use the
X-RT-Loop-Prevention header is incorrect? Or are you saying that it
doesn’t respond to the messages but it still puts them in the queue?
RT should use the X-RT-Loop-Prevention header to stop RT from talking to
itself. But ezmlm and your customer’s MTA are broken in such a way that
by catering to them, RT could get itself stuck in a loop with another
poorly behaved MTA.
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act on
it. Setting the precedence header to “bulk” is a pretty widely honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a loop.
Not sure if this has been covered yet (I’m a little late to this thread),
but we’ve had several customers call us complaining that then never received
correspondence from us. After some digging, it turns out their spam filters
had interpreted the bulk precedence header as a sure sign that our
correspondence was spam-tastic.
-Darren
Not sure if this has been covered yet (I’m a little late to this thread),
but we’ve had several customers call us complaining that then never received
correspondence from us. After some digging, it turns out their spam filters
had interpreted the bulk precedence header as a sure sign that our
correspondence was spam-tastic.
Right. Which is just wrong. When picking between “possibly get caught in
users’ overzealous mail filters” and “get into mail loops with other
autoresponders”, we chose the former. (We chose the default before
people really had spam filters, actually 
Precedence: bulk is the
closest we have to an internet standard for “I’ve been sent by a
machine. Machines should not autoreply to me.”
Right. Which is just wrong. When picking between “possibly get caught in
users’ overzealous mail filters” and “get into mail loops with other
autoresponders”, we chose the former. (We chose the default before
people really had spam filters, actually Precedence: bulk is the
closest we have to an internet standard for “I’ve been sent by a
machine. Machines should not autoreply to me.”
If you need something different, you can modify the Templates on your
system.
-R
Darren,
That’s exactly the issue I’m running into. 
-JasonOn Jun 29, 2004, at 8:44 PM, Darren Nickerson wrote:
On Tue, Jun 29, Jesse Vincent wrote:
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act on
it. Setting the precedence header to “bulk” is a pretty widely honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a
loop.
Not sure if this has been covered yet (I’m a little late to this
thread),
but we’ve had several customers call us complaining that then never
received
correspondence from us. After some digging, it turns out their spam
filters
had interpreted the bulk precedence header as a sure sign that our
correspondence was spam-tastic.
-Darren
The rt-users Archives
RT Developer and Administrator training is coming to LA, DC and
Frankfurt this spring and summer.
http://bestpractical.com/services/training.html
Sign up early, as class space is limited.
Thanks Jesse. This is exactly the information that I needed.
-JasonOn Jun 29, 2004, at 7:44 PM, Jesse Vincent wrote:
On Tue, Jun 29, 2004 at 07:43:10PM -0700, Jason Grigsby wrote:
No. That’s not actually quite right. RT doesn’t respond to incoming
mail with a precendece of bulk. Other than that it continues to act
on
it. Setting the precedence header to “bulk” is a pretty widely
honored
convention for saying "This email message was generated by a machine,
not a human. If you’re a machine (like a vacation autoresponder), you
don’t want to reply to the sender, as you’re likely to generate a
loop.
Jesse, to clarify, are when you say “Other than that it continues to
act on it” are you saying that Alex’s statement that RT will use the
X-RT-Loop-Prevention header is incorrect? Or are you saying that it
doesn’t respond to the messages but it still puts them in the queue?
RT should use the X-RT-Loop-Prevention header to stop RT from talking
to
itself. But ezmlm and your customer’s MTA are broken in such a way that
by catering to them, RT could get itself stuck in a loop with another
poorly behaved MTA.
After some digging, it turns out their spam filters had interpreted
the bulk precedence header as a sure sign that our correspondence was
spam-tastic.
I think I encountered the same problem yesterday. One of our staff
didn’t receive mail from RT any more, and I got bounces (saying the
address didn’t exist!).
His spam filter behaved weirdly, and we had to frob config options at
random to get it to work, so I can’t say for sure that it was the
Precedence header, but it seemed likely to me.
My question: Is there any kind of standards document regarding the
“Precedence: Bulk” convention? This would be great when dealing with
spam filter manufacturers, as I could simply say “your filter is
broken, it’s violating TLA 42” or something like that, rather than
having to argue about the correct interpretation of the Precedence
header.
Sebastian
Sebastian Flothow
sebastian@flothow.de
Because it reverses the logical flow of conversation.