Re: MTAs denying messages (was: Re: Moderated posts?)
On Mon, Oct 13, 2014 at 9:24 AM, lee <lee@yagibdah.de> wrote:
> Joel Rees <joel.rees@gmail.com> writes:
>
>> (But in this case, absolutely requiring a response would be building a
>> DOS and potential privacy vulnerability into the message
>> infrastructure. The RFCs really should be stored with a summary of
>> relevant comments.)
>
> Could you explain how an MTA would create a privacy vulnerability or
> expose itself to DOS attacks by not accepting messages?
>
> For example, my MTA does not accept messages that have an empty Subject:
> header. How does that expose my privacy or allow for DOS attacks?
Somebody mentioned both the problem and the usual solution later in
the thread, but, laying it out in more detail:
I have an e-mail address my ISP gave me. Back almost twenty years ago,
when the internet was still a bit safe for naive use, I put my
isp-provided e-mail address in my home page. For the last fifteen
years, I've had to periodically clear that mailbox of junkmail, a
thousand in a week at the worst times, down to about a hundred a week
now.
I'd change the address, but a junkmail magnet is actually an
interesting resource.
Every now and then, I still get a spate of junkmail there, where the
to: field has a long list of semi-random names@isp.tld . I know those
names are bogus because I know there are not that many users at this
isp who have registered themselves with English names. Rather amusing.
What are the junkmailers doing? Shotgun mailing the isp with possible
user names.
If the isp responds with a code that says my user-id is valid, the
junk mailer knows he has a live address.
If the isp responds to the bad ones with an invalid user-id code, any
user-id that doesn't get that response is assumed live. There's your
privacy problem.
If the isp accepts the message without acknowledging the existence of
the user id, and then later sends an undelivered message, that's still
revealing what user-ids in the random attack were valid, and it also
amplifies the attack -- backscatter. Wikipedia's current article is
fairly informative, check the references, too.
http://en.wikipedia.org/wiki/Backscatter_%28email%29
If the sending box is a bot, it will disappear by the time a delayed
rejection message is sent, which will cause a host-not-found message
from somewhere. This also amplifies traffic.
There have been several relatively well-known cases where this kind of
opportunistic junkmail temporarily took an isp off the network.
Searching the web for such things as "backscatter spam" should get you
more information.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: