ietf-mxcomp
[Top] [All Lists]

RE: DEPLOY: Legal liability for creating bounces from forged messages

2004-08-24 14:00:55

From: Jim Lyon
Sent: August 24, 2004 2:54 PM

A reasonable use of SenderID is to use it at SMTP time, and
to refuse to accept forged mail.  If you refuse to accept
it (by giving an error at end of DATA), you won't generate
a bounce.  

The MTA that was sending the mail might or might not
generate a bounce, but that's his problem, not yours.

In fact, most of the forged mail is sent by specialized
spam engines or virus propagation engines.  These engines
won't generate bounces, they'll just give up and go on to
the next victim.

A number of issues:

* Your position presumes wide spread implementation of
Submitter, allowing for extraction of the PRD at the data
stage.

* Until this happens, as Sender-ID is presently drafted,
the receiving MTA has to 'swallow' the message and extract
the PRA from the headers. As has been previously stated
this leads to a greater risk of false positives.

* Sender-ID does not call for SMTP mail from checks at the
DATA stage in the absence of PRA. If you are suggesting
either amending Sender-ID or preparing a BCP document to
suggest that receivers do carry out SMTP mail from checks
at the DATA stage in the absence of PRA, I would whole
heartedly support this.

* I am concerned about the suggestion that:

If you refuse to accept it (by giving an error at end of
DATA), you won't generate a bounce.

I agree if there is no domain found in either Submitter or
SMTP mail from this may be appropriate. However, the
appropriate 55x error message must be generated, so that
legitimate senders with mis-configured mail servers can
rectify the situation. 

Also, in the event of Submitter or SMTP mail from spoofing,
again it is important to generate the appropriate 55x error
message, so that legitimate senders with mis-configured
email policy records can sort out the problems.

There is no love lost for forged headers. At the same time,
I suggest we need to take care not to throw out senders who
are endeavouring to comply but for some reason are using
mis-configured mail servers, who have made errors in
publishing their email policy records, or who have failed
to update their email policy records as a result of system
changes.

Finally you write:

In fact, most of the forged mail is sent by specialized
spam engines or virus propagation engines.  These engines
won't generate bounces, they'll just give up and go on to
the next victim.

My understanding is different. Apparently according to
published reports earlier this summer between 60 to 80% of
UBE is now sent by spammers accessing zombie computers on
infected networks. The use of specialized spam engines is
apparently no longer the spammer's weapon of choice.

(See in particular comments made by Stephen Linford in June
at an anti spam conference in London, England, along with
an article published by Tom Donnelly through Circle-ID.)

Recent reports indicate less than 1% of all filtered email
is CAN SPAM compliant. This leads me to believe most UBE
coming from zombie computers uses forged return paths.
Anecdotal evidence seems to confirm this understanding. 

Therefore I am not sure the conclusion you reach is correct.

Having said all of this, from my personal perspective,
having made a fuss about the license, I am satisfied with
the IPR statement given the representations made by MS in
the FAQ and the form of license. 

Others will strongly disagree and let the discussion
continue.

From my perspective, the core issues involve technical
concerns surrounding the need to protect the return path
and related deployment concerns arising from the failure to
protect the return path against spoofing or fraud in
Sender-ID.

Having said this I acknowledge the Sender-ID specifications
does not focus on these issues. 

I have previously stated these concerns can be resolved
through the use of a Best Current Practices document.

For more on this, see my earlier discussions in the threads
What Meng Said, Point of Order, Incomplete Flawed Response
to MARID WG Charter and Forged Sender (Resent From Attacks).

Unless this 'circle is squared' Sender-ID will in my view
continue to meet with opposition in the open source
community as it compels software developers to utilize the
PRA algorithm. 

I don't know whether this will ultimately result in the WG
rejecting Sender-ID. But I strongly believe without
resolution it will ultimately result in an attitude of two
solitudes between those supporting Sender-ID and those
supporting SPF.

I come from a country which has dealt with the problem of
two solitudes existing between founding national groups for
over 100 years. This has lead to the development of a
confederation which allows for co-existence of diverse
ethnic groups within one nation state.

This WG is essentially confronted with the same reality.
There is not just one way of dealing with sender
authentication.

It would be tragic if this WG was to ignore the underlying
problems now facing implementation of sender authentication
given the developing split between the SPF and Sender-ID
communities.

This is also why I support the CSV proposal.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004