Mailing List Archive

David MacQuigg wrote:

> Is this a good model, or at least good enough that we can
> use it as a basis for simple discussions, and clarify when
> we need to add something?

Let's stick to the existing terminology, as you have noted
there's one special case where we use "forward" as shorthand.

The "border" enters the picture when an MTA on the side of
the sender figures out that a mail is not "local" and has
to be forwarded / relayed / sent to a third party. For that
job a border MTA on the side of the sender (not necessarily
the MSA, it could be behind the MSA) has to query=mx, with
an address fallback where query=mx yields nothing. It then
finds a working MTA on the side of the receiver.

The border MTA on the side of the receiver has to decide if
it accepts or rejects the mail. After that decision it can
do whatever it needs to do to deliver the mail in its "own"
receiving network. That can include forwarding / relaying /
sending from secondary to primary MX, and the secondary MX
can be a backup MX elsewhere, but as far as "sender policy"
is concerned it did its job at te border, SPF doesn't (and
can't) worry about whatever the receiver does to deliver an
accepted mail. The receiver can even "bounce later" if an
accepted PASS goes to e.g. a mailbox over quota.

Things the receiver can do includes to resolve aliases, and
if these are local aliases "change RCPT TO, keep MAIL FROM"
can't cause havoc, IOW the receiver only needs to make sure
to check SPF once, at the border, that's fairly simple.

An MTA on the side of the receiver can find that an RCPT TO
is a mailing list, it then replaces the MAIL FROM with its
own list-bounce address, maybe it manipulates the header by
adding a corresponding Sender (for PRA, or just anyway), and
then sends / forwards the mail to the various list members.
Also no problem for SPF (but maybe a problem for PRA).

And the last case, that's what we are talking about here, is
a non-local alias, where the receiver changes RCPT TO a 3rd
party, and forwards the mail across a *second* border, again
coupled with query=mx etc. as at the first border. Because
this is a third party it can normally check SPF again, and
for an unmodified MAIL FROM this either FAILs, or at least
it can't PASS.

After that the game can simply repeat, but for SPF it won't
introduce new cases. Typically when we talk about "forward"
it's the one and only interesting case for SPF, "forward to
third party". We ignore cases where MAIL FROM is adjusted
(as for mailing lists), that's good enough for SPF (not for
PRA, but here is not senderid.discuss :-) We also ignore
cases where a new RCPT TO is a local alias, as that doesn't
cross another border where it could cause havoc.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84582080-b806b8
Powered by Listbox: http://www.listbox.com

Frank Ellermann wrote:
> And the last case, that's what we are talking about here, is
> a non-local alias, where the receiver changes RCPT TO a 3rd
> party, and forwards the mail across a *second* border, again
> coupled with query=mx etc. as at the first border. Because
> this is a third party it can normally check SPF again, and
> for an unmodified MAIL FROM this either FAILs, or at least
> it can't PASS.

That's what Frank softly called "the odd 5.3.6(a) loophole",
after rfc 1123 section numbering; see
http://www.gossamer-threads.com/lists/spf/discuss/32901#32901

