[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-05 10:49:49

Sabahattin Gucukoglu wrote:
Hi all,

Before this discussion goes further, I want to just get this bit sorted out, just in case people don't see a relationship between the two contenders in this dilema (as indicated in the Subject line) ...

On Fri, 02 May 2008 05:11:33 -0400, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Sabahattin Gucukoglu wrote:
1. I am naive enough to receive mail from non-verifiable senders.
Yes. <g>

To be sure, it sounds like the right thing to do. As yet, though, there's no justification in doing it other than that queue clogging will often result if you don't.

Well, I don't see that as the key reason. It just a matter of checking the SMTP client. By our last 2006 site specific stats, rejection breakdown was:

As the transaction proceeds at each state (We check RCPT before MAIL first):

    31% EHLO/HELO, Bad Invalid Syntax, Format
    43% MAIL FROM, Delayed Sender Verification

        17% Internal Local Rules/blocks
        52% DNS RBL
         2% SPF
        29% CBV (CallBack Verification)

    34% RCPT TO, Bad Recipients
    37% DATA, Sysop defined Mail Content Local Rules

For DATA, in our specific site case, we have a simple "Bad Words" filter list. Nothing fancy.

For local recipients tranactions, one of the benefits is no bounces.

If you are hosting and relaying mail, you can reduce bounces as well, but you can still get them because you don't know if the forwarding path is acceptable until its actually processed.

Is it *semantically* correct to reject mail just because bounces for the sender are undeliverable?

IMO, since it is a SMTP requirement for the return path to be valid, it would be more than semantically correct and IMO, a reasonable justification for verification.

The question is when do you think it to be valid? Before acceptance or after acceptance? or only when its needed? The latter seems to be modus operandi of most systems and they are the ones that typically suffer the most (or bare the blunt of the issue), and because of that they are usually the ones with the most undelivered mail scenarios. i.e, they will discard mail. IMO, the systems that accept all mail before they check it are usually the ones with debatable issues.

If it isn't, fine - let's get to work on standardising a way for domains to indicate that they don't want mail, and they'll live happily ever afterward not knowing that mail they originated (or not, but that's irrelevant) didn't get through. We can try and fail to deliver our DSNs straight away, keep backup MXs working without fuss, etc, etc, and still have nice, clean queues without going to extraordinary, expensive lengths to verify sender addresses.

I don't follow this and the rest of your statements.


Hector Santos, CTO