spf-discuss
[Top] [All Lists]

Re: SRS and Stuff

2005-02-25 14:11:12
Try wrapping it with <PRE></PRE>

Terry

David MacQuigg wrote:

I just looked at this message in the list archive, and it looks like the formatting of the figure is unrecoverable!! It looks OK if you are on the mailing list and viewing your own fresh copy, but you won't be able to follow this discussion by viewing the archives. I'll try some HTML codes around the figure. Does anyone have a suggestion?

Here is the last post again:

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.

<pre>
                        +------+
             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 +------------------------+---------+
                     +------+
</pre>


> 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
------------------------------------------------------------------------
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


--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

-------
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
<Prev in Thread] Current Thread [Next in Thread>