For terminology, perhaps we may call it the odd _SMTP_ loophole,
since rfc 2821 still encourages vanilla forwarding (although it
also says that "any further (forwarding, gateway, or relay)
systems MAY remove the return path and rebuild the MAIL command
as needed".)

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84617984-37da0e
Powered by Listbox: http://www.listbox.com

On Jan 10, 2008 11:18 AM, David MacQuigg <dmquigg-spf@yahoo.com> wrote:

> At 11:05 AM 1/10/2008 -0500, Stuart wrote:
> >>
> >> C: MAIL FROM:<bla@example.com> AUTH=forwarder.org
> >
> >You would want
> >
> >C: MAIL FROM:<bla@example.com> AUTH=mailbox@forwarder.org
> >
> >A receiver might want to whitelist only selected mailboxes at
> >a forwarder (e.g. their own).
>
> You must mean a *recipient* might want to whitelist only their own
> mailbox. Receivers are often unaware of the forwarding arrangements made by
> recipients.
>
> I wish we had a shared terminology for the various entities in an
> exchange. From this and other recent discussions on this list, I'm trying
> to build a mental picture of how this group views the transfer of a typical
> email. Is this a good picture:
>
> Sender --> Relay --> /Border/ --> Forwarder(s) --> Receiver --> Recipient
>
> I'm following Julian's use of "Relay" to distinguish an MTA on the
> Sender's side from the "Forwarder(s)" on the Recipient's side. I have
> included the possibility of multiple Forwarders, but only one Relay,
> assuming any MTA's closer to the Sender really *belong* to the Sender, and
> don't add anything useful to the picture.
>
> Is this a good model, or at least good enough that we can use it as a
> basis for simple discussions, and clarify when we need to add something?


I like this diagram. It will certainly help clarify our discussion on using
HELO names. As I understand it, the objection was that Relays often handle
mail for multiple Senders, and we want to authenticate the Sender, not the
Relay. I suggest we include multiple Sender(s) in the diagram.

On Jan 10, 2008 9:54 PM, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
And the last case, that's what we are talking about here, is
a non-local alias, where the receiver changes RCPT TO a 3rd
party, and forwards the mail across a *second* border, again
coupled with query=mx etc. as at the first border. Because
this is a third party it can normally check SPF again, and
for an unmodified

Should we show multiple Border(s)?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84752379-1c01d1
Powered by Listbox: http://www.listbox.com

At 08:56 AM 1/11/2008 -0700, Edmig wrote:
>On Jan 10, 2008 11:18 AM, David MacQuigg <<mailto:dmquigg-spf@yahoo.com>dmquigg-spf@yahoo.com> wrote:
>>At 11:05 AM 1/10/2008 -0500, Stuart wrote:
>>>>
>>>> C: MAIL FROM:<<mailto:bla@example.com>bla@example.com> AUTH=<http://forwarder.org>forwarder.org
>>>
>>>You would want
>>>
>>>C: MAIL FROM:<<mailto:bla@example.com>bla@example.com> AUTH=<mailto:mailbox@forwarder.org>mailbox@forwarder.org
>>>
>>>A receiver might want to whitelist only selected mailboxes at
>>>a forwarder (e.g. their own).
>>
>>You must mean a *recipient* might want to whitelist only their own mailbox. Receivers are often unaware of the forwarding arrangements made by recipients.
>>
>>I wish we had a shared terminology for the various entities in an exchange. From this and other recent discussions on this list, I'm trying to build a mental picture of how this group views the transfer of a typical email. Is this a good picture:
>>
>>Sender --> Relay --> /Border/ --> Forwarder(s) --> Receiver --> Recipient
>>
>>I'm following Julian's use of "Relay" to distinguish an MTA on the Sender's side from the "Forwarder(s)" on the Recipient's side. I have included the possibility of multiple Forwarders, but only one Relay, assuming any MTA's closer to the Sender really *belong* to the Sender, and don't add anything useful to the picture.
>>
>>Is this a good model, or at least good enough that we can use it as a basis for simple discussions, and clarify when we need to add something?
>
>I like this diagram. It will certainly help clarify our discussion on using HELO names. As I understand it, the objection was that Relays often handle mail for multiple Senders, and we want to authenticate the Sender, not the Relay. I suggest we include multiple Sender(s) in the diagram.

Good suggestion. This does not add complexity to the diagram, and does capture an essential part of what we are discussing.

>On Jan 10, 2008 9:54 PM, Frank Ellermann <<mailto:nobody@xyzzy.claranet.de>nobody@xyzzy.claranet.de> wrote:
>>And the last case, that's what we are talking about here, is
>>a non-local alias, where the receiver changes RCPT TO a 3rd
>>party, and forwards the mail across a *second* border, again
>>coupled with query=mx etc. as at the first border. Because
>>this is a third party it can normally check SPF again, and
>>for an unmodified
>
>Should we show multiple Border(s)?

The *Border* in my definition is the one place where there is no relationship between sender and receiver. I would leave these other boundaries out of the basic diagram, and add them as needed for a specific discussion. We need to keep the basic diagram simple.

The same reasoning applies to "backup MX's" and other alternate paths that the mail might flow. Showing all these possibilities could make the diagram much more complex, and less useful for communicating with non-experts.

I'm still concerned that we don't have agreement on basic terminology. Without that we can't have a productive discussion.

At 05:54 AM 1/11/2008 +0100, Frank wrote:
>Let's stick to the existing terminology,

The problem with existing terminology is that there are too many words for each thing or action (e.g. your use in several places of the awkward phrase "forwarded / relayed / sent" ) and too many different things using each word (e.g. "sender"). We should either agree on a distinction between "relay" and "forwarder", or a use more awkward, but complete phrase, like "border MTA on the sender's side", or use a new term that doesn't conflict with anything already in use, perhaps an invented acronym BMoSS.

I like the word "transmitter" to designate the border MTA on the sender's side - no conflict with existing email terms, and an appropriate analogy with its more common use in radio and TV broadcasting. It is unlikely to generate confusion, even for people coming into the middle of a discussion. See http://open-mail.org/3strikes/QnA.html for more on email "transmitters".

Other _terms_ that I see causing a problem in communication include:
>After that decision it can do whatever it needs to do to deliver
>the mail in its "own" _receiving network_.

I assume _receiving network_ includes everything on the receiver's side, from the Border MTA to the final MDA. Although there are _secondary borders_ within this network, there is at least an indirect relationship between the parties, e.g. a Forwarder has a direct relationship with a Recipient, who also has a direct relationship with the Receiver, thereby forming an indirect relationship between the Forwarder and Receiver, and putting the burden on the Recipient to make sure mail flows smoothly between *his* Forwarder and *his* Receiver.

>the _receiver_ only needs to make sure to check SPF once, at the border,

We have a conflict here in the use of the word _receiver_. Should I change the diagram, use a different word, or what?

How about this for rev 2 of our basic Mail-Handling System:

/
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
/
Border

-- Dave





-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85055378-efe5cb
Powered by Listbox: http://www.listbox.com

David MacQuigg wrote:

>> Should we show multiple Border(s)?

For an "interesting" scenario wrt MAIL FROM you need two.

> We need to keep the basic diagram simple.

Depends on what you want to focus on, or if you intend to
use the same diagram for anything that's relevant for SPF,
PRA, DKIM, SSP, and BATV.

> Showing all these possibilities could make the diagram
> much more complex, and less useful for communicating
> with non-experts.

Don't use Dave's mail-arch diagram for SPF, it won't help
you, it has a completely othogonal view of "border" based
on different admins who can change things in their "ADMD".
And it's fairly complex.

> I'm still concerned that we don't have agreement on basic
> terminology. Without that we can't have a productive
> discussion.

That's at it is. The top-IETF experts supposed to know
what a mailing-list is have completely different ideas -
e.g. 2821bis + 2822upd don't justify to add Sender header
fields (more precisely they forbid it), nevertheless many
lists do something in this direction.

> The problem with existing terminology is that there are
> too many words for each thing or action (e.g. your use
> in several places of the awkward phrase "forwarded /
> relayed / sent" ) and too many different things using
> each word (e.g. "sender").

Yeah, the "forward / relay / send" was intentional, and I
forgot "transmit" among others :-) The "mail-arch" draft
and 2821bis *try* to offer some clearer terms, e.g. the
word "bounce" in 2821bis never means "reject", it means
"send non-delivery report to originator as indicated in
the reverse-path".

For the "mail-arch" draft that's not yet clear, I hope it
will use "envelope sender address" as the DSN RFCs, but
of course Dave hates this, it's too near to the 821 idea,
not his "bounces-to" view.

The SSP folks will replace their bogus "originator" not
compatible with mail-arch, 2822upd, etc. by "author" or
"first author". I hope. Of course they are not thrilled
to use correct terminologoy, with "originator" they could
pretend that SSP does something it clearly can't (as is).

Dfferent "terminologies" refelect different "ideologies",
as far as they're not only sloppy or shorthands or wrong.

And I think this isn't the list to improve it, we had our
chances with mail-arch and 2821-bis, to some degree we
used it: 2821bis is far better than 2821. IMO it could
be still clearer about the problem of "backscatter", but
it's definitely better than 2821.

>> After that decision it can do whatever it needs to do
>> to deliver the mail in its "own" _receiving network_.

> I assume _receiving network_ includes everything on the
> receiver's side, from the Border MTA to the final MDA.

Yes, personally I like Keith's terminology, MON + MRN for
Mail Originating / Receiving Network. Ignore all details
in the MON (=> business of the sender), and all details
in the MRN (=> business of the receiver), and especially
ignore the various ADMDs within MON or MRN.

But that's not good enough for our discussions, we need
the fact that an MON is also an MRN (and v.v.) to send
those bounces back to the originator. And we need a big
piece of Dave's terminolgoy ("mediator") for cases with
more than one border. SPF only needs to worry about one
kind of "mediator", a "traditional forwarder", but Dave's
term "mediator" makes it easier to discuss modifications.

> a Forwarder has a direct relationship with a Recipient,
> who also has a direct relationship with the Receiver,
> thereby forming an indirect relationship between the
> Forwarder and Receiver

Were the forwarder might have no idea that the receiver
checks SPF, and the receiver might have no idea that the
forwarder is a forwarder, and the recipient has no idea
at all what this is about, he just clicked buttons... ;-)

