Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 3:28 PM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
> On 10/14/2014 12:03 PM, Tanstaafl wrote:
>> On 10/14/2014 11:17 AM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
>>> On 10/14/2014 8:05 AM, Tanstaafl wrote:
>>>> If you think I'm kidding, please by all means go make these silly
>>>> statements on the postfix list and I'll just sit and watch the fun.
>>
>>> You don't read very well. This has nothing to do with emails to a valid
>>> address. A large amount of that spam goes to invalid addresses. I see
>>> them go through the logs regularly.
>>
>> I read fine. The 'silly statements' reference was about your suggestion
>> that it is in any way shape or form 'ok' to *accept* mail to invalid
>> recipients then send it to dev/null.
> But you just said it was OK to delete emails.
Please don't misquote me. I said it was the *worst case*, meaning, only
marginally better than *bouncing* them, which you should never do.
I certainly did not say it was 'OK'.
>>> Wrong. Rejecting garbage sends a message back to the originator,
>> No, it doesn't. It closes the connection with a response code.
<snip>
> I know how it works.
Apparently not, since you keep saying that the RECEIVING server 'sends a
message back to the originator' - unless maybe you simply have a hard
time saying what you really mean, which always causes confusion.
> Now how often do you get an email of 1MB?
Like a large percentage of businesses, we get mail *all the time* that
is many MB's in size. Even all of the freemailers have very large max
sizes they accept now (I think gmail is up to 25MB or 30MB?).
But, I'd say 10-15% of our email traffic consists of messages that are 1MB+
And yes, even lots of spam now has larger attachments (even seen them
over 2MB, though not very often).
>> If I reject the mail at the RCPT-TO stage, then I only accepted a few
>> bytes of traffic before terminating the connection with an SMTP response
>> (error) code. The connecting machine then decides whether to pass the
>> response back or not (again, a few bytes at most).
> That's your option.
No, it is the right thing to do.
>> If you *accept* the mail, then you accepted the entire 1MB of traffic.
>>
>> So, who is responsible for more traffic in such a case?
> Sure.
Thank you for acknowledging that at least this argument in support of
breaking recipient validation (that rejecting emails results in more
traffic than accepting/deleting them) is wrong. We're making progress.
> But spammers don't know whether it is a good address or not.
Nor do they if I reject the transaction way before the RCPT-TO stage,
which postscreen does *very* well, which is what happens most of the time.
Also, my understanding is that there the vast majority of spammers no
longer engage in dictionary attacks to harvest valid email addresses.
> I said NOTHING about security. I just don't want them to know what the
> valid email addresses are.
In my mind saying 'I am doing this because I don't want them to know
what the valid email addresses are' is the exact same thing as saying 'I
am doing this for security purposes.'.
> That way they don't send more SPAM to the good addresses.
It isn't about how much spam is targeted at your users, it is about how
much gets through, and an effective anti-spam solution block 99+% of it
- *without* breaking SMTP. And again, my understanding is that there the
vast majority of spammers no longer engage in dictionary attacks to
harvest valid email addresses, so you are continuing to break smtp for
your users and getting very little to no real world value out of it.
>> Passwords, by their very nature, are intended to be
>> difficult/impossible to 'guess'.
>>
>> To suggest that this is even in the same universe as 'security through
>> obscurity' is ludicrous.
> Then what is that if it isn't "obscurity"?
I didn't say it wasn't 'obscurity', I said it wasn't "*security through
obscurity*". The first is a simple word that has a very broad and
general meaning. The second has a very specific and limited meaning.
>> You don't necessarily need to explictly violate any give RFC to 'break
>> SMTP', Jerry.
>>
>> Breaking recipient validation defacto breaks SMTP. It tells the sending
>> server that everything is OK, when it isn't. It allows someone who
> Tell me what RFC I am violating. Unless I am violating an RFC, there is
> no "breaking" of SMTP.
Objection: asked and answered (see directly above).
>> No one should. What I do care about is if the President of NBC typos an
>> email address to our President when sending an important email, I want
>> him to know the email didn't make it.
> And what if he sends a letter, but misaddresses the letter?
He'll (hopefully) know about it when it gets returned, because his
secretary (hopefully) isn't stupid and puts the correct return address
on it.
>> Please explain what is *Seriously Fraudulent* or *otherwise
>> inappropriate* about a typo in the recipient address of an otherwise
>> perfectly legitimate email, Jerry.
> How many valid emails do you get to a bad email address?
Please answer the question.
> The answer on this end is NONE.
That is *your* answer - but only because you silently delete them, so in
fact, you really don't *know* how many, *because* you silently delete them.
I see them from time to time It isn't a daily thing, but it definitely
happens often enough. I'll get a call from someone occasionally saying
'xyz's emails to me are bouncing (their terminology, they are rejected,
and they get the rejection notice), and when I investigate, it is almost
always because of a typo. Sometimes the message is too big, or even more
rarely it is because their sending server is on a blacklist we use, but
the most common issue by far is a typo.
You never get these complaints because the emails are silently deleted.
> It is a perfect analogy. In both cases the sender misaddressed the
> email or envelope. But there is no guarantee it will be returned to you.
100% guarantee? No. But there is a 99+% guarantee that it will in both
cases, *except* in cases where the mail server is configured to accept
then silently delete them, or the sender of the letter doesn't put the
correct return address on it. In those two cases the sender is 100%
guaranteed to *never* get a notification.
> Once again - point me to the RFC which states this is wrong.
>
> Otherwise, it is just your *opinion*.
And the opinion of 99+% of the people who run the internet - people like
Wietse Venema and all of his peers.
Reply to: