Re: Recipient validation - WAS: Re: Moderated posts?
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.
>>>> To bounce all of those invalid addresses not only would further
>>>> increase the amount of junk on the internet,
>
>>> That is pure and absolute nonsense. The vast majority of spam comes from
>>> botnets, and *rejecting* garbage from these results in ZERO additional
>>> smtp traffic.
>
>> Wrong. Rejecting garbage sends a message back to the originator,
>
> No, it doesn't. It closes the connection with a response code.
>
> The system that had opened the connection and was attempting to send the
> email is the one responsible for 'sending a message back to the originator'.
>
> Well, *if* the system talking to your server is the originating server,
> that is.
>
> If, on the other hand, there were relays involvbed, then it would simply
> relay the response code back down the chain until it got to the
> originating server.
>
> This is very simple to validate. I suggest you do so before compounding
> your error in public.
>
I know how it works. And it all depends on when the message is rejected
- if it is rejected. Accepting it and deleting it adds no extra
overhead to the network.
>> increasing the traffic. Simply dropping them, as I do, does not.
>
> Given an identical mail transaction, with an email with a size of 1MB:
>
Now how often do you get an email of 1MB?
> 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.
> 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. But spammers don't know whether it is a good address or not.
>>>> but by not replying, servers tell the spammers what are valid email
>>>> addresses.
>
>>> More nonsense. Security through obscurity *never* works, and only, in
>>> this case totally breaks SMTP.
>
>> Wrong on two counts. First of all, the false notion "Security through
>> obscurity *never* works". This has nothing to do with security.
>
> You said you were concerned about telling spammers valid emails. Why are
> you concerned about that if not from a security perspective?
>
I said NOTHING about security. I just don't want them to know what the
valid email addresses are. That way they don't send more SPAM to the
good addresses.
Security is not a problem. People log in to their mailboxes with ids
that are not necessarily the same as their email address.
>> And BTW, that statement is also wrong - why do you think people are
>> encouraged to use obscure passwords if it doesn't work? But that's
>> another subject.
>
> Lol! Not even in the same ballpark, Jerry. 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"?
>> On the second count - please point out exactly which RFC I am violating
>> that "breaks SMTP".
>
> 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.
>>>> Finally, as for "...undermine confidence in the reliability of the
>>>> Internet's mail systems..." - it hasn't been reliable since spammers
>>>> virtually took over the email. And even when emails were rejected, it
>>>> still was no indication the recipient got the message.
>>>
>>> Of course it wasn't, but it was certainly a positive indication that the
>>> recipient did *not* receive it (as long as the sending server is
>>> properly configured).
>
>> And why should I care if a bot finds out the message has not been received?
>
> 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?
>>>> BTW - by definition, any messages to any of the domains I manage without
>>>> a valid email address are "seriously fraudulent or otherwise inappropriate".
>>>>
>>> Really?
>>
>> Yes
>>
>>> So when the President/CEO of XYZ Corporation, who does business with a
>>> customer whose domain happens to be managed by you, accidentally typos
>>> an email address, you consider that a 'seriously fraudulent or otherwise
>>> inappropriate' email?
>
>> Yes.
>
> 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? The answer on
this end is NONE.
>> Just like a misaddressed letter at the post office. It will not
>> necessarily be returned.
>
> While not a perfect analogy (big difference between totally automated
> systems and systems that have imperfect humans (postoffice workers) in
> the mix), it is still generally wrong.
>
> I have had more than one letter/package returned because it was
> misaddressed in my lifetime - but of course, this does require that you
> actually put a valid return address on it. But I guess maybe you are
> against that too?
>
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.
>>> You must not have any real commercial customers, because I would imagine
>>> you would be a prime target for lawsuits for losing emails like this, as
>>> it would only be a matter of time before it was something important sent
>>> by someone important to someone else important.
>
>> I have enough, and there are no valid emails lost.
>
> And you know this because you check every single email that you 'drop'
> to make sure it wasn't a legitimate email with a typo in the recipient
> address?
>
> You have lost all credibility with me Jerry.
>
I know because I can tell what the attempted email addresses are.
>>> That said, I do have an email template I send to our users regularly
>>> explaining why/how email should never be considered 100% reliable, and
>>> if they ever send an email that has money riding on it being received,
>>> they should follow it up with a phone call to make sure it actually was
>>> received. I guess people like you are one of the reasons I have that
>>> template and need to send it out on occasion.
>
>> Ah, so even you admit email is not reliable.
>
> Of course... mostly due to people who mis-configure servers, either
> accidentally, through ignorance, or even intentionally (like you are
> advocating).
>
And even if they are configured correctly, email can get lost.
Once again - point me to the RFC which states this is wrong.
>> If it were, why would you encourage your people to follow up with a
>> phone call? After all, if they didn't get a reject message, the email
>> MUST have gone through.
>
> Again - because:
>
> a) mistakes happen, and
> b) because of people like *you*...
>
>
Once again - point me to the RFC which states this is wrong.
Otherwise, it is just your *opinion*.
Jerry
Reply to: