Yakov Shafranovich wrote:
Alan DeKok wrote:
I've updated the LMAP discussion paper, and put the latest copy on
my web site at:
http://www.striker.ottawa.on.ca/~aland/draft-irtf-asrg-lmap-discussion-00.txt
In case we get SlashDoted, a copy is also available on the ASRG worksite
at:
http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf-asrg-lmap-discussion-00.txt
Some comments on the document:
Please add the following towards the beginning:
NOTE: This document is intended to evolve, based on comments
from the Anti-Spam Research Group (ASRG) mailing list.
It is certain that the current draft is incomplete and
entirely possible that it is inaccurate. Hence, comments
are eagerly sought, preferably in the form of suggested
text changes, and preferably on the ASRG mailing list,
at <asrg(_at_)ietf(_dot_)org>.
NOTE: This protocol is experimental and is not suitable for
wide spread deployment or production use.
Section 1.1:
The policy published by a domain includes statements as to which IP's
are permitted to claim association with the domain in SMTP EHLO/HELO
and MAIL FROM. That policy can request certain decisions to be made
by a recipient on behalf of the domain. For example, "mail from
example.com originates solely from the machine mail.example.com.
Please reject mail allegedly from example.com which originates
elsewhere."
I would also add information here about MTA MARK.
SMTP recipients can look up this policy when a domain name is used in
EHLO/HELO and/or MAIL FROM. The recipient can then choose to apply
the requested policy to the message.
We can also mention that nothing steps someone from checking the LMAP
information against the "From" address inside the actual message body,
resulting in a 5xx code after the DATA command. We should also decide
whether such behavior should be encouraged or discouraged.
Note that recipients should also publish that they use/enforce LMAP.
Receiving mail transport agents using protocols with the ability to
advertise capabilities should advertise a capability to the sender
that informs the that the sender that the receiver will check the
incoming IP address with LMAP.
Have any proposals addressed this? Is this something that should be done
via the SMTP banner, DNS records, or perhaps an ESMTP extension?
2. Problem Statement and Scope
LMAP addresses the problem of forgeries in the argument field of SMTP
EHLO/HELO, and SMTP MAIL FROM. It does not use or examine any other
argument of any other field of the SMTP protocol. Specifically, no
information in the body (DATA portion) of an SMTP message is used in
any part of LMAP. Examination, validation, or verification of the
body "From:" is explicitly not part of this proposal, and this
proposal should not be represented as using body "From:".
But should we encourage such behavior or discourage it? The current text
seems to stay away from the issue.
2.2 Scope of the proposal
> 2.3 Scope of the Problem
Some information should also be added about the MTA MARK proposal. The
entire LMAP idea is about publishing policy decisions on the Internet,
and the MTA MARK proposal does the same for IP addresses, that
RMX/DMP/DRIP/etc. do for domains.
2.3.1 Junk Email
Since this proposal does not examine or verify the body From: field,
there is still the possibility for spammers to use that field to
fraudulently claim assocation with a well-known domain. We leave
that problem to be addressed by a method other than LMAP. We will
recommend, however, that recipients take additional care when
accepting messages where the domain in the envelope MAIL FROM does
not match the domain in the body From:. Such messages have greater
potential to be forgeries than messages where the domains are
identical, and where an accountability system exists.
What kind of care can be taken in this instance? Since the MTA cannot
modify the "From" headers, either a custom header or something in the
"Received" headers should be added?
2.3.2 Viruses, Trojans, and Worms
While many malicious programs sometimes use the infected machine's
sender address, they rarely use the sender domain's resources to send
copies of itself, instead running their own SMTP engines.
Domains implementing LMAP may reject copies of viruses and other
malicious software sent in this manner. This method does have
limitations, however, see also Section 2.4.3.
More text on MTA MARK can be useful here as well.
2.4.1 Junk Email with Correct Envelope Information
LMAP can not stop a spammer from using envelope information that they
are authorized to use. However, maintainers of a spammer's domain
could audit their activity more effectively, as the spammer is forced
to use their correct information.
If spammers maintain their own domains, domain-based blocking becomes
more effective. In extreme cases, where a spammer hosts multiple
domains, blocking the authoritative DNS servers for the spammer's
domains becomes very effective, as the recipient could reject all
LMAP lookups on the spammers' DNS servers. They would effectively
reject all email from domains hosted there.
We have to address the fact that spammers can register new domains much
faster than we can block them. The bit about DNS servers might also be a
bit controversial, since possible fallout can affect others hosted on
the same DNS servers.
2.7 DNS based attacks
You can add a reference here to the draft published by one of the DNS
working groups on the subject, it has an entire list of issues. DNS SEC
can be mentioned as well:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-05.txt
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my
tongue." (MIT's 404 Message)
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg