Il 08/10/2010 18:23, Rick Romero ha scritto:
Quoting "Matt Brookings" <m...@inter7.com>:
-----BEGIN PGP SIGNED MESSAGE-----
On 10/08/2010 11:05 AM, Eric Shubert wrote:
U. George wrote:
It is not clear to me if the same message is sent to multiple users,
or multiple messages to multiple users using the same smtp session.
I don't recall ever seeing multiple messages using the same smtp
session. I presume it can be done simply by following the . (ending one
message) with another "MAIL FROM" command and proceeding with another
message. I just haven't ever (in 4 years of using QMT) seen it in a
BUT, I think, if the *last* email rcpt is legit, then the message is
passed along to that legit account irrespective of any any failures
that happened before. I will have to review the mail log to see if
That shouldn't be happening. If any one of the recipients is invalid,
the message should be rejected (depending on the bounce/catchall
of course). Someone please correct me if I'm wrong on this.
I will have to log the smtpd session to see what the actual conditions
Please let us know what you determine. Inquiring minds want to know. ;)
A receiving SMTP server that is doing recipient validation for a
single message has no reason to reject an entire message simply
because a single RCPT command failed. If there are three RCPT
commands, two fail, one succeeds, and the sending server continues
sending, the single recipient that was accepted will receive the
The sending server may choose to handle the RCPT failure however it
wants, but a receiving server should not reject a DATA command unless
there are no recipients to deliver to (or other protocol errors).
There was actually a 'bug' in an older chkuser that did the exact same
thing with Hotmail. If you received an email from Hotmail, with two
recipients and one was invalid, the error code chkuser spat out was
interpreted literally by Hotmail as a full failure and not a user
failure and Hotmail would bounce the entire message to the sender.
I debugged the whole thing only to have Tonix wake up in Italy and say
'yeah, upgrade to the latest version' :)
Yes, at that time return code were not exact, and after a lot of
studying and suggestions, chkuser was upgraded (just a few before your
problem) to use right codes.
But problem was mainly with e-mail clients, not with SMTP servers.
As far as I could see, a good SMTP sending server manage each recipient
falure alone, without causing other good recipients not to be delivered.
And this happened despite of exact return codes.
Instead clients are more troublesome, and the most of times stop sending
as they have the first error, and do not complete the delivery. Correct
error codes help handling that, but do not improve situation. If I
remember well, Outlook creates an (fake) return error message for wrong
recipients and sends to all right recipients, but other e-mail clients
(like Eudora at that time) stop sending at first error, just because
recipient is not existing.
In my environment, for my authenticated customers, I disable chkuser, so
even if they send a message to a wrong local recipient, message is
accepted, and followed later by a bounce message. Just to semplify life
to e-mail clients.
For public MX, instead, rejecting is active, because I expect to talk
with servers only.
This is not, anyway a chkuser problem, but a general behaviour.
Unique case in which chkuser plays "dirty" to senders, is when intrusion
thresholds are hit, but in that case you see it clearly in logs.
In George's case, I've the suspect sender was not a server, but a normal
client or a bad working smtp engine for spam.
What version of chkuser are you running?
in...@zioni Interazioni di Antonio Nati