Peter,
We are all in the same boat. The SORBIG-generation eVirus (dual
accept/bounce attacks) was pretty much the last straw and created the
world wide mail anti-virus/spam research movement we have seen since
2003.
My (SSI) initial basic approach to the problem to provide stronger
SMTP level compliancy checks. In other words, I'm with the school of
thought that prefers that you REJECT a transaction as oppose to
ACCEPTING and DISCARDING. It will keep with standards, as well as
some borderline US-EPCA legal provisions, yet, also drastically
minimize the accept/bounce dilemma.
In our AVS system, we have mail filter rules with end results at the
SMTP level
ACCEPT - accept the transaction
REJECT - reject the transaction
KEEP - reject the transaction, keep copy for review
DISCARD - reject, delete it.
There is no there accept without notification concept. If the email
is accepted, it fulfills its responsibility as expected. BOUNCE is
not involved because that need/check was done at SMTP before
acceptance was decided.
The "Give me everything, I will figure it out later, discarding the
ones I don't like" email operational approach is passe and promotes
bad behavior. It is what the bad guy looks for. Once they get they
foot in the door, they really don't care what you do with it. In their
eyes, the email address was GOOD because you accepted it. That
continues to promotes bad behavior.
Of course, this dynamic mode is not for everyone, namely, for many
older setup systems who run accept first operations, generally because
it run large email operations, thus for scalability reasons can't deal
with dynamic mail checking operations. I've always felt that this
dual mode of SMTP was a central difference in the attitudes of many -
it didn't help with the two sides could not work together.
Hopefully, in time, they will move to these high-end dynamic power
mode of operations. Others large systems have made that move because
they have realized the payoff is extremely high. It makes ideas like
ADSP more acceptable.
My view.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Peter P. Benac wrote:
Hector,
Have you ever considered that the " laisez-faire dropping of mail by
operators" as you put it, is done to thwart spammers and email miners? My
system spends a great deal of time sending email to addresses that do not
exist to tell them the system rejected their email. Worse, it sends email
to people whose addresses have been spoofed telling them I rejected email
they never sent. My postmaster account is full of rejects of my rejects.
The whole idea of DKIM is to make email more reliable. If I have my DKIM
set to discardable I really don't want to have to process email telling me
that some spoofer's email was discarded. Why should my resources be used
for such a purpose when I didn't send the original in the first place?
I don't condone the practice of just dropping the mail, but sometimes
"standards" need to catch up with reality.
Regards,
Pete
----
Peter P. Benac, CCNA
Emacolet Networking Services, Inc
Web and Mail Hosting.
Phone: 252-657-9591
Web: http://www.emacolet.com
To have principles...
First have courage.. With principles comes integrity!!!
-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org]
On Behalf Of Hector Santos
Sent: Friday, October 31, 2008 05:18
To: MH Michael Hammer (5304)
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] Q: "dkim=discardable"
MH Michael Hammer (5304) wrote:
I wrote the language in the ADSP draft, and that is what I meant when
I wrote it.
Then you should have wrote what you meant rather than what you wrote
which doesn't match what you now say is the intent. Sometimes semantics
are important.
I have viewed in John's world that DISCARD was 100% about silently
dropping mail with no blow back in a POST SMTP world.
There is a major different between DISCARD and REJECT.
DISCARD helps POST SMTP systems who PER 821/2821/5321 you MUST create
bounces for undeliverable mail. ASDP/DISCARD removes this requirement.
In dynamic SMTP systems, a REJECT does not produce blow back. A REJECT
would be the same as a DISCARD.
The problem with ASDP is that its not cooperative with standard
practice and it will reduce mail delivery reliability and more higher
concern, it further encourages the laisez-faire dropping of mail by
operators.
But I do understand why it was introduced.
IMV, it will only work reliably, meaning no harm in mail lost, in
dynamic SMTP DKIM verification systems - where a dkim verification
DISCARD effectively rejects the transaction at the SMTP level. But
within a SMTP reception/accept first environment with a post SMTP DKIM
verification process, DISCARD promotes mail delivery reliability
problems because it removes the BOUNCE concept.
In that vain, ASDP is BAD for EMAIL.
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops