Subject: [Asrg] More e-mail oddities; SPF thoughts

From: Douglas Campbell <[email-masked]>
Date: Wed, 01 Feb 2006 23:25:52 -0800

All,

I mentioned previously that my domain name has been hijacked by spammers 
for use in falsified return paths.  As a result, I am receiving 
approximately 500 bounce e-mails per day from spammed servers.  I've 
noticed something quite interesting about the most recent batch of 
bounces -- the message id of the bounced spam attachment starts with 
what appears to be an ESC 20 (or, more exactly, text looking like 
<R[20), with the rest of the headers and body suppressed.

I'm wondering what the spammers are up to with this -- the bounce e-mail 
contains virtually NO information to allow me to backtrace.  Any ideas?

Claus,

I've just realized that the .forward capability in sendmail operates 
differently than my MUA, thunderbird, does when I manually forward..  If 
I manually forward an e-mail from thunderbird, I tell it the new 
recipients and get the chance to add additional information in a body.  
Thunderbird makes the original e-mail headers and body  into an 
attachment and wrappers that with my own envelope, headers, and body.  
Why is the automated process different from the manual one?

Note that, in the case of forwarded mail, it has often been accepted by 
a boundary MTA and sent onward to the appropriate interior MTA for 
delivery to the end user; it's the interior machine that has access to 
the .forward information, not the boundary MTA.  Hence, the only way the 
original sender can be notified that the possibly multiple forwarding 
addresses have problems is via bounce messages, since his original 
e-mail has already been accepted by a boundary MX system of the 
forwarder's domain.

I'm coming to the conclusion from my own bounce message problems that 
bounce messages are intrinsically bad, because they can easily be turned 
into a third party DOS issue.  For example, I've thought of adding 
[email-masked] to a .forward file in my postmaster account, given that 
they are hosting the spamvertised website's portal page and refuse to 
take it down.

Cheers,
Doug Campbell

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Danny Angus <[email-masked]>
Date: Thu, 2 Feb 2006 08:56:43 +0000

> differently than my MUA, thunderbird, does when I manually forward..

Two different rules for two different roles, an MTA is actually re-routing
the original message the MUA is forwarding the content of the message in a
new message.
This is how it is supposed to work, whether or not it is a wholly Good
Thing is another matter.

d.

***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Feb 2006 11:03:33 +0100

Douglas Campbell wrote:

> the bounce e-mail contains virtually NO information to allow
> me to backtrace.  Any ideas?

If you're 100% sure that the original spam wasn't sent by "you"
(i.e. malware on your system) you can report the "backscatter"
with SpamCop.  A "minority" thinks that this is bad without SPF
FAIL policy, but this "minority" is somewhat limited (= me ;-).

> I've just realized that the .forward capability in sendmail
> operates differently than my MUA, thunderbird, does when I
> manually forward..

Yes, "forward", "bounce", and "sender" are confusing terms,
everybody has its own definition.  When you "forward" manually
with a MUA, it's normally MAIL FROM you, and it can be

- "resend" (MUA adds Resent-* header fields, see RfC (2)822)

- a mail with MIME Content-Type message/rfc822 (your header +
  the forwarded mail with the complete original header)

- dito with Content-Disposition "attachment" (OE can do this,
  bad idea but mostly harmless)

- dito multipart/digest, one or more message/rfc822 parts plus
  optionally other parts (like a text/plain part where you can
  say why you forwarded one or more complete mails ;-)

- dito multipart/mixed, almost the same, only a different
  default type for the one or more parts:  the digest default
  is message/rfc822, and the mixed default is text/plain.

- pseudo-forward, calendar software like Outlook abused as MUA
  could create a single part, your text, followed by a ruler,
  old From / Date / Subject (most other header fields AWOL),
  followed by the body of the original mail (if it was plain
  text, no idea how bad it gets for other content types)

- in theory you (= your MUA) could also forward multiple mails
  in one of the many mbox formats (MIME type application/mbox)

OTOH when talking about SMTP "forward" generally means one MTA
sending stuff as is to the next hop, adding a timestamp line
(Received header field).

That can be on the side of the "sender" (MUA = MTA to MSA, MSA to
"mailout") or on the side of the receiver (secondary MX to
primary MX, MX to MDA, maybe a separate AV-MTA before the MDA).

And of course it can be between "sender" (last mailout MTA) and
receiver (first MX on his side).  These cases of "forwarding"
are all sane as far as SPF is concerned, if the "sender" has
enumerated all IPs of his "mailouts" (sending border MTAs), and
the receiver checks SPF at his border, not behind it.

"RTFM" is all it takes (e.g. the primary MX should white list
the secondary MX, the latter "forwards" mails to the primary).

Also no problem for mailing-lists, when they redistribute mails
(another case of "forward"), they use their own MAIL FROM to
catch error messages.  That case is messy with PRA (SenderID).

The most interesting case of "forward" is "251 user not local",
because then the mail is sent to a 3rd party.  If the forwarder
kept the original MAIL FROM as proposed in RfC 1123 5.3.6(a) it
breaks:  Error messages won't go to the responsible party (i.e.
the forwarder), and if the MAIL FROM was forged they also don't
go to the originator (as mandated by 2821), they hit innocent
bystanders.  RfC 1123 5.3.6(a) forwarding is broken by design.

