Mailing List Archive

On Wed, 2004-02-25 at 15:10, mw-list-srs-discuss@csi.hu wrote:

> Of course, the situation can be worse, if the bounce contains a virus,
> since it avoids going through VIRUS_FILTER_FOR_DEST, and hence may
> deposit a virus in ORIG.

I don't see a problem bouncing a virus BACK to the very place it
originated from since its ALREADY infected.

Cheers,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

mw-list-srs-discuss@csi.hu <mw-list-srs-discuss@csi.hu> [2004-02-25/17:10]:
> It assumes that a relay service is not only willing to relay messages
> from a domain, but relay back bounces to the domain.

No.

> ORIG -> SPAM_FILTER_FOR_ORIG -> DEST

In this case, SPAM_FILTER_FOR_ORIG is an authorized sender for ORIG's
domains, and thus ORIG must add SPAM_FILTER_FOR_ORIG to ORIG's SPF
record. There is no need for SPAM_FILTER_FOR_ORIG to rewrite the
addresses.

> DEST -> VIRUS_FILTER_FOR_DEST -> ORIG

In this case, SPAM_FILTER_FOR_DEST is an authorized sender for DEST's
domains, and thus DEST must add SPAM_FILTER_FOR_DEST to DEST's SPF
record. There is no need for SPAM_FILTER_FOR_DEST to rewrite the
addresses.

> Now the original message sent to DEST bounces. According to SRS, it
> has to go through the route
>
> DEST -> SPAM_FILTER_FOR_ORIG -> ORIG

No. According to your scenario, DEST routes all outbound mail through
his outbound spamfilter, so the message will travel like this, if
SPAM_FILTER_FOR_ORIG uses SRS:

DEST -> SPAM_FILTER_FOR_DEST -> SPAM_FILTER_FOR_ORIG -> ORIG

Normally, SPAM_FILTER_FOR_ORIG would just be a designated sender for
ORIG, so there would be no need to do SRS, and thus you get:

DEST -> SPAM_FILTER_FOR_DEST -> ORIG

Which coincides with the route normal non-bounces take according to your
scenario.

> In particular, the spam filtering company hired by ORIG would have to
> accept bounces from DEST---a strange requirement for such a service:
> accept bounces from _anywhere_ though all it was supposed to do is
> filter messages from _selected_ clients.

There is no such requirement, as there is no need to do SRS either.

> Of course, the situation can be worse, if the bounce contains a virus,
> since it avoids going through VIRUS_FILTER_FOR_DEST, and hence may
> deposit a virus in ORIG.

It does not avoid going through VIRUS_FILTER_FOR_DEST.

But anyhow, I think this is a highly unusual scenario -- usually you
filter inbound mail or both, but not just outbound mail. Filtering
outbound mail is tricky anyway, you need to transparently intercept all
SMTP connections for it to work.

I might have misunderstood your scenario, so please correct me if I'm
wrong on this.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Thu, Feb 26, 2004 at 08:41:30PM -0800, James Couzens wrote:
> On Wed, 2004-02-25 at 15:10, mw-list-srs-discuss@csi.hu wrote:
>
> > Of course, the situation can be worse, if the bounce contains a virus,
> > since it avoids going through VIRUS_FILTER_FOR_DEST, and hence may
> > deposit a virus in ORIG.
>
> I don't see a problem bouncing a virus BACK to the very place it
> originated from since its ALREADY infected.

Who said the original message contained a virus. I said, the bounce
contains a virus. But you can replace virus by spam, or anything you
want. The point is that SRS forces a server which, in the present
system, accepts mail only from selected clients to accept mail from
the rest of the world.

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, Feb 27, 2004 at 05:00:18PM +0100, Daniel Roethlisberger wrote:
> mw-list-srs-discuss@csi.hu <mw-list-srs-discuss@csi.hu> [2004-02-25/17:10]:
> > It assumes that a relay service is not only willing to relay messages
> > from a domain, but relay back bounces to the domain.
>
> No.
>
> > ORIG -> SPAM_FILTER_FOR_ORIG -> DEST
>
> In this case, SPAM_FILTER_FOR_ORIG is an authorized sender for ORIG's
> domains, and thus ORIG must add SPAM_FILTER_FOR_ORIG to ORIG's SPF
> record. There is no need for SPAM_FILTER_FOR_ORIG to rewrite the
> addresses.

Going along with your idea: if SPAM_FILTER_FOR_ORIG decides to further
relay messages through another server, say RELAY, then, since SRS is
not happening on SPAM_FILTER_FOR_ORIG, ORIG also has to add RELAY to
its SPF record. And then, if RELAY decides to relay through RELAY1,
then ORIG has to add RELAY1 to its SPF records, etc.

So all these relays, owned by unrelated companies, would have to
communicate with ORIG about every decision they make (including
new IPs used by SPAM_FILTER_FOR_ORIG) so that they can avoid SRS.

To further highlight the difficulty in your suggestion: forwarding
happens much spontaneously. Indeed, what if, in the original setup,

ORIG -> SPAM_FILTER_FOR_ORIG -> DEST

, the recipient user at DEST decides to forward its mail by using an
entry in his .forward. Then ORIG immediately would have to put DEST
in its SPF record.

I thought SRS was invented to avoid exactly this impossible chaos.

But, please recall that this is the SRS and not the SPF list. I was
repeatedly told that SPF and SRS are to solve different problems.

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

mw-list-srs-discuss@csi.hu <mw-list-srs-discuss@csi.hu> [2004-02-27/12:51]:
> > > ORIG -> SPAM_FILTER_FOR_ORIG -> DEST
> >
> > In this case, SPAM_FILTER_FOR_ORIG is an authorized sender for
> > ORIG's domains, and thus ORIG must add SPAM_FILTER_FOR_ORIG to
> > ORIG's SPF record. There is no need for SPAM_FILTER_FOR_ORIG to
> > rewrite the addresses.
>
> Going along with your idea: if SPAM_FILTER_FOR_ORIG decides to further
> relay messages through another server, say RELAY, then, since SRS is
> not happening on SPAM_FILTER_FOR_ORIG, ORIG also has to add RELAY to
> its SPF record. And then, if RELAY decides to relay through RELAY1,
> then ORIG has to add RELAY1 to its SPF records, etc.
>
> So all these relays, owned by unrelated companies, would have to
> communicate with ORIG about every decision they make (including new
> IPs used by SPAM_FILTER_FOR_ORIG) so that they can avoid SRS.

I believe there is something like an include: feature in SPF, which
would effectively solve this administrative problem.

> To further highlight the difficulty in your suggestion: forwarding
> happens much spontaneously. Indeed, what if, in the original setup,
>
> ORIG -> SPAM_FILTER_FOR_ORIG -> DEST
>
> , the recipient user at DEST decides to forward its mail by using an
> entry in his .forward. Then ORIG immediately would have to put DEST
> in its SPF record.

No, not at all. DEST would have to use SRS on forwarded mail.

To summarize:
- Static mail routes/relays on outgoing mail: adjust SPF records
- Per user forwarding on incoming mail: do SRS

> I thought SRS was invented to avoid exactly this impossible chaos.

No, it was invented to unbreak forwarding in a forwarding-broken world.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, Feb 27, 2004 at 10:33:46AM -0800, James Couzens wrote:
> On Fri, 2004-02-27 at 10:19, mw-list-srs-discuss@csi.hu wrote:
> > > I don't see a problem bouncing a virus BACK to the very place it
> > > originated from since its ALREADY infected.
> >
> > Who said the original message contained a virus. I said, the bounce
> > contains a virus. But you can replace virus by spam, or anything you
> > want. The point is that SRS forces a server which, in the present
> > system, accepts mail only from selected clients to accept mail from
> > the rest of the world.
>
> Fair enough. But just how would someone create a bounce, including a
> virus, that will be successfully verified by HOSTB in a "SPAMMER forges
> bounce to HOSTB in the hopes of it reaching and infecting HOSTA
> scenario".