Sure, I know what you mean. And if TENBOX or whatever
allows forwarder and receiver to enter into a direct
relationship it's fine. Recipient and receiver should be
interested that this works. It's less obvious why the
forwarder should care about it. And if he cares, why SRS
isn't good enough.

>> the _receiver_ only needs to make sure to check SPF
>> once, at the border,
> We have a conflict here in the use of the word _receiver_.

Not really. I started with the simple case (no forwarding),
and added "forwarding to a third party" as last step. You
started with a forwarder as given, and used the "receiver"
where I said "third party". Checking Keith's terminology:

MON -> MRN + MON -> MRN
originator | mediator | receiver
sender 1st|border 2nd|border 3rd party

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85080791-c30092
Powered by Listbox: http://www.listbox.com

Frank Ellermann wrote:
> David MacQuigg wrote:
>> I'm still concerned that we don't have agreement on basic
>> terminology. Without that we can't have a productive
>> discussion.
>
> That's as it is. [...]
> Different "terminologies" reflect different "ideologies"

May I suggest that we use a community web page on openspf.org
for writing a glossary with the definition (and possibly
pointers to relevant archived post) of any term that is meant
to last more than a single thread?

That page should be mentioned in the relevant line of
http://www.openspf.org/Forums

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85150632-e704a1
Powered by Listbox: http://www.listbox.com

Frank, your writing is brilliant, but hard to follow with all the acronyms and "insider" talk. For those new to the list, whenever Frank says "Dave", he is referring not to me, but to Dave Crocker, an email expert who wrote "Internet Mail Architecture" http://www.ietf.org/internet-drafts/draft-crocker-email-arch-09.txt, a grand unified synthesis of email terminology and concepts.

Using Crocker's terminology from Fig. 3, our diagram

/
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
/
Border
might look like:

Originator(s) --> Source --> Relay(s) --> Dest --> Recipient

with no special role for Transmitter or Receiver, and no special significance or even recognition of a Border between originating and receiving networks. In Crocker's view, there are many borders, one for each ADMD (Administrative Management Domain). An ADMD might include one or more of the {Source, Relay(s), Dest} machine-level entities in the above diagram. If we want administrative-level entities, the best we can do is Fig.4:

+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +---------+ +--->| | | |
| V | | | ADMD2 | | +-------+ +-------+
| Edge--+---+ | ----- | |
| | | | | |
+-------+ +----|-Transit-+---+
| |
+---------+

Again, no recognition of a single, most-important Border. Even worse from an SPF point-of-view, this diagram implies there are "Transit ADMDs" with no relationship to either side.

I think Crocker's document is a noble effort to satisfy everyone, but in doing that, it ends up with such complexity and generality that it is hard to use when we need simplicity and specificity for a particular discussion, like we are having now on how to solve the forwarding problem.

Luckily, we don't need to satisfy everyone, just the participants in this discussion. We can use terminology like "transmitter" and "border", expand the diagram as needed to include a few "secondary borders", then make a new diagram for the next discussion.

One last question, before we proceed with the discussion - Should we clarify the role of Sender, i.e. individual vs domain? My sense is that we are talking about a domain, but it probably doesn't matter. Crocker's document defines Originator as being equivalent to Author, so it seems he referring to an individual. Maybe we should just use the phrase "individual sender" in any context where it matters.

At 05:21 AM 1/12/2008 +0100, Frank wrote:
>David MacQuigg wrote:
>
>> a Forwarder has a direct relationship with a Recipient,
>> who also has a direct relationship with the Receiver,
>> thereby forming an indirect relationship between the
>> Forwarder and Receiver
>
>Were the forwarder might have no idea that the receiver
>checks SPF, and the receiver might have no idea that the
>forwarder is a forwarder, and the recipient has no idea
>at all what this is about, he just clicked buttons... ;-)

LOL :>) This perfectly describes an interaction I had with an "ADMD" yahoo.com. They put my forwarding service (box67.com) on their "bulk" list (Yahoo's euphemism for spam), in spite of the fact that we forward only what the recipient wants us to forward, in this case, everything including the spam. When the recipient clicks the "Spam" button in Yahoo's webmail client (instead of forwarding it to our spamreport address, as we instructed), Yahoo dings the reputation of box67.com.

I don't have a good solution to this problem. Yahoo doesn't allow their recipients to set up individual whitelists (although they do have individual blacklists, so I know its not a question of resources). One thing we do recommend for any recipient forwarding to a large unresponsive service, is that they set up a separate account just to receive forwarded mail, and turn off all spam filtering on that account.

>Sure, I know what you mean. And if TENBOX or whatever
>allows forwarder and receiver to enter into a direct
>relationship it's fine. Recipient and receiver should be
>interested that this works. It's less obvious why the
>forwarder should care about it. And if he cares, why SRS
>isn't good enough.

box67.com (the receiver and forwarder) does use SRS on its forwarded mail, and we still have a problem with yahoo.com (the MDA). SRS hides that we are forwarding the mail.

At 11:59 AM 1/12/2008 +0100, Alessandro Vesely wrote:
>Frank Ellermann wrote:
>
>>Different "terminologies" reflect different "ideologies"
>
>May I suggest that we use a community web page on openspf.org
>for writing a glossary with the definition (and possibly
>pointers to relevant archived post) of any term that is meant
>to last more than a single thread?

Good suggestion, but we may have difficulty getting agreement on terminology even for this one thread.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85209603-6bc4ae
Powered by Listbox: http://www.listbox.com

Alessandro,

At 03:59 AM 1/12/2008, you wrote:
>Frank Ellermann wrote:
>>David MacQuigg wrote:
>>>I'm still concerned that we don't have agreement on basic
>>>terminology. Without that we can't have a productive discussion.
>>That's as it is. [...]
>>Different "terminologies" reflect different "ideologies"
>
>May I suggest that we use a community web page on openspf.org
>for writing a glossary with the definition (and possibly
>pointers to relevant archived post) of any term that is meant
>to last more than a single thread?
>
>That page should be mentioned in the relevant line of
>http://www.openspf.org/Forums

Excellent thought, although I'm wondering if a glossary of
definitions is not there, why not simply have it in the spec itself?

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85220298-4bc7e3
Powered by Listbox: http://www.listbox.com

On Sat, 12 Jan 2008, David MacQuigg wrote:

> LOL :>) This perfectly describes an interaction I had with an "ADMD"
> yahoo.com. They put my forwarding service (box67.com) on their "bulk" list
> (Yahoo's euphemism for spam), in spite of the fact that we forward only what
> the recipient wants us to forward, in this case, everything including the
> spam. When the recipient clicks the "Spam" button in Yahoo's webmail client
> (instead of forwarding it to our spamreport address, as we instructed), Yahoo
> dings the reputation of box67.com.

I've have the same problem repeatedly with AOL users. They disable my
content filter, because they "like the AOL one better", then add a forward
to their AOL account and proceed to mark all the spam. Everyone on
the same MTA then gets their AOL mail disabled. And I have to spend days
going through the AOL process to get reenabled, and disable their forwarding
ability. And they never do understand why I won't let them forward
or what the problem was.

I've ended up making a blanket rule - no forwarding to AOL. Ever. For
any reason - enforced by checking for aol.com in the MAIL TO for forwarded
messages by the outgoing mail milter.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85240482-e717ef
Powered by Listbox: http://www.listbox.com

WebMaster@Commerco.Net wrote:
> At 03:59 AM 1/12/2008, you wrote:
>> May I suggest that we use a community web page on openspf.org
>> for writing a glossary
>
> Excellent thought, although I'm wondering if a glossary of definitions
> is not there, why not simply have it in the spec itself?

I think the spec should be understood by the community at large, so they
should use terms from the rfc 1983 glossary. Yet, it is possible that we
come out with concepts that deserve inclusion in a wider community's
parlance.

FWIW, I wouldn't deem "transmitter" as defined in
http://open-mail.org/3strikes/QnA.html
is a useful term. Indeed, its definition implicitly refers to a boundary
even though that doesn't transpire from the term itself --as it does, for
example, in "MON", where "N" for Network implies a network boundary. And
it conflicts with the generic use of "transmitter" as the receiver's peer.

David MacQuigg wrote:
> Again, no recognition of a single, most-important Border.
> Even worse from an SPF point-of-view, this diagram
> implies there are "Transit ADMDs" with no relationship to
> either side.

Borders are particularly insidious for SPF. "ADMD" has different meanings
when its administrative management affects DNS, IPs assignment, or SMTP
configuration. In addition, large organizations are partitioned into
internal subunits, which may wish to carry out SPF checking one against
the other. I don't think we can pull out any useful topology from that.

A forwarder who knows it is whitelisted by a specific receiver may assume
no borders are crossed on forwarding to that receiver. Does that imply it
won't replace the original envelope sender?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85366622-e28a69
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> On Sat, 12 Jan 2008, David MacQuigg wrote:
>> LOL :>) This perfectly describes an interaction I had with an "ADMD"
>> yahoo.com [who] dings the reputation of box67.com.
>
> I've have the same problem repeatedly with AOL users. They disable my
> content filter, because they "like the AOL one better", then add a forward
> to their AOL account and proceed to mark all the spam. Everyone on
> the same MTA then gets their AOL mail disabled. And I have to spend days
> going through the AOL process to get reenabled, and disable their forwarding
> ability. And they never do understand why I won't let them forward
> or what the problem was.
>
> I've ended up making a blanket rule - no forwarding to AOL. Ever. For
> any reason - enforced by checking for aol.com in the MAIL TO for forwarded
> messages by the outgoing mail milter.

Obviously, senders want to maximize the chances that what they send gets
delivered. However, I hadn't thought that one would sacrifice forwarding
to specific domains in order to maximize the sum of its delivery chances.

As an alternative, you may register a domain that you only use for SPF-
compliant forwarding of unfiltered mail. That domain will end up having
the reputation it deserves, i.e. some average of the global spam traffic.
To let recipients make a better classification, you may opt to do vanilla
forwarding for senders that either lack any SPF policy or authorize your
IP explicitly --to achieve the same effect w.r.t. DNSBLs you need to use
a dedicated IP as well.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85367444-a08ec3
Powered by Listbox: http://www.listbox.com

On Sun, 13 Jan 2008, Alessandro Vesely wrote:

> > I've ended up making a blanket rule - no forwarding to AOL. Ever. For
> > any reason - enforced by checking for aol.com in the MAIL TO for forwarded
> > messages by the outgoing mail milter.
>
> Obviously, senders want to maximize the chances that what they send gets
> delivered. However, I hadn't thought that one would sacrifice forwarding
> to specific domains in order to maximize the sum of its delivery chances.
>
> As an alternative, you may register a domain that you only use for SPF-
> compliant forwarding of unfiltered mail. That domain will end up having
> the reputation it deserves, i.e. some average of the global spam traffic.
> To let recipients make a better classification, you may opt to do vanilla
> forwarding for senders that either lack any SPF policy or authorize your
> IP explicitly --to achieve the same effect w.r.t. DNSBLs you need to use
> a dedicated IP as well.

Doesn't help with AOL. They track reputation by IP (they don't check SPF). I
would need a another IP for forwarding unfiltered mail to AOL - and it would be
a waste because it would be very quickly blacklisted.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85450957-9b4fdd
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> On Sun, 13 Jan 2008, Alessandro Vesely wrote:
>
>> > I've ended up making a blanket rule - no forwarding to AOL. Ever. For
>> > any reason - enforced by checking for aol.com in the MAIL TO for forwarded
>> > messages by the outgoing mail milter.
>>
>> Obviously, senders want to maximize the chances that what they send gets
>> delivered. However, I hadn't thought that one would sacrifice forwarding
>> to specific domains in order to maximize the sum of its delivery chances.
>>
>> As an alternative, you may register a domain that you only use for SPF-
>> compliant forwarding of unfiltered mail. That domain will end up having
>> the reputation it deserves, i.e. some average of the global spam traffic.
>> To let recipients make a better classification, you may opt to do vanilla
>> forwarding for senders that either lack any SPF policy or authorize your
>> IP explicitly --to achieve the same effect w.r.t. DNSBLs you need to use
>> a dedicated IP as well.
>
> Doesn't help with AOL. They track reputation by IP (they don't check SPF). I
> would need a another IP for forwarding unfiltered mail to AOL - and it would be
> a waste because it would be very quickly blacklisted.

