Re: Why do I get replies to DSNs? (policy response)
D. Stussy wrote:
> On Mon, 1 Jan 2006, jmaimon@xxxxxxxx wrote:
>Which to me means the SPAMMERS - they are the responsible parties. I don't
> have a problem with that. To me, the recipient of a spam is NOT responsible
> for it. The other problem is to have it the other way then fails to notify
> about problems pertaining to legitimate mail.
If you do not operate your system in such a way as to minimize all
possible notifications to abuse, then since you know that the
notifications will most likely be considered abuse in and of
themselves, congratulations, you are the spammer.
> And that's one reason why we still have a spam problem on the Internet.
The only reason we have an abuse problem on the Internet is because its
financialy attractive. IOW people see it. Aggressive filtering that
covers the entire email population will have the side effect of
eliminating the financial incentive to send spam in the first place.
It is not peoples responsibility to track down and shut down entities
on the net who are not abusing them directly or are not abusing other
people with their securable resource.
An email address is not a securable resource.
> I didn't say that you had to be. All it takes is us 0.01% of RESPONSIBLE
> operators to send notices to make the innocent third-parties aware of the
Sending notifications to a destination gleaned from fraudelent abuse is
not responsible behavior.
Notifications to IP addresss abuse contact, that might be.
Those "responsible" systems are sending notification knowing that
nobody (except you) wants them.
> The problem with your attitude is even that is too much. Would you
> rather not deal with even one bounce back to you and have your mailbox banned
> net-wide as a spammer identity, or would you rather want to know that your
> mailbox address was abused and be able to do something about it?
Yes. Because they would not be banning my "mailbox".
They would be pattern matching on my email address. Systems run that
way are irresponsibly run. Email addresses are not a valid source of
information when it comes to blocking or whitelisting. Systems that do
so will get what they deserve when abusers finish their transition to
forging meaningfull names and email addresses, with meaningfull subject
On top of that there is not all that much I could do to prevent my
email address for being seen on incoming abuse in the long run.
> > Non-existent addresses have no standard robust reliable way to be
> > detected upon incoming connections. Non-existent domain names do, but
> > thats not the problem these days.
> Yes, they do. If the domain part of the envelope sender mailbox isn't in DNS,
> or is listed but has no address-type records (including those for any MXs),
> then it is not replyable and needs to be rejected up front.
Used to be an email address did not have to be replyable to be
But I did mention this part.
> Sendmail does
> this. Other MTA programs (e.g. Maillenium) don't. For the username part,
> there are "callback verifiers" that can be employed to validate it.
And thats the part I called non-standard, non-robust and non-reliable.
Besides, your system verifiing that my address is valid before sending
me a notification due to the abuse with my name fraudelently on it is
the actual problem. Common adopting of that mechanism will herd abusers
into using a much higher percentage of real email addresses as their
Thus making the flood of incoming DSN's even worse.
> > <snip>
> Obviously, by the fact that those systems attempted to pass a message on, such
> a message has already passed all their spam checks (if any, and there should be
> some in today's world), so to them, it's not spam.
That can only affect my system decision process if there is some kind
of "trust" that I give to that system. Which isnt the case. Combing
logs show that large percentage of 554 cause the remote end to drop the
connection. Guess those arent legitimate servers.
> Are you saying that any
> mail system today should do MORE than just generate the DSN - especially, it
> should learn from the responses given to it, especially "554 5.7.1 ..."
No, I am saying that If I 554 an incoming connection and the email was
actualy legitimately sent, than the server I 554'd is responsible for
the DSN, and thats a good thing, since it moved the onus for ensuring
that out-of-channel-notifications to abuse be kept to an absolute
minimum to that system instead of mine.
Abuse needs to be detected at the Point Of Entry into the email system.
> responses and consider those to retrain their anti-spam systems? It's exactly
> this sort of thing that caused many "Yahoo groups mailing lists" to be
> classified as spam at larger ISPs such as AT&T (this happened in October 2005).
> [AT&T's system uses user-generated feedback to adjust their filters, but same
Any system that blocks dynamicaly must have an equaly dynamic mechanism
to unblock and permit.
> > If the sending server is not legitimate, than I really dont care what
> > it does so long as I dont generate more abuse in response to it.
> How do you define a "legitimate sending server?"
A server that does its due diligence to ensure that email it sends is
not abuse. In this day and age that means a lot more than five years
> > According to RFC mail from:<> is not to be DSN'd
> But DSNs are SUPPOSED to be sent using "Mail From:<>". Read what I said.
Right, I was saying that systems are not supposed to create a DSN for
email with a return path of <>
> > Back in 1999 notifications that you were sending a virus actually made
> > sense. Now, they just evoke the above sentiment.
> Show me where the standards have actually been changed. They haven't.
Standards may not have changed. However viruses have. They are all
forged return path.
This has been argued extensively everywhere and consensus is not on
All notifications to modern viruses (the only ones actually in the
wild) is completely undefensible.
You want to be a good netizen, notify the abuse contact of the IP
address holder. And dont flood it either.
I know I would appreciate that far more than all the flood of user
complaints "what is this? I didnt send anything? Do I have a virus?" to
which the answer HAS to be "ignore it"
Training users to ignore error messages when far too many of them dont
read them as it is cant be a good side effect of all the "accept,
store, proccess policy, send notification to forged return path" badly
designed email systems.
Sendmail milter systems (the one starting this thread) have absolutely
no need to operate that way and can do all policy checks during the
connection lifetime for nearly all common cases of abuse.
> > These days what possibly would make sense would be a vacation style
> > rate limited notice to the whois found abuse contact of the network
> > address sourcing the abuse.
> Why not just list 0.0.0.0/0 in your IPv4 RBL and be done with it? ;-)
Only 60000 ip addresses in the local self maintaining (virus senders
and spamtrap caught and spam that scores >6 for spamassassin) dns
blocklist. The rest is handled by all the other RBL's
I expect lots of those are systems that sent DSN's in response to
abuse. My heart bleeds for them.
- Re: Why do I get replies to DSNs? (policy response)
- From: jmaimon@xxxxxxxx
- Re: Why do I get replies to DSNs? (policy response)
- Prev by Date: sendmail 8.13.5 + SASL2: using multiple login/passwd sources
- Next by Date: Filtering Bad HELO's
- Previous by thread: Re: Why do I get replies to DSNs? (policy response)
- Next by thread: Re: Why do I get replies to DSNs? (policy response)