> Why is the automated process different from the manual one?

It used to work before 1123, keep almost everything as is, add
host to MAIL FROM (reverse path), add timestamp line, use new
RCPT TO, ready.

Then they eliminated the "unnecesary" routing crap, after all
why should the final recipient C route error messages via the
forwarder B, if it could send it directly to an originator A ?

The subtle problem identified more than a decade later, the
poor A never was the originator.  It's a "mission impossible",
a bug, they screwed up when they tried to eliminate routing.

> I'm coming to the conclusion from my own bounce message
> problems that bounce messages are intrinsically bad, because
> they can easily be turned into a third party DOS issue.

IBTD.  Numerous things can go wrong in SMTP.  It's a "simple"
protocol, no rocket science, it doesn't work very well if mail
routinely vanishes in black holes instead of reporting errors.

The "intrinsically bad" thing are forged Return-Paths, and SPF
allows (or rather asks) to _reject_ FAIL.  Bounces to SPF PASS
never hit innocent bystanders, they are good.

> I've thought of adding [email-masked] to a .forward file in
> my postmaster account, given that they are hosting the
> spamvertised website's portal page and refuse to take it down

Fighting abuse with abuse is often a very bad plan.  Bye, Frank

---

From: Gunnar Lindberg <[email-masked]>
Date: Thu, 2 Feb 2006 11:27:22 +0100 (MET)

For one thing, .foward is _much_ older than rfc822 attachements.

Changing behavior would expect rfc822 attachements to be ubiquitous.

	Gunnar Lindberg

>From [email-masked]  Thu Feb  2 09:53:30 2006
>In-Reply-To: <[email-masked]>
>Subject: Re: [Asrg] More e-mail oddities; SPF thoughts
>To: Douglas Campbell <[email-masked]>
>Message-ID: <[email-masked]>
>From: Danny Angus <[email-masked]>
>Date: Thu, 2 Feb 2006 08:56:43 +0000
>Cc: [email-masked]

---

From: Bill Cole <[email-masked]>
Date: Thu, 2 Feb 2006 08:27:31 -0500