Thus it becomes apparent that SPF can help saving IPv4 addresses!
(In that respect, it is functionally similar to the "Host" HTTP header
and the "Server Name Indication" TLS extension.)

I mentioned you needed a dedicated IP. If the receiver that feeds your
forwarder is a client of the same DNSBL that blacklists it, that should
make for a good removal argument: it is enough if they blacklist the
original submitter. (AOL is peculiar in that it doesn't publish its
blacklist, AFAIK.)

Of course, it is technically unfeasible to forward mail keeping the
original sender's IP address. That is similar to the case where the
original sender's policy doesn't allow the forwarder to keep the same
envelope sender's domain. For both cases, the forwarder's problem is
how to indicate to blacklisters that the responsibility of the message
content should be associated with the original datum. For both cases,
blacklisters may contest the trustworthiness of the Received[-SPF]
headers written by forwarders.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85546233-c5a9b8
Powered by Listbox: http://www.listbox.com

On Mon, 14 Jan 2008, Alessandro Vesely wrote:

> original submitter. (AOL is peculiar in that it doesn't publish its
> blacklist, AFAIK.)

Yes, that would neatly solve the problem if only I could query their
blacklist before forwarding to aol.com. But since they don't provide that
and are a giant unresponsive corporation, I have to ban forwarding.
I suppose I could at least reject with 551.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85725546-f35e45
Powered by Listbox: http://www.listbox.com

At 11:33 AM 1/14/2008 +0100, Alessandro Vesely wrote:
>Stuart D. Gathman wrote:
>>On Sun, 13 Jan 2008, Alessandro Vesely wrote:
>>
>>>> I've ended up making a blanket rule - no forwarding to AOL. Ever. For
>>>> any reason - enforced by checking for aol.com in the MAIL TO for forwarded
>>>> messages by the outgoing mail milter.
>>>Obviously, senders want to maximize the chances that what they send gets
>>>delivered. However, I hadn't thought that one would sacrifice forwarding
>>>to specific domains in order to maximize the sum of its delivery chances.
>>>As an alternative, you may register a domain that you only use for SPF-
>>>compliant forwarding of unfiltered mail. That domain will end up having
>>>the reputation it deserves, i.e. some average of the global spam traffic.
>>>To let recipients make a better classification, you may opt to do vanilla
>>>forwarding for senders that either lack any SPF policy or authorize your
>>>IP explicitly --to achieve the same effect w.r.t. DNSBLs you need to use
>>>a dedicated IP as well.
>>Doesn't help with AOL. They track reputation by IP (they don't check SPF). I
>>would need a another IP for forwarding unfiltered mail to AOL - and it would be
>>a waste because it would be very quickly blacklisted.
>
>Thus it becomes apparent that SPF can help saving IPv4 addresses!
>(In that respect, it is functionally similar to the "Host" HTTP header
>and the "Server Name Indication" TLS extension.)
>
>I mentioned you needed a dedicated IP. If the receiver that feeds your
>forwarder is a client of the same DNSBL that blacklists it, that should
>make for a good removal argument: it is enough if they blacklist the
>original submitter. (AOL is peculiar in that it doesn't publish its
>blacklist, AFAIK.)
>
>Of course, it is technically unfeasible to forward mail keeping the
>original sender's IP address. That is similar to the case where the
>original sender's policy doesn't allow the forwarder to keep the same
>envelope sender's domain. For both cases, the forwarder's problem is
>how to indicate to blacklisters that the responsibility of the message
>content should be associated with the original datum. For both cases,
>blacklisters may contest the trustworthiness of the Received[-SPF]
>headers written by forwarders.

Well, using our new terminology, we should be able to simplify this discussion.

/
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
/
Border (Stuart) (aol.com)

As I understand it, Stuart is saying that the MDA (aol.com) blacklists his IP address whenever a Recipient, who asked Stuart to forward his mail, later clicks "This is Spam" on a piece of that forwarded mail. This blacklisting then blocks mail from Stuart to other Recipients at aol.com.

