Yet another question regarding Autoreply =]
I’m having some issues with autoreply loops.
Last night someone sent a message from an account that was being serviced by
an autoresponder, (a notification of email-address change), when rt sent the
autoreply back to this address, the remote autoresponder sent another message
(not a reply but a completely new message) thus causing a never ending loop.
Has anyone else encountered anything similar if so how did you solve it?
If anyone has any suggestions I would love to hear them.
I’m hoping to solve this problem I won’t have to disable the autoreply.
Also on another note but unrelated.
RT is setting the Return-Path: header to mydomain.com@mail.mydomain.com
Is there a reason for this? (is it setting it to an address it thinks should
be nonexistant?)
Thanks to everyone in advance,
-Michael
Hi
I think the solution is easy on SMTP-level, but I have no idea how to
fix it in RT codebase.
Autoresponders normally insert special MIME headers in their messages,
just view them
in your example and subsequently filter mails with these headers.
Example: use “X-Mailer” and “Precedence”
The big problem might be, that not all autoresponders use the same
signature of MIME-headers…
:-/
Manfred
Michael Grubb wrote:
Yet another question regarding Autoreply =]
I’m having some issues with autoreply loops.
Last night someone sent a message from an account that was being serviced by
an autoresponder, (a notification of email-address change), when rt sent the
autoreply back to this address, the remote autoresponder sent another message
(not a reply but a completely new message) thus causing a never ending loop.
Has anyone else encountered anything similar if so how did you solve it?
If anyone has any suggestions I would love to hear them.
I’m hoping to solve this problem I won’t have to disable the autoreply.
Also on another note but unrelated.
RT is setting the Return-Path: header to mydomain.com@mail.mydomain.com
Is there a reason for this? (is it setting it to an address it thinks should
be nonexistant?)
Thanks to everyone in advance,
-Michael
EMail: Manfred.Bathelt@epost.de
Michael Grubb wrote:
Last night someone sent a message from an account that was being serviced by
an autoresponder, (a notification of email-address change), when rt sent the
autoreply back to this address, the remote autoresponder sent another message
(not a reply but a completely new message) thus causing a never ending loop.
Has anyone else encountered anything similar if so how did you solve it?
If anyone has any suggestions I would love to hear them.
http://www.fsck.com/pub/rt/contrib/2.0/UpdateSquelch/
http://www.amsterdamned.org/~bc/rt/AutoReplySquelch.tgz
(Jesse, AutoReplySquelch still seems to be absent from contrib/2.0)
Also on another note but unrelated.
RT is setting the Return-Path: header to mydomain.com@mail.mydomain.com
Is there a reason for this? (is it setting it to an address it thinks should
be nonexistant?)
I’m guessing this is a local configuration issue, possibly either
the queue’s email address (Configuration->Queues->queuename) or
CorrespondAddress (and/or CommentAddress) in your config.pm.
Manfred Bathelt wrote:
The big problem might be, that not all autoresponders use the same
signature of MIME-headers…
It’s nothing to do with MIME and everything to do with
Precedence: bulk
which waaay too many autoresponders neither set nor honour.
“MB” == Manfred Bathelt Manfred.Bathelt@epost.de writes:
MB> I think the solution is easy on SMTP-level, but I have no idea how to
MB> fix it in RT codebase.
MB> Autoresponders normally insert special MIME headers in their messages,
MB> just view them
I’ve had my fair share of autoresponder wars from running various
services over the years. The only way to block this is to have a
per-address database of responses sent during the last X days (or
hours or whatever) and not respond to any address in that list.
We usually build our autoresponders to scan this list and purge old
addresses prior to checking for the existence of the current target.
In RT, I could see this as a config variable (say
$autoRespondBlackoutTime) and a per-queue list of of addresses that
have gotten an autoresponse and the time they got it. If they send
another message that triggers an autoresponder within
$autoRespondBlackoutTime amount of time to that queue, they don’t get
the response. I’d set that time at something like 30 minutes.
Vivek Khera wrote:
In RT, I could see this as a config variable (say
$autoRespondBlackoutTime) and a per-queue list of of addresses that
have gotten an autoresponse and the time they got it. If they send
another message that triggers an autoresponder within
$autoRespondBlackoutTime amount of time to that queue, they don’t get
the response. I’d set that time at something like 30 minutes.
Or you could use Bruce’s excellent AutoReplySquelch/UpdateSquelch
scrip pair to accomplish the same thing. See contrib/2.0. 