Il 08/10/2010 18:23, Rick Romero ha scritto:
Quoting "Matt Brookings" <m...@inter7.com>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 log.

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
thats true.

That shouldn't be happening. If any one of the recipients is invalid,
the message should be rejected (depending on the bounce/catchall setting
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
are.

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 message.

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.

http://mail.tnpi.net/toaster/?0::11467

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.

Regards,

Tonino




What version of chkuser are you running?

Rick







--
------------------------------------------------------------
        in...@zioni            Interazioni di Antonio Nati
   http://www.interazioni.it      to...@interazioni.it
------------------------------------------------------------


!DSPAM:4caf8e4232712051070742!

Reply via email to