At 11:25 PM -0800 2/1/06, Douglas Campbell wrote:
>All,
>
>I mentioned previously that my domain name has been hijacked by 
>spammers for use in falsified return paths.  As a result, I am 
>receiving approximately 500 bounce e-mails per day from spammed 
>servers.  I've noticed something quite interesting about the most 
>recent batch of bounces -- the message id of the bounced spam 
>attachment starts with what appears to be an ESC 20 (or, more 
>exactly, text looking like <R[20), with the rest of the headers and 
>body suppressed.
>
>I'm wondering what the spammers are up to with this -- the bounce 
>e-mail contains virtually NO information to allow me to backtrace. 
>Any ideas?

These have been flowing for years, and there has been some debate 
over exactly what is going on, but it is either a software bug in a 
piece of spamware that uses compromised machines, a common spammer's 
misconfiguration of such a tool, or (dubious) the effect of some 
security device between the sending zombie and the receiving MTA.

The appearance you describe is a bit misleading. The fingerprint of 
this flavor of runt spam is:

1. Very short message data: rarely more than 3 lines, sometimes just one.
2. If there is any formal body, it looks like a detached header, 
usually a malformed Message-ID.
3. Often there is one (clearly fake) Received header.
4. Rarely, there is a Date header.
5. The trailing end of the last line (usually a detached Message-ID 
'header') is '[' followed by one or two digits, with the Message-ID 
subspecies always ending with '[20' preceded by '<' and one capital 
letter.

I would bet that if you look closely at the mail you describe, you 
will notice that the Message-ID 'header' is detached, and that if it 
has a Received header unassociated with the machine bouncing the 
mail, that header is not actually credible, and maybe not even 
complete.
-- 
Bill Cole                                  
[email-masked]

---

From: der Mouse <[email-masked]>
Date: Thu, 2 Feb 2006 09:28:11 -0500 (EST)

> For one thing, .foward is _much_ older than rfc822 attachements.

What are "rfc822 attachements"?  As far as I can tell, neither 822 nor
its successor 2822 has anything to say about anything that would
normally be called an attachment.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 02 Feb 2006 15:54:37 +0000

On Feb 2,  9:28am, der Mouse wrote:
} Subject: Re: [Asrg] More e-mail oddities; SPF thoughts
}
} > For one thing, .foward is _much_ older than rfc822 attachements.
} 
} What are "rfc822 attachements"?

MIME parts with content-type message/rfc822.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 05 Feb 2006 11:38:24 -0800

> This is how it is supposed to work, whether or not it is a wholly Good

To drive your point home even further, and with crushingly boring detail:

The .forward mechanism is a cooperative action between the recipient specified 
in the SMTP RCPT-TO envelope address and that recipient's email service delivery 
agent (MDA).  It's effect is to re-submit exactly the same message, with one 
significant difference:  There is a new SMTP RCPT-TO address.  (I am ignoring 
whether there are additional Received headers, because they do not matter for 
this discussion.)  Even though the .forward mechanism uses information created 
by the recipient, it really is best to view it as an enhancement to the email 
transfer infrastructure.

By contrast, the use of a Forward command in an MUA creates a brand new user 
message and adds the previous message to its body.  To stress the key point:  It 
is entirely a user-level activity.  The email infrastructure has nothing to do 
with it, other than the usual process of transferring a new message.  The MUA 
can add the forwarded message as in-line text, as part of a single, unified 
message body, or it can add it as an attachment (the message/rfc822, as 
mentioned earlier.)

A message that is re-routed by .forward is FROM the original author.  A message 
re-routed by an MUA is FROM the user of that MUA.

The "redirect" or "resend" MUA command attempts to perform something akin to the 
action of the .forward function, but the results usually are different and 
variable.  The concept of redirect is, really, to re-assign the message to an 
alternate recipient.  Therefore, the original FROM is preserved -- rather than 
having the FROM address be that of the recipient doing the redirecting, even 
though the user doing the re-directing might add a bunch to the message body, 
such as instructions for how the new recipient is to deal with the message. (The 
FROM field often shows some commentary text to indicate who did the redirecting. 
  There also are some resent-* header fields added.)

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Douglas Campbell <[email-masked]>
Date: Sun, 05 Feb 2006 16:59:41 -0800

Dave Crocker wrote:

> A message that is re-routed by .forward is FROM the original author.  
> A message re-routed by an MUA is FROM the user of that MUA.

Dave,

I understand the difference.  I question the reason for the difference, 
given that the current
MTA ".forward" mechanism and aliasing appear to stand in the way of 
allowing a
straightforward SPF implementation, particularly because the "original 
author" can be foreign to
the MTA doing the forwarding.  These problems appear to go away when 
"user-initiated" or MUA
forwarding is performed, because the author as specified in the envelope 
is then perceived as local
to the MTAs by both them and any foreign MTA which is a target of the 
forwarding.

I've gotten some e-mail indicating that because the .forward mechanism 
predates RFC-822,
it must be implemented the way it is.  I'm not sure I agree with that.  
I'd like to see an example
of why the .forward method as now implemented is better than the MUA 
method of wrappering
the forwarded materials in another envelope (with "local postage" 
applied, so to speak).  At the
present time, I don't see any advantage, and at least one disadvantage 
(it breaks simple SPF, requiring
a whole 'nuther layer of complexity).

Cheers,
Doug Campbell

---

From: Dave Crocker <[email-masked]>
Date: Sun, 05 Feb 2006 19:16:54 -0800

Doug,

> the MTA doing the forwarding.

I suggest that you have your causal concerns, or power relationships, reversed.

The problem is that SPF imposes an unreasonable restriction on long-established, 
highly reasonable uses of email.

In fact, this is the inherent difficulty with path registration schemes like SPF 
because it  requires that the 'author' authorize each path the message travels, 
to each recipient.  This is a variation on the theme of "source routing" and 
source routing does not scale.

The only scenario that SPF works for that is stable and scalable is for highly 
integrated services, where the user environment and the transfer service are 
under the same control and are quite stable.

In reality, this reduces SPF to a single-hop vetting between border gateways.

For that purpose, it is massively over-engineered.  (But then I am a tad biased, 
since CSV <http://mipassoc.org/csv/> targets only and exactly this limited 
scenario and accomplishes it much more simply.)

More generally, let me suggest that any proposal which begins by requiring that 
we get rid of reasonable scenarios is a proposal that is almost certainly deeply 
flawed.

> I've gotten some e-mail indicating that because the .forward mechanism 

822 is about headers.  821 is about transfer.  They came out in 1982.  .forward 
and related mechanisms predated that by some years.  Whether they predated 
RFC733 (19777) which was what rfc822 revised, I am not sure. I do not recall 
seeing a .forward mechanism back in 77, but it could easily have already been 
around.

But I'll suggest that none of this matters.  The .forward facility is a) a good 
idea, and b) entirely legal within all current standards.

> applied, so to speak).

My note described very substantial differences between the two.

In any event, it is always a bit challenging to change a long-established 
practice for a service in use by a billion people...

d/

-- 

Dave Crocker

---

From: der Mouse <[email-masked]>
Date: Mon, 6 Feb 2006 01:34:05 -0500 (EST)

>> I question the reason for the difference, given that the current MTA
>> ".forward" mechanism and aliasing appear to stand in the way of
>> allowing a straightforward SPF implementation, particularly because
>> the "original author" can be foreign to the MTA doing the
>> forwarding.

> The problem is that SPF imposes an unreasonable restriction on
> long-established, highly reasonable uses of email.

I submit that neither view is particularly helpful to reaching any sort
of workable resolution.

There is an incompatability between SPF and .forward-style forwarding;
I think everyone agrees on that.  SPF proponents see this as a problem
with .forward; opponents, a problem with SPF.  Neither view is
automatically "right".

> But I'll suggest that none of this matters.  The .forward facility is
> a) a good idea, and b) entirely legal within all current standards.

The same could have been said of open relays, when they first began to
be a problem.

This is not to say that I want to argue on either side.  I simply find
this line of argument unconvincing; I am presenting an opposing point
not because I oppose the conclusion but because I oppose the argument.

> In any event, it is always a bit challenging to change a
> long-established practice for a service in use by a billion people...

True.  I think the question we need to be asking is "is this, however
widespread and however longstanding, something we will ultimately be
forced to give up?".  If the answer is "no", we should try to find
antispam tactics that preserve it.  If the answer is "yes", we should
mentally give up on it now and figure out how to best manage the
(inevitable, in that case) transition.

I'm not convinced of either "yes" or "no" at this point.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 6 Feb 2006 08:01:31 -0500 (EST)

> > long-established, highly reasonable uses of email.

I expect that if (and I am not advocating it) the rejection of mail
because of SPF discrepancies becomes widespread, the operators of MTAs
doing so will offer their users the ability to register forwarders that
will be exempt for their own mail. That is, each user will be allowed to
specify one or more MTAs that can forward mail to that user without SPF
checks. This would enable .forward forwarding, without affecting mailing
lists or forwarding by MUAs.

One of the reasons that SPF is not widely yet used to reject mail, is that
that ability is not yet built into mail servers.

Daniel Feenberg

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 06 Feb 2006 15:12:46 +0100

der Mouse wrote:

> I submit that neither view is particularly helpful to
> reaching any sort of workable resolution.

Nobody is forced to publish SPF FAIL policies, and nobody
is forced to reject SPF FAIL, that's IMHO as "voluntary"
as possible.

When some of the SPF folks got carried away and discussed
to eliminate the "without MX try A" rule, or to enforce
"HELO must make sense" up to "IP-literal is always evil"
or other variations of "receiver policy" it didn't fly.

The S in SPF is for Sender, not reengineer SMTP from scratch.

> There is an incompatability between SPF and .forward-style
> forwarding;  I think everyone agrees on that.

Without reverse paths since about 1989 (RfC 1123), it used
to be fine before, when ".forward" also modified MAIL FROM.
Let MAIL FROM do what it says, and SMTP works as designed,
including 251-".forward".

> SPF proponents see this as a problem with .forward;
> opponents, a problem with SPF.  Neither view is
> automatically "right".

Maybe we could still agree that the SPF view is (1) older,
(2) treats MAIL FROM more verbatim, and (3) is based on the
literal meaning of "reverse path" / Return-Path.

The opposition claims that STD 10 was always bogus, and a
better name for MAIL FROM would be ERRORS TO.  That's like
Euclidean and non-Euclidean geometry, "right" or "wrong"
is not really the question,

SPF is an option, like 6.1 "enforced submission rights" in
PS 2476 and DS 2476bis.  PRA (Senderid) is _another_ option,
like 8.1 "MAY add Sender" in RfC 2476(bis).  Ignoring some
technical problems like Resent-* with the latter.

CSV is unrelated to 2821-From or 2822, it's more like a kind
of "single hop DKIM", without the huge 2822-overhead of DKIM.

The SPF HELO checks can roughly achieve the same effect as
CSV as side-effect of normal SPF checks.  And if a receiver
uses SPF only to check HELO it's also okay.  Above all SPF
is voluntary, "do what you like and cause no harm".

>> The .forward facility is a) a good idea, and b) entirely
>> legal within all current standards.

> The same could have been said of open relays, when they
> first began to be a problem.

> This is not to say that I want to argue on either side.  I
> simply find this line of argument unconvincing; I am
> presenting an opposing point not because I oppose the
> conclusion but because I oppose the argument.

The argument that CSV could replace SPF was already dubious;

CSV is an alternative to DKIM after reducing the problem to
the critical hops from original sender to initial receiver,
from initial receiver to next "251"-destination, and so on.

DKIM integrates this into "let any MON on the route sign
the message, and let any later MRN check this signature".

Or in other words DKIM is interesting if there's more than
one critical hop between signer and checker, otherwise its
overhead is beyond all reasonable limits:  There are much
simpler schemes like MTAMARK or CSV or SPF HELO to get a
grip on "legit mailer" (in combination with a white list).

It's a bit beyond me why folks bother with CSV, or SPF HELO,
or DKIM (sorted by potential overhead) if they could as well
use something as simple as MTAMARK (maybe in combination with
reliable DUL-lists, worst case their own private list).

Of course DKIM with STRONG signing policies is another matter
"phishing" in the muddy waters of PRA.  But "pure" DKIM is
much ado about nothing - more convenient for 251-forwarders
than SPF, less convenvient for mailing lists than SPF.  Where
PRA managed to combine both worst case scenarios... <sigh />