As I indicated, please concentrate on the main idea here: presently,
in the scenario

ORIG -> SPAM_FILTER_FOR_ORIG -> DEST

the relay SPAM_FILTER_FOR_ORIG has to accept SMTP connections _only_
from ORIG. But under SRS, it suddenly would have to accept
connections from the whole world. Does not this appear as at least a
slight extra complication in configuring and securing
SPAM_FILTER_FOR_ORIG?

More generally, but with a slight abuse of language: SRS demands that
every relay becomes bidirectional.

>
> Given that YES you accept mail with an SRS1 address and happily rewrite
> it, but that since its not a valid email, it will be simply deleted.
> Why would someone go to the effort of attempting to do that KNOWING
> their data is going nowhere?
>

I do not understand what you are saying: here comes a message
originating from ORIG, and deposited in DEST's mailbox which is
infected (or just got infected by a virus in the email). Now the
virus takes the envelope sender address, and sends itself to it
masquerading the enveloping email as a bounce. The _outgoing_ virus
filter of DEST will never see it, because SRS demands the bounce goes
back through its incoming route which contains no virus filter. Will
the "bounce virus" reach ORIG?

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

> [James Couzens]
> Fair enough. But just how would someone create a bounce, including a
> virus, that will be successfully verified by HOSTB in a
> "SPAMMER forges
> bounce to HOSTB in the hopes of it reaching and infecting HOSTA
> scenario".

By harvesting an outgoing message anywhere in transit and using the
SRS0-signed address in the return-path. This is a classic playback
attack and is one of the vulnerabilities of the current SRS scheme.


>
> Given that YES you accept mail with an SRS1 address and
> happily rewrite
> it, but that since its not a valid email, it will be simply deleted.
> Why would someone go to the effort of attempting to do that KNOWING
> their data is going nowhere?

Because if they have a valid SRS0-signed message, they can just put the
SRS0 part in the return path of any SRS1 message. As a DSN, it will
accepted with the forged SRS1 address, be rewritten with the valid SRS0
address and sent back to the original host, where it will be accepted.

>
> Are we on the same page or do I misunderstand? Is it
> possible you are
> suggesting that an infected or trojaned/hacked MTA might attempt to
> return bounces with a virus attached instead as opposed to
> the original
> content?

SRS does not protect message content, only the return-path. That is
what makes this exploit usable by spammers. As we cut off the direct
spamming route, they will be forced to resort to exploits such as this.

--

Seth Goodman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

mw-list-srs-discuss@csi.hu <mw-list-srs-discuss@csi.hu> [2004-02-27/13:15]:
> More generally, but with a slight abuse of language: SRS demands that
> every relay becomes bidirectional.

Not in all cases. Independant forwarders like pobox.com, yes. But not
designated relays like your virus scanning outbound relays.

A SRS relay must be allowed to SEND mail for the domain it rewrites to
(SPF record), but it does not have to be the same host which handles
inbound mail for that domain (MX record).

For more details, see my earlier reply to your original post.

Anyway, your scenario of only outbound virus scanners is fundamentally
broken in the way that those people need inbound virus scanners too if
they expect their mail to be virus free.

Cheers,
Dan

--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

In <20040227191526.GC12385@csi.hu> mw-list-srs-discuss@csi.hu writes:

> As I indicated, please concentrate on the main idea here: presently,
> in the scenario
>
> ORIG -> SPAM_FILTER_FOR_ORIG -> DEST
>
> the relay SPAM_FILTER_FOR_ORIG has to accept SMTP connections _only_
> From ORIG.

As mentioned previously, ORIG should simply list SPAM_FILTER_FOR_ORG
as being allowed to send email using ORIG's domain name. No other
changes would be needed.



