Jason, have you had a chance to think about this any more? I didn't
see a response, though I could have missed it. (I'm not subscribed to
the list; I just scan the archives now and then).
I'm reasonably convinced that TMDA will have a problem doing SMTP
delivery to any MTA other than qmail; if you disagree with the
analysis I posted in December, I'd be interested to discuss this
further...
-roy
--------------------
From: Roy Badami <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: roy
Subject: Re: User unknown in debug file
Date: Thu, 12 Dec 2002 00:49:32 +0000
"Jason R. Mastaler" <[EMAIL PROTECTED]> writes:
> Could be. Perhaps I should have said non-qmail specific, as qmail
> doesn't have this problem AKAICT.
Hmm, let me check that I'm understaning this right. As I understand
it TMDA by default sends its mail by opening an SMTP connection to the
local mail daemon. So if you're not seeing this problem with qmail,
it sounds like qmail's SMTP listener will accept a RCPT TO command for
a non-existent user in the local domain, and queue the mail anyway
(and then subsequently bounce it).
In general, you should *expect* an SMTP listener to reject the
transaction if it can immediately verify that the address is
undeliverable. Sendmail, postfix and exim all seem to behave this
way.
So I think far from sendmail doing something unusual, I rather suspect
that TMDA is relying on qmail (or perhaps just your qmail
installation) doing something unusual...
> Why won't you see the message in your pending queue? The message is
> written to pending before the auto-response is generated and sent.
Oops, that's just me misunderstanding how TMDA works.
> It is pretty annoying though to have your debug log filled up every
> time a spammer sends a message to [EMAIL PROTECTED]
>
> > IMHO, TMDA should just silently errors such as 550 when sending
> > confirmation requests.
>
> Hmm, this sounds a bit kludgey.
I disagree, though perhaps notifying postmaster of the failed message
might be more traditional. One or other of these two things is
happeneing with qmail, it's just that having accepted the message,
qmail is forced to do the dirty work for you.
Think about what qmail will do once it's accepted your message: it's
got a message to a non-existent local user, that is clearly
undeliverable. The message has a null envelope sender so it can't
bounce it to anyone. Whilst I'm not familiar with qmail, the only
things an MTA can do under these circumstances are to notify the
postmaster, or to silently drop the message.
I would suggest that if a confirmation mail (or any mail with a null
sender) causes a hard (5xx) error, then TMDA should (configurably)
either silently give up on the message, or notify postmaster (or
another specified user). I'd suggest that 'notify postmaster' should
*not* be the default, even though it's arguably the most correct
default behaviour, because it would result in a lot of TMDA users
annoying their local postmasters.
> If there isn't a way to configure around this problem in the MTA,
I'm not sure if there is, but in general, I wouldn't want to even if I
could. It would force my MTA to accept undeliverable mail and then
bounce it back, rather than just rejecting the transaction and letting
the upstream MTA bounce it. Qmail admins may be stuck with this
behaviour, but the rest of us aren't... :)
> perhaps affected users should just set OUTGOINGMAIL = "sendmail".
On the contrary, perhaps users who desire the current behaviour should say
OUTGOINGMAIL = "qmail"
:)
-roy
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