Now, the "original submitter" (I assume you mean Sender in our diagram) SHOULD be the one held responsible for the spam, but that is something that can only be handled between the Transmitter and Receiver. The Receiver should get the spam report (not AOL, not SpamCop, not anyone who doesn't know what is going on). The Receiver should communicate with the Transmitter (not directly with the Sender) and the Transmitter should take prompt action to eliminate the problem (zombie Sender, whatever).

The trickier question is what should Stuart do when AOL takes action against him, based on an error by the Recipient. Cutting off all AOL recipients seems a bit extreme to me, and certainly worse than letting AOL cut the connection. AOL should deal with the complaints. Maybe if they hear from their own customers, they will find a better way to accommodate forwarders.

I don't know AOL's policies, but assuming they don't blacklist senders when there is only a very small amount of spam leaking through, a less severe Forwarder's policy might work. Perhaps Stuart could suspend just one Recipient account on the first spam report. That will ensure the Recipient knows not to do it again. Maybe the problem is absent-mindedness. The Recipient should figure out how to segregate the forwarded mail from anything else which he might report as spam. That may even require setting up a whole new account just to receive forwarded mail. I've done this with all MDAs that handle my own mail. Most accounts are free, so its not a big deal.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85747413-cb356f
Powered by Listbox: http://www.listbox.com

On Mon, 14 Jan 2008, David MacQuigg wrote:

> I don't know AOL's policies, but assuming they don't blacklist senders when
> there is only a very small amount of spam leaking through, a less severe
> Forwarder's policy might work. Perhaps Stuart could suspend just one
> Recipient account on the first spam report. That will ensure the Recipient
> knows not to do it again. Maybe the problem is absent-mindedness. The
> Recipient should figure out how to segregate the forwarded mail from anything
> else which he might report as spam. That may even require setting up a whole
> new account just to receive forwarded mail. I've done this with all MDAs
> that handle my own mail. Most accounts are free, so its not a big deal.

I did that at first. But, it is a pretty consistent statistical fact that
anyone who uses AOL mail is utterly clueless about email and computers in
general, and is incapable of understanding what the problem is and how
their actions are responsible. They might be (and usually are) smart in
other ways, but are computer idiots. So refusing to forward to AOL is the
only workable solution until AOL makes their blacklists available to
forwarders, or makes other arrangements.

AOL is a poster child for why the canard about how SPF "breaks forwarding"
is complete FUD. *Any* system that blocks the sources of spam
"breaks forwarding". And that is as it should be. Alias forwarding
is broken, SPF or no SPF. It can only work when specifically configured
by the receiver as well as forwarder.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85839473-c16fc1
Powered by Listbox: http://www.listbox.com

David MacQuigg wrote:

> whenever Frank says "Dave", he is referring not to me, but to Dave
> Crocker, an email expert who wrote "Internet Mail Architecture"

ACK, sorry, I wasn't aware of this ambiguity. He also wrote RFC 822
(STD 11), the predecessor of 2822, and was an author or co-author of
other e-mail related RFCs (e.g. 5068) and drafts (e.g. CSV). A big
proponent of DKIM, and opponent of SPF + SSP.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85920169-d3a690
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
>
> AOL is a poster child for why the canard about how SPF "breaks forwarding"
> is complete FUD. *Any* system that blocks the sources of spam
> "breaks forwarding". And that is as it should be. Alias forwarding
> is broken, SPF or no SPF.

Agreed.

> It can only work when specifically configured by the receiver as well as
> forwarder.

Thus far, we have located a few ways to aid that task:

* whitelisting by MTA-specific (IP-based?) settings,
* the AUTH Parameter to the MAIL FROM command,
* SPF "i-am=" or similar modifiers in the DNS record.

David MacQuigg wrote:
>
> Well, using our new terminology, we should be able to simplify this discussion.
>
> /
> Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
> /
> Border (Stuart) (aol.com)

I'm not sure aol.com should be labeled "MDA". In addition,
there is a second border after the Forwarder(s). The latter
is what makes it difficult for the receiver to reuse spam
knowledge gathered by the recipient.

Why is that forwarding different from secondary MX transfer?
(The last time I had a secondary MX it was on a different ADMD
in order to be on a different network --that way, I did once
receive a notification that my network was unreachable.)
Currently, I have no secondary MX in order to avoid those
difficulties. Besides unlisting/nolisting tricks, I guess that
is the current best practice about secondary MXes. Isn't it?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85950859-cdedf9
Powered by Listbox: http://www.listbox.com

For the benefit of non-experts, I'll add a few definitions as I go, at least as I understand the terminology. Let me know if I misunderstood anything. Maybe Alessandro can collect these definitions for his Glossary page.

At 04:08 PM 1/14/2008 -0500, Stuart Gathman wrote:
>On Mon, 14 Jan 2008, David MacQuigg wrote:
>
>> I don't know AOL's policies, but assuming they don't blacklist senders when
>> there is only a very small amount of spam leaking through, a less severe
>> Forwarder's policy might work. Perhaps Stuart could suspend just one
>> Recipient account on the first spam report. That will ensure the Recipient
>> knows not to do it again. Maybe the problem is absent-mindedness. The
>> Recipient should figure out how to segregate the forwarded mail from anything
>> else which he might report as spam. That may even require setting up a whole
>> new account just to receive forwarded mail. I've done this with all MDAs
>> that handle my own mail. Most accounts are free, so its not a big deal.
>
>I did that at first. But, it is a pretty consistent statistical fact that
>anyone who uses AOL mail is utterly clueless about email and computers in
>general, and is incapable of understanding what the problem is and how
>their actions are responsible. They might be (and usually are) smart in
>other ways, but are computer idiots. So refusing to forward to AOL is the
>only workable solution until AOL makes their blacklists available to
>forwarders, or makes other arrangements.
>
>AOL is a poster child for why the canard about how SPF "breaks forwarding"
>is complete FUD. *Any* system that blocks the sources of spam
>"breaks forwarding". And that is as it should be.

Yet AOL is a shining example of how a large email service, working for the good of the community, can eliminate outgoing spam. They also publish an SPF record (although not ending in -all as we would like). I think we should try to figure out how to make SPF work with services like AOL and Yahoo, who are *allies* in the war against spam, and not just keep saying that they and everyone like them are wrong.

Both of these companies have eliminated their outgoing spam, even though that adds nothing to their bottom line. They deserve some recognition of their good work, at least among email experts.

>Alias forwarding is broken, SPF or no SPF.
-- Alias forwarding: forwarding an email and keeping its original Return Address,
rather than re-writing it using SRS.
-- SRS: Sender Re-writing Scheme http://openspf.org/SRS - A method used by Forwarders
to re-write the Return Address so as to include the Forwarder's domain name.

Yet AOL and others process tons of forwarded mail each day, and 99% of it doesn't use SRS. So I guess we need a definition of broken.

>It can only work when specifically configured by the receiver as well as forwarder.

So how can we encourage forwarders and receivers to make these arrangements? Right now we have small domains like Stuart's and mine making laborious arrangements with companies like AOL and Yahoo, just to send *normal* mail to their subscribers. That is a lot of work, much more than these companies should expect of us. We need to make the process simple, and fully automated.

Maybe we could agree on a simple, standardized form, one for each Recipient that wants their mail forwarded. After receiving a few of these forms, Yahoo would figure out that it actually saves time on their end, compared to a bunch of emails back and forth, and the five-page "exam" that they had me fill out, proving that I knew how to manage a "mailing list".

The essential information in the form would be the Forwarder's domain name, its authorized transmitter addresses, and the recipient's forwarding address. '''STANDARD FORWARDING REQUEST \n To: _yahoo.com_ \n From: __box67.com_ \n IP addresses: _see our SPF record_ \n Recipient _dmacquig@yahoo.com_ has asked us to forward all his mail to his new address in your domain. Please let us know when we may begin.''' Assuming Yahoo confirms the request with its Recipient, this procedure seems airtight, i.e. no way a spammer can abuse it.


At 10:38 AM 1/15/2008 +0100, Alessandro Vesely wrote:

>Thus far, we have located a few ways to aid that task:
>
>* whitelisting by MTA-specific (IP-based?) settings,
>* the AUTH Parameter to the MAIL FROM command,
>* SPF "i-am=" or similar modifiers in the DNS record.

Don't forget http://trusted-forwarder.org/ and Michael's TENBOX proposal. We could also add a "Standard Forwarding Request" form, but I haven't given it any more thought than just what I've written above.

>David MacQuigg wrote:
>>
>>Well, using our new terminology, we should be able to simplify this discussion.
>> /
>>Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
>> /
>> Border (Stuart) (aol.com)
>
>I'm not sure aol.com should be labeled "MDA".

That is their role in this exchange. Of course, as a company they provide a lot of other services, including Sender, Transmitter, Receiver, Forwarder, Webhost, Domain Registrar, Targeted Advertising ...

>In addition,
>there is a second border after the Forwarder(s). The latter
>is what makes it difficult for the receiver to reuse spam
>knowledge gathered by the recipient.

??? There is a *direct* relationship between the Receiver and the Recipient. The Recipient should send spam reports directly to the Receiver, not AOL, not SpamCop, not anyone who has no *first-hand knowledge* of the source of the spam.

These relationships are what make all the "borders" in the MRN *secondary*. Unlike mail transfers crossing a Border, transfers within an MRN are based on *prior arrangements*.

-- MRN: Mail Receiving Network - includes all MTAs and connections on the
Receiver's side of the Border.
-- Border: the interface between the last MTA on the Sender's side, and the
first MTA on the Receiver's side of a mail transfer. There is one and
only one Border in a normal mail transfer between unrelated parties on
the open Internet.

>Why is that forwarding different from secondary MX transfer?
>(The last time I had a secondary MX it was on a different ADMD
>in order to be on a different network --that way, I did once
>receive a notification that my network was unreachable.)
>Currently, I have no secondary MX in order to avoid those
>difficulties. Besides unlisting/nolisting tricks, I guess that
>is the current best practice about secondary MXes. Isn't it?

-- Secondary MX: An email Receiver listed as a backup to the main Receiver
for a domain.

Secondary MXs are often exploited by spammers, who expect that there will be less effective defenses on those machines. Even if you have good defenses, you will see a flood of attempts to spam those machines. I had a secondary MX for a while, but dropped it for these reasons. In nearly three years, our primary MX has been down only once, and that was 20 minutes for a pre-arranged service upgrade. Hosting services are so cheap and reliable now, that secondary MXs are just not needed.

That's not to say a busy domain doesn't need *multiple* MXs, but the difference is that all MXs are configured identically, including the recipient database, which is hard to replicate on a shared "secondary" MX.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86050295-695593
Powered by Listbox: http://www.listbox.com

On Tue, 15 Jan 2008, David MacQuigg wrote:

> >AOL is a poster child for why the canard about how SPF "breaks forwarding"
> >is complete FUD. *Any* system that blocks the sources of spam
> >"breaks forwarding". And that is as it should be.
>
> Both of these companies have eliminated their outgoing spam, even though that
> adds nothing to their bottom line. They deserve some recognition of their
> good work, at least among email experts.

I didn't say AOL was wrong. I said:

> >Alias forwarding is broken, SPF or no SPF.

AOL works because they track reputation (by IP in their case).
I cannot honor requests from AOL users to forward mail because
that requires special treatment by AOL - which is not available.

> -- Alias forwarding: forwarding an email and keeping its original Return
> Address, rather than re-writing it using SRS.
> -- SRS: Sender Re-writing Scheme http://openspf.org/SRS - A method used by
> Forwarders to re-write the Return Address so as to include the Forwarder's
> domain name.
>
> Yet AOL and others process tons of forwarded mail each day, and 99% of it
> doesn't use SRS. So I guess we need a definition of broken.

It doesn't matter whether SRS is used. Forwarding to AOL is broken
in either case - because they track reputation by IP, not domain.

> >It can only work when specifically configured by the receiver as well as
> >forwarder.
>
> So how can we encourage forwarders and receivers to make these arrangements?
> Right now we have small domains like Stuart's and mine making laborious
> arrangements with companies like AOL and Yahoo, just to send *normal* mail to
> their subscribers. That is a lot of work, much more than these companies
> should expect of us. We need to make the process simple, and fully
> automated.

It all works great with no special arrangements - as long as you don't
forward or fully filter the stuff you do forward (or the subscriber has a clue
and doesn't mark forwarded stuff as spam - which isn't going to happen with AOL
users). Unfiltered (alias) forwarding is broken when reputation affects
delivery.

> Maybe we could agree on a simple, standardized form, one for each Recipient
> that wants their mail forwarded. After receiving a few of these forms, Yahoo

Does not address the problem at all. The [unfiltered] junk being forwarded
really is spam! What is needed is for forwarders to have access to the
AOLs reputation database (via DNS for example) so that they can reject
blacklisted senders, and a way to pass forward the source of messages so
that reputation acrues to the actual sender.

None of this has anything to do with SPF or SRS.

> know when we may begin.''' Assuming Yahoo confirms the request with its
> Recipient, this procedure seems airtight, i.e. no way a spammer can abuse it.

The spammer abuses it by sending lots of spam - which gets forwarded,
but then the forwarders IP gets blacklisted instead of the spammers.

In an environment where IP/domain reputation matters, forwarding
email is like co-signing a loan.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86060706-d4dc22
Powered by Listbox: http://www.listbox.com

David MacQuigg wrote:
>>>Thus far, we have located a few ways to aid that task:
>>>
>>>* whitelisting by MTA-specific (IP-based?) settings,
>>>* the AUTH Parameter to the MAIL FROM command,
>>>* SPF "i-am=" or similar modifiers in the DNS record.
>
> Don't forget http://trusted-forwarder.org/ and Michael's
> TENBOX proposal.

Good point. I found the latter at
http://www.gossamer-threads.com/lists/spf/discuss/28067

> We could also add a "Standard Forwarding
> Request" form, but I haven't given it any more thought than
> just what I've written above.

However, the three added points describe techniques for
establishing relationships. The former three points apparently
address what happens during an SMTP transaction more closely.

> -- Alias forwarding: forwarding an email and keeping its
> original Return Address, rather than re-writing it using SRS.
> -- SRS: Sender Re-writing Scheme http://openspf.org/SRS - A
> method used by Forwarders to re-write the Return Address so
> as to include the Forwarder's domain name.

For the terminology, I'd propose "vanilla forwarding" or
"plain mail forwarding", as opposed to "SPF-compliant
forwarding", be the latter SRS or otherwise.

>> I'm not sure aol.com should be labeled "MDA".
>
> That is their role in this exchange. Of course, as a company
> they provide a lot of other services, including Sender,
> Transmitter, Receiver, Forwarder, Webhost, Domain Registrar,
> Targeted Advertising ...
>
>> In addition, there is a second border after the
>> Forwarder(s). The latter is what makes it difficult for the
>> receiver to reuse spam knowledge gathered by the recipient.
>
> ??? There is a *direct* relationship between the Receiver and
> the Recipient. The Recipient should send spam reports
> directly to the Receiver, not AOL, not SpamCop, not anyone
> who has no *first-hand knowledge* of the source of the spam.

This is where I get lost. We don't actually mount AOL's hard
disks on the Receiver host --which I'd call "direct". Formally,
we engage an SMTP (or LMTP) transaction with their server,
playing the transmitter's role.

> These relationships are what make all the "borders" in the
> MRN *secondary*. Unlike mail transfers crossing a Border,
> transfers within an MRN are based on *prior arrangements*.

Fine.

> -- MRN: Mail Receiving Network - includes all MTAs and
> connections on the Receiver's side of the Border.

It is not clear if that is defined for each single transfer or
if an MRN is the union of all such MTAs for each recipient
currently valid at the target MTA. It is clear that MRN is
determined after the target domain, MRN(RHS). However, "prior
arrangements" might also be made for each specific user. In the
latter case an MRN is determined as a function of a specific
address, MRN(mailbox).

If I got it right, that parallels one difference between TENBOX
and trusted-forwarder.org.

> -- Border:
> the interface between the last MTA on the Sender's side, and
> the first MTA on the Receiver's side of a mail transfer.
> There is one and only one Border in a normal mail transfer
> between unrelated parties on the open Internet.

Again, I tend to understand that as "unrelated as far as one
specific exchange is concerned."

>> Why is that forwarding different from secondary MX
>> transfer? (The last time I had a secondary MX it was on a
>> different ADMD in order to be on a different network --that
>> way, I did once receive a notification that my network was
>> unreachable.) Currently, I have no secondary MX in order to
>> avoid those difficulties. Besides unlisting/nolisting
>> tricks, I guess that is the current best practice about
>> secondary MXes. Isn't it?
>
> -- Secondary MX: An email Receiver listed as a backup to the
> main Receiver for a domain.
>
> Secondary MXs are often exploited by spammers, who expect
> that there will be less effective defenses on those machines.
> Even if you have good defenses, you will see a flood of
> attempts to spam those machines. I had a secondary MX for a
> while, but dropped it for these reasons.

So did I. What I wanted to point out is that a secondary MX is
also part of an MRN. It also forwards mail attempting an SMTP
(or LMTP) transaction toward the primary MX (or one of them.)
Obviously, one difference is that secondary MXes don't change
the envelope recipients, while forwarders do that. Yet, those
who didn't give up secondary MXes (anyone out there?) had to
tackle the problems of how to configure mail acceptance and
propagate data for defensive mechanisms. The same problems that
we tackle now.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86245986-d96530
Powered by Listbox: http://www.listbox.com

On Tue, 15 Jan 2008, David MacQuigg wrote:
> The essential information in the form would be the Forwarder's domain
> name, its authorized transmitter addresses, and the recipient's forwarding
> address. '''STANDARD FORWARDING REQUEST \n To: _yahoo.com_ \n From:
> __box67.com_ \n IP addresses: _see our SPF record_ \n Recipient
> _dmacquig@yahoo.com_ has asked us to forward all his mail to his new
> address in your domain. Please let us know when we may begin.''' Assuming
> Yahoo confirms the request with its Recipient, this procedure seems
> airtight, i.e. no way a spammer can abuse it.

That's what TENBOX/O would be. I haven't elucidated it further because
it's better to get TENBOX/E settled first. TENBOX/E alone can at least be
used reliably on it's own by the power users who can manually key in a
pseudo-address to whitelist.

TENBOX/O could in theory be used alone, but only by mailing lists that do
not VERP and forwarders that always Sham-SRS to the same MAIL FROM.

(For those who forget:
TENBOX/E = authEntication component of the TENBOX solution
TENBOX/O = authOrization component of the TENBOX solution
)

> Don't forget http://trusted-forwarder.org/ and Michael's TENBOX
> proposal. We could also add a "Standard Forwarding Request" form, but I
> haven't given it any more thought than just what I've written above.

He didn't forget it. TENBOX/E *is* the AUTH-parameter approach.
TENBOX/O (the standard-request-form) is not a competitor but just a
user-friendly interface to TENBOX/E.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86285894-5106e7
Powered by Listbox: http://www.listbox.com

On Thu, 10 Jan 2008, David MacQuigg wrote:
> I wish we had a shared terminology for the various entities in an
> exchange. From this and other recent discussions on this list, I'm trying

Actually we do already have a vocabulary.

The relay at the sender's border is called a "smarthost".

The relay at the recipient's border is called an "MX".

There's no term for the possibly-multiple relays that constitute a
forwarder. However, we can generally treat the forwarder as a black box,
and just use the term "Forwarder" to refer to the whole thing.

> Sender --> Relay --> /Border/ --> Forwarder(s) --> Receiver --> Recipient

Normal case:
Sender --> Smarthost ==> MX --> Recipient

Forwarding case:
Sender --> Smarthost ==> Forwarder ==> MX --> Recipient

Where "==>" denotes a border-crossing hop.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86280228-c44abf
Powered by Listbox: http://www.listbox.com

On Tue, Jan 15, 2008 at 04:42:26PM -0800, Michael Deutschmann wrote:

> Normal case:
> Sender --> Smarthost ==> MX --> Recipient
>
> Forwarding case:
> Sender --> Smarthost ==> Forwarder ==> MX --> Recipient
>
> Where "==>" denotes a border-crossing hop.

Shouldn't the forwarder case more appropriately read:

Sender --> Smarthost ==> MX --> Forwarder ==> MX --> Recipient

(or, if "Forwarder" is a black box:
Sender --> Smarthost ==> MX(Recipient) --> Forwarder")

The sender, relevant to SPF, doesn't know nor care what happens after
the first "==> MX". It, or some entity like "Smarthost" acting on
behalf of the sender, was told to deliver mail for "example.com" at
mx.example.com, it did so, and then responsibility for the message is
transfered to "example.com".

Whatever happens to this message is now under control of the recipient,
and problems occuring from that moment on are the recipient's problems.

Why would there be a difference between:

"... MX --> Forwarder ==> MX --> Recipient"

and

"... MX --> Internal_relay1 --> Internal_relay2 --> Recipient"

?


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=86296621-31bff9
Powered by Listbox: http://www.listbox.com