> More generally, but with a slight abuse of language: SRS demands that
> every relay becomes bidirectional.

No, only untrusted relays. Relays within an organization's control
(and that includes external companies such as smart hosts, spam
filters, etc.), don't need to deal with SRS.




-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, 2004-02-27 at 11:21, Seth Goodman wrote:
> By harvesting an outgoing message anywhere in transit and using the
> SRS0-signed address in the return-path. This is a classic playback
> attack and is one of the vulnerabilities of the current SRS scheme.

Just how easy is that? I'd imagine thats not something average Joe
spammer is capable of? You'd have to be sitting on a compromised box
somewhere off my network to do something like, or have access over some
proxy. Wouldn't something like that get noticed and dealt with pretty
quickly, or am I not following you?

> Because if they have a valid SRS0-signed message, they can just put the
> SRS0 part in the return path of any SRS1 message. As a DSN, it will
> accepted with the forged SRS1 address, be rewritten with the valid SRS0
> address and sent back to the original host, where it will be accepted.

> SRS does not protect message content, only the return-path. That is
> what makes this exploit usable by spammers. As we cut off the direct
> spamming route, they will be forced to resort to exploits such as this.

Indeed. My primary curiosity, is just how easy would it be for someone
to come up with such an email without getting noticed or caught. It
just seems to fall into the "possible, yes, but likely no" category. If
this is an ignorant view I'm happy to be enlightened.

Cheers,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

In <1077913881.4234.87.camel@code3> James Couzens <jcouzens@obscurity.org> writes:

> On Fri, 2004-02-27 at 11:21, Seth Goodman wrote:
>> By harvesting an outgoing message anywhere in transit and using the
>> SRS0-signed address in the return-path. This is a classic playback
>> attack and is one of the vulnerabilities of the current SRS scheme.
>
> Just how easy is that?

Not hard at all. You need a list of email addresses that forward
email, for example pobox. You then use the knowledge that Yahoo will
block any sender that sends to too many invalid user names. You send
email with a forged SRS1 address to pobox customers. If they get
through to the final forwardered destination, the spammer wins by
getting spam through. If the email gets bounced, it will bounce
through pobox to yahoo and Yahoo will block pobox. In this case, the
spammer wins again by hurting a company with a strong anti-spam
policy.



> I'd imagine thats not something average Joe
> spammer is capable of?

Spammers have been sending with forged email return addresses for a
long time.


> Indeed. My primary curiosity, is just how easy would it be for someone
> to come up with such an email without getting noticed or caught.

It would be hard to catch the spammer. It would take a fair amount of
effort to detect that the attack is going on and stop it before the
damage is done.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, Feb 27, 2004 at 02:16:30PM -0600, wayne wrote:
> No, only untrusted relays. Relays within an organization's control
> (and that includes external companies such as smart hosts, spam
> filters, etc.), don't need to deal with SRS.

Who said the virus scanning service is in the company's control?

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

In <20040227210127.GD12385@csi.hu> mw-list-srs-discuss@csi.hu writes:

> On Fri, Feb 27, 2004 at 02:16:30PM -0600, wayne wrote:
>> No, only untrusted relays. Relays within an organization's control
>> (and that includes external companies such as smart hosts, spam
>> filters, etc.), don't need to deal with SRS.
>
> Who said the virus scanning service is in the company's control?


"Control" does not mean "ownership" or any such thing. As long as the
organization has contracted with the virus scanning service, the
organization controls whether they use them or not. If the virus
scanning service starts to send email using the organization's domain
name without permission, the organization can leverage to change
things, including probably terminating the contract.

No such control exists between an organization and many third-party
forwarders such as POBox.com.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

----- Original Message -----
From: <mw-list-srs-discuss@csi.hu>
To: <srs-discuss@v2.listbox.com>
Sent: Friday, February 27, 2004 8:15 PM
Subject: Re: [srs-discuss] A problem with SRS

> More generally, but with a slight abuse of language: SRS demands
> that every relay becomes bidirectional.

The argument seems, that one becomes not an open relay, because a spammer
cannot forge SRS1 an address which will also produce a valid SRS0 address.

But why relay at all? An open relay is simply this: "A host which, barring
local .forward functionality, relays mail to non-local recipients, from
non-authorized IP space." SRS1 falls into that category. If you send me a
valid SRS0 address, wrapped in a valid SRS1 recipient, then I am an open
relay; because I allow you, from an unauthorized IP space, to use my (E)SMTP
mailers to send mail to non-local recipients.

I am no SRS1 forwarding host; and plan not to become one, either. :) I
accept SRS1 addresses, when they resolve to valid, local SRS0 recipients;
that's all. To that effect, I even compiled a disclaimer into sendmail:

<<< 220-asarian-host.net ESMTP + SPF Sendmail 8.12.11/8.12.11; ...
<<< 220- Effective immediately: Asarian-host may no longer accept
<<< 220- connections from IP addresses which have no rDNS
<<< 220- (PTR record) assigned.
<<< 220- Effective immediately: Asarian-host no longer accepts
<<< 220- DSN recipients without valid SRS signature.
<<< 220 N.B. Asarian-host is no SRS1 forwarding host.
>>> EHLO asarian-host.net
<<< 250-asarian-host.net Hello localhost [127.0.0.1], pleased to meet you
<<< 250-ENHANCEDSTATUSCODES
<<< 250-PIPELINING
<<< 250-8BITMIME
<<< 250-SIZE 6291456
<<< 250-DSN
<<< 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
<<< 250-STARTTLS
<<< 250-DELIVERBY
<<< 250-X-SPF
<<< 250-X-SRS 0
<<< 250 HELP

Since SPF and SRS are essentitally SMTP Service Extensions, I also compiled
in two RFC1869 4.3 compliant SMTP Service Extensions:

<<< 250-X-SPF
<<< 250-X-SRS 0

The second one says: "I do SRS0, but I am no SRS1 forwarding host." A
forwarder, like pobox, for instance, might respond:

<<< 250-X-SRS 0 1

I know this, and the extended error codes, are probably not exactly on
people's list of highest priorities. Still, I think these matters deserve
some attention too.

Cheers,

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, Feb 27, 2004 at 08:07:27PM +0100, Daniel Roethlisberger wrote:
> mw-list-srs-discuss@csi.hu <mw-list-srs-discuss@csi.hu> [2004-02-27/12:51]:
> > > > ORIG -> SPAM_FILTER_FOR_ORIG -> DEST
> > >
> > > In this case, SPAM_FILTER_FOR_ORIG is an authorized sender for
> > > ORIG's domains, and thus ORIG must add SPAM_FILTER_FOR_ORIG to
> > > ORIG's SPF record. There is no need for SPAM_FILTER_FOR_ORIG to
> > > rewrite the addresses.
> >
> > Going along with your idea: if SPAM_FILTER_FOR_ORIG decides to further
> > relay messages through another server, say RELAY, then, since SRS is
> > not happening on SPAM_FILTER_FOR_ORIG, ORIG also has to add RELAY to
> > its SPF record. And then, if RELAY decides to relay through RELAY1,
> > then ORIG has to add RELAY1 to its SPF records, etc.
> >
> > So all these relays, owned by unrelated companies, would have to
> > communicate with ORIG about every decision they make (including new
> > IPs used by SPAM_FILTER_FOR_ORIG) so that they can avoid SRS.
>
> I believe there is something like an include: feature in SPF, which
> would effectively solve this administrative problem.

Could you remind me how the spf records would change if we start with

orig -> relay_1 -> dest

then the route changes to

orig -> relay_1 -> relay_2 -> dest

then to

orig -> relay_1 -> relay_2 -> relay_3 -> dest

Mate

--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com