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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com