At 10:12 PM 2/24/2005 -0600, Dennis Olvany wrote:
> I'm going to speak in terms of figure 5, becuase figure 3 seems pretty
abstract.
That's OK with me. Let's use the "protocols and services" terminology of
Figure 5, and add the "actors" labels from Figure 3. I will also add some
extra MTAs to the figure, so we can talk about how a spammer might beat the
system. I've shown the spammer as an MTA, rather than an MUA, as that will
give him full control over everything including the envelope
information. Also, I'm assuming the spammer controls all MTAs up to the
point where his message is injected into the normal flow. And to discus
the worst-case scenario, let's assume the spammer knows the likely paths of
normal mail, and can fake their headers with perfection.
+------+
Originator | oMUA |<------------------------------+
+--+---+ |
| {smtp, submission |
Spammer V |
+------+ +------+ |
| MTA | | MSA |<--------------------+ |
+--+---+ +--+---+ | |
| | {smtp | |
| Source V | |
| +------+ /+===+===+\ |
. | MTA | || dsn || |
Relays . +--+---+ \+=======+/ |
. | {smtp ^ ^ |
| . | | |
| Relays . | | |
| . | | |
V V | | |
+------+ +------+ | | |
| MTA |-------->| MTA | | | |
+------+ +--+---+ | | |
Relay Relay | | | |
| | | |
| | | |
Destination V | | |
+------+ | | /+==+==+
| MTA +-------------------+ | || mdn ||
+--+---+ | \+=====+/
| {local, smtp, lmtp | |
V | |
+------+ | |
| +-----------------------+ |
| MDA | |
| |<--------------------+ |
+-+--+-+ | |
local} | | | |
V | | |
+------+ | /+===+===+\ |
| MS-1 | | || sieve || |
+-+--+-+ | \+=======+/ |
| | | {pop, imap ^ |
| V V | |
| +------+ | |
| | MS-2 | | |
| +--+---+ | |
| | {pop, imap, local | |
V V | |
+------+ | |
Recipient | rMUA +------------------------+---------+
+------+
> I'm going to lay down some ground rules for my hypothetical environment.
(MTA also refers to MSAs and MDAs.)
> 1. If a received email does not contain a return-path header, an MTA
should create a return-path header based on the envelope sender.
I'll assume you mean an *authenticated* envelope sender. That would be the
most recent MTA.
> 2. If a received email does contain a return-path header, an MTA should
not alter it or create any additional return-path headers.
Then the trace path is broken, and the IP leading back to the spammer is
lost forever.
> 3. MTAs should send DSNs to the recipient specified in the return-path
header.
Probably forged.
> 4. Forwarders should use the local mailbox as the envelope sender on
forwarded email.
What do forwarders ( relay MTAs) do with bounces if the Return-Path in the
headers is forged?
> Using the above logic, spammers could forge return-path headers all day
long from their MUAs/MSAs and it will cause DSN backscatter,
> but DSN backscatter is not spam. Spammers already cause plenty on DSN
backscatter in this manner, but I don't think spammers would
> be motivated to intentionally fill your inbox with their spam as
DSN-attached files. If DSN-attached SPAM passed SPF at the hop from the MSA,
> then the domain is identifiable.
DSN backscatter will result in strong opposition by companies like
SpamCop. If a standard allows it to happen, you can be sure it will be
heavily abused. How will you know by looking at a long string of headers
that the spam actually "passed SPF at the hop from the MSA"? There
probably is no MSA! All headers below that of the receiving MTA are a pile
of crap.
Seems to me that a complete standard would insist that forwarders pass on
at least the IP address of an incoming mail. I would also add as a MUST,
the authenticated domain name and the result of authentication ( SoftFail,
etc.). Other things like hash codes could be optional. Recipients will
need authenticated domain names to use in spam filtering. They will also
need a standard format for this information, so they can look past the
forwarder's domain name, and filter on the name that the forwarder
authenticated. If I'm using pobox.com as my trusted forwarder on all
incoming email, that's not the name I need my filter to look at.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq at gain.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com