> I think the question we need to be asking is "is this,
> however widespread and however longstanding, something we
> will ultimately be forced to give up?".

Give up on "the originator as indicated in the Return-Path" ?
That would kill several RfCs starting from 2821 up to 3834.

                        Bye, Frank

---

From: Claus Assmann <[email-masked]>
Date: Mon, 6 Feb 2006 07:56:12 -0800

> to be fine before, when ".forward" also modified MAIL FROM.

Ok, you are writing this again and again, so here's a question:

Can you explain how you deal with the problems of "reverse path",
e.g., unauthorized relaying?

You are certainly aware of those problems -- that's why the SPF
proponents proposed SRS -- so what's your solution?

---

From: der Mouse <[email-masked]>
Date: Mon, 6 Feb 2006 11:53:48 -0500 (EST)

>> I think the question we need to be asking is "is this, however
>> forced to give up?".

Well, I meant ".forward-style forwarding", by which I mean, forwarding
such that when A sends mail to B, which forwards to C, then B's
mailserver accepts the A->B transaction and generates a new SMTP
transaction to C, with the same MAIL From as the first hop but a new
RCPT To.  (Whether B informs A of this with a 251 is mostly irrelevant,
especially since I know of no common MTA software that pushes the 251
back to the user when it's A in that case.)

If that's what you meant by "the originator as indicated in the
Return-Path", well, then, "yes".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Feb 2006 11:13:40 -0800

> The argument that CSV could replace SPF was already dubious;

Rather than compiling huge address lists for all possible paths as  
with SPF, CSV, in conjunction with a forward PTR list of "authorized"  
domains within some message field, easily supplants the SPF  
approach.  This changes the maximal number of published records from  
112 down to 2, where in many cases one record lookup would be  
enough.  A CSV and forward PTR strategy is not bound by DNS response  
size which allows unlimited scaling.  This approach does not require  
specialized string parsing for CIDR notation, macro expansions,  
includes, redirects, or exists.

> CSV is an alternative to DKIM after reducing the problem to the  
> critical hops from original sender to initial receiver, from  
> initial receiver to next "251"-destination, and so on.

With DKIM, the message envelope is not included within the  
signature.  This independence is essential for store-and-forward,  
especially within heterogeneous name space.  With privacy concerns,  
especially related to spam, silently forwarding changes will likely  
be considered important.  The message envelope is independent of the  
DKIM signature, so the signing-domain must not be held accountable  
for the destination, the return-path, or the overall number of  
messages sent using the same signature.

Some may wish to trust the signing-domain to verify "originating"  
header fields within the signed portion of the message, and use this  
assumption to hold the "originating" email-address culpable.  This  
culpability may be considered "confirmed" when email-address policies  
records associate the signing-domain.  Using DKIM to hold either an  
email-address or the signing-domain accountable requires stringent  
control of message content.  Such control is not practical for most  
domains.  Getting sloppy about culpability also ensures only large  
domains remain viable.

While DKIM may prevent the initial source of a message from being  
spoofed, most reputation systems attempt to judge governance of a  
domain by a percentage of good/bad messages.  With DKIM, the  
assessment of bad depends upon the evaluation of just the message  
content that can not be quantified.  This evaluation would need to  
check for invalid header fields, criminal message content, or perhaps  
deceptive links.  This type of assessment is resource intensive, to  
say the least.

DKIM could reduce the expense related to monitoring for abuse by  
having the signing-domain indicate which messages are from vetted  
sources.  Any exceptional handling based upon the validation of a  
DKIM signature should also be limited to just those vetted sources.   
With DKIM, an inordinate amount of abuse can be generated from  
unvetted sources, which could easily overwhelm monitoring.  It would  
not be practical for monitoring to depend upon undefined email- 
address verifications by the signing-domain and then separately rank  
an unlimited number of email-addresses.

> DKIM integrates this into "let any MON on the route sign the  
> message, and let any later MRN check this signature".

The overhead processing signatures will not be insignificant.  This  
will become more apparent as SHA-1 is replaced with SHA-256 or keys  
greater than 1024 bits are used.  The stacking of signatures will  
likely represent a growing DoS concern.  A strategy that overlays or  
removes signatures (perhaps changing the signature header name to  
permit header inclusion) may be desirable.

> Or in other words DKIM is interesting if there's more than one  
> critical hop between signer and checker, otherwise its overhead is  
> beyond all reasonable limits:  There are much simpler schemes like  
> MTAMARK or CSV or SPF HELO to get a grip on "legit mailer" (in  
> combination with a white list).

Agreed.  A lightweight verification of the sending machine will help  
defend schemes like DKIM, that assist in overcoming some routing  
exploits.

> It's a bit beyond me why folks bother with CSV, or SPF HELO, or  
> DKIM (sorted by potential overhead) if they could as well use  
> something as simple as MTAMARK (maybe in combination with reliable  
> DUL-lists, worst case their own private list).

Perhaps network providers are keen to avoid spam related issues.  A  
forward lookup represents less administrative effort as well, which  
is why CSV seems to be a good approach.  CSV is not ambiguous about  
the purpose of the record.  Your example of the SPF not.example.com  
demonstrated what _not_ to do with SPF.  This example produces  
unexpected exposures, lost in the complexity of the syntax.

> "phishing" in the muddy waters of PRA.  But "pure" DKIM is much ado  
> about nothing - more convenient for 251-forwarders than SPF, less  
> convenient for mailing lists than SPF.  Where PRA managed to  
> combine both worst case scenarios... <sigh />

The use of DKIM should be seen as a means to raise the level of trust  
for some transactional email.  DKIM will reduce the false positive  
detections with phishing related filtering.  Policy records offer no  
significant assistance, as there should be no reliance upon an email- 
address not being spoofed in the exploit, or that the recipient can  
recognize a look-alike.  There could be efforts to purchase thousands  
of look-alike domains and publish records indicating those domains do  
not sign messages.  It would be cheaper and safer to make a list of  
domains that have retained their trustworthy status, and mark those  
messages accordingly.  This also underscores the need to note which  
DKIM signatures are from a vetted source to both increase the safety  
of this assurance, and to minimize the resources consumed.

DKIM can also allow individuals recipients to locally make their own  
"trusted" lists to aid their effort avoiding being spoofed.  This  
would assume such recipient would use some out-of-band method to  
verify the source.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 06 Feb 2006 20:25:06 +0100

der Mouse wrote:

> Well, I meant ".forward-style forwarding", by which I mean,
> forwarding such that when A sends mail to B, which forwards
> to C, then B's mailserver accepts the A->B transaction and
> generates a new SMTP transaction to C, with the same MAIL
> From as the first hop but a new RCPT To.

In other words 1123 5.3.6(a) with an unmodified MAIL FROM.

> If that's what you meant by "the originator as indicated
> in the Return-Path", well, then, "yes".

The bit about "the originator as indicated in the Return-Path"
was supposed to be a RfC 2821 quote, but I got it wrong, it's:

| If an SMTP server has accepted the task of relaying the mail
| and later finds that the destination is incorrect or that the
| mail cannot be delivered for some other reason, then it MUST
| construct an "undeliverable mail" notification message and
| send it to the originator of the undeliverable mail (as
| indicated by the reverse-path).

And yes, I think we must keep this MUST as is, and therefore we
can't keep 1123 5.3.6(a) as is, in a world with forged "reverse
paths" everywhere this causes havoc for innocent bystanders.

                              Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 06 Feb 2006 21:02:47 +0100

Claus Assmann wrote:

> Can you explain how you deal with the problems of "reverse
> path", e.g., unauthorized relaying?

In the one case I've personally seen it was a "551 emulation",
already discussed here, I simply sent the mail again directly,
bypassing the 5.3.6(a) forwarder.

My ISP "offers" a MAIL FROM alias not covered by their SPF FAIL
sender policy - so far I never needed it in practice.  Actually
this alias always existed, this "feature" is unrelated to their
later introduction of SPF FAIL for their "normal" addresses.

> You are certainly aware of those problems -- that's why the
> SPF proponents proposed SRS -- so what's your solution?

If receivers don't address it at the forwarder (e.g. with SRS)
they have to address it at the next hop (e.g. white list the
forwarder), if that next hop otherwise rejects SPF FAIL.

If they do nothing at all, but test SPF behind their border it
generally can't work, SPF lists the sending IPs of the original
sender.  This set of "permitted" IPs normally won't include IPs
of any forwarders (starting with the IPs of the MXs).

How they do it depends on their situation.  In the worst case
they do nothing and won't receive forwarded mails.  Publishers
of SPF FAIL are happy to get a single "551 emulation" in months
instead of hundreds of bogus bounces daily - TINSTAAFL.

Mail providers wishing to support this could offer to "white
list" 5.3.6(a)-forwarders per user.  They could "white list"
5.3.6(a)-forwarders globally for all users.  They could use
a global list like <http://trusted-forwarder.org>.  They could
ignore this issue, simply "reject SPF FAIL" works as designed.

That's all discussed in chapter 9.3 of the SPF spec., see also
http://tools.ietf.org/html/draft-schlitt-spf-classic#section-9

                          Bye, Frank
P.S.:
If your question was about how it used to work before RfC 1123:
STD 10 offered 551 as alternative for 251.  It made no sense to
relay mail if they have no clue how to report errors later, the
bounces would queue up.  As stated for 251-forwarding in 821:

| The receiver takes responsibility for delivering the message.

Obviously the receiver is then also responsible to report errors
to the original MAIL FROM (i.e. to the RCPT TO of a bounce after
it reached the 251-forwarder).  Where that's impossible use 551.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Feb 2006 17:14:27 -0800

> paths" everywhere this causes havoc for innocent bystanders.

Replacing the return-path in every case when modifying recipients is  
rather complex.  In the event of auto-responses with a return-path,  
messages sent to this new return-path will require that the recipient  
be modified to that of the original return-path, and the current  
return-path be changed as well.  It would seem not having the ability  
to copy the return-path when changing RCPT TO parameters makes for a  
high level of complexity.

This unfortunate MTA now needs to track modified return-paths going  
both directions.  The number of these addresses tracked would not  
scale like that of a one-person list-server.  There are not  
subscriptions constraining the range of addresses being handled.   
This auto-response scenario often represents a fair amount of  
traffic.  Of course, this assumes that the return-path can be  
qualified before being processed.  Assume a EHLO verification is  
within the domain of the return-path.  When it is not, a forward  
lookup of a PTR record could return a list of acceptable EHLOs for  
this return-path.  This verifies both the EHLO, and, by adding one  
more lookup in the odd case, the return-path is validated as well.

This return-path replacement could be accomplished using a compressed/ 
encrypted return-path, a nested/signed return-path embedded within  
the new local-part, or a local-part as a randomized index into a  
table of original return-paths.  A table index approach allows  
determinant sized local-parts.  The nested/signed return-path  
requires syntactical conventions be adopted for this to be  
beneficial.  While table entries could be purged after a period of  
inactivity, the size of this table could grow to be extremely large  
and would need to be a shared resource within the domain making this  
a security problem at least.  The compressed/encrypted or nested/ 
signed schemes could overflow the local-part capacity, although this  
problem is not likely.  The compressed/encrypted approach would  
likely be the fastest technique.

-Doug

---

From: der Mouse <[email-masked]>
Date: Tue, 7 Feb 2006 03:43:37 -0500 (EST)

>> [...SPF vs .forward...]
> scale like that of a one-person list-server.

I just noticed: TCP:NAT::email:this.

Of course, it's not a perfect analogy, but I see a lot of the same
issues cropping up.  And things like DK are IPSEC AH....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign