On Wed, Feb 05, 2003 at 07:00:27PM -0700, Jason R. Mastaler wrote:
>I'm considering a couple of options here.
>
>(1) Document that non-qmail users who experience these problems can
> set OUTGOINGMAIL = 'sendmail' in the .tmda/config which will cause
> TMDA to send mail using the /usr/sbin/sendmail interface rather
> than direct SMTP, thus avoiding the problem.
>
>(2) Provide a configuration option (default is false) which silently
> fails when the SMTP server returns a 5xx reply code. This is
> useful for users who don't run qmail, are unable to use the
> /usr/sbin/sendmail interface, are unable or unwilling to configure
> their MTA around this issue, and are willing to accept the
> possible risks and ramifications of this decision.
>
>Thoughts anyone? I start to get conservative when mail loss is
>possible, so I'm leaning toward option #1.
>
>FWIW, I consider this yet another example of where qmail "does the
>right thing" even though the other MTAs do not.
There seems to be a subsidiary problem that I've encountered related to
this problem. I've switched OUTGOINGMAIL to "sendmail" in order to fix
it, but I thought that the issue should be documented anyway. The problem
is that there seems to be an email that will perpetually get stuck in a
deferred state if a faked sender address from my own domain is used in
a spam.
When I'm at work, I have a "tail -f tmda_incoming.log" running as a
sort of "biff". I know, it's not very effective as such. Whatever.
I happened to see an email come in from "[EMAIL PROTECTED]" to
"[EMAIL PROTECTED]". I ignored it. But then it came in again, and again,
and again. All told it came in 8 times before I started to get curious
as to what the heck was going on.
It turns out that postfix had the one spam stuck in the deferred queue.
I'm just putting together why I think it got stuck. But I think the
reason is that TMDA's failure caused an EX_TEMPFAIL to be percolated up
to postfix causing postfix to try to deliver this email every queue run
only to have the exact same thing happen over and over again.
Here's what I think happens:
1) postfix gets the spam from a non-existant [EMAIL PROTECTED]
address, and attempts to deliver it to [EMAIL PROTECTED]
through procmail.
2) procmail gets the email and sends it to TMDA
3) TMDA gets the email, does not recognize [EMAIL PROTECTED]
and attempts to confirm
4) TMDA connects to localhost:25 and tries to deliver
to [EMAIL PROTECTED] The local postfix knows
that this address doesn't exist, and reples with "550
<[EMAIL PROTECTED]>: User unknown in local recipient
table". This causes TMDA to die with a message in
tmda_debug.log. TMDA may very well die setting EX_TEMPFAIL
(I dunno).
5) procmail sees that tmda died, and sends EX_TEMPFAIL up to
postfix, which keeps the email in the queue... allowing this
process to recycle everytime the queue is run.
I can understand why you'd want this process to repeat if the recipient
account just has some sort of problem, that may eventually get corrected.
But the current setup seems to allow for this particular email (and others
like it) to be recycled perpetually with no hope of ever getting removed
from the deferred queue, because "[EMAIL PROTECTED]" does not exist.
Since, this problem can *only* exist when a faked hornclan.com email
address is in use, I would like to lobby for the #2 option above, since
I'm the one who controls hornclan.com and I don't ever do any of the
things that the earthlink guy described.
Of course, setting OUTGOINGMAIL = "sendmail" also works. I'm just
hesitant to be permanantly precluded from using smtp for OUTGOINGMAIL.
Thoughts?
- Mark
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
