Regarding of failure of delivery due to spam, this is currently what
systems do:
I. Abort during tranmission by giving usually 5xx error message. Often
providing comments as part of 5xx error code on that email is not
accepted because its suspected to be spam.
Topic to work on:
a. Check to see what 5xx messages various systems give.
b. Identify if we need additional 5xx message just for message not
accepted dur to content problems (spam)
c. Identify if we need extended error codes for anti-spam filters and if
so only one or multiple ones
d. Identify if we need to standartize on comments as well (i.e. not
accepted because listed in xxxx blacklist with comments used to
indicate what blacklist in universally accepted format, etc).
II. Return email after it has been scannded by the filter and found to be
unacceptable to system/user.
1. These is what included in return email as far as its original:
a. Only says that particular email (usually identfied by subject) is not
accepted but does not include actual email with it
b. Return email and headers but not content of the email.
c. Return entire email including content
2. What is included in addition to returned email:
a. Return email without any information on why this was done
b. Provide information that email was stopped because its spam with
various levels or reporting up to indicating what exactly is wrong
or what filter was used
c. Return not the email but request for authentication (such website
address where only human would be able to authenicate) so that
sender's email address is added to some kind of whitelist
3. There several addesses used for returning email:
a. MAIL-FROM - most use this and this is appropriate
b. "From:" - used by some filters that do not see MAIL-FROM or for some
reason choose to ignore it
c. "Reply-To:". Same as above, but this is rare
d. Send email (even returned ones) to
domain(_dot_)com(_at_)abuse(_dot_)net(_dot_) Not recommended
for automated system to do this, but some users configure that anyway.
But this is done in part because of in many spam emails "MAIL-FROM" is
invalid and automated system does need some valid email address to
return to.
4. Topics to work on:
a. What possible formats are used for returning email
b. Should we standartize format
c. If standardize what options as far as what information is included
d. Need to discuss regarding return email address in particular due to
spammers using invalid mail form and arrive at standards on what
email address is to be used for unaccepted spam emails
e. For requests for authentication, should we standartize that? Is that
possible? How?
Please comment on anything above.
On Mon, 24 Mar 2003, Paul Judge wrote:
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
-----Part 1. Understanding the Problem:
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
-----Part 2. Propose Solutions:
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
-----Part 3. Evaluate Solutions:
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg