Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. SPF>
  3. SRS
1 2 3  View All
Why SRS really sucks
j.steigenberger at admins
Mar 26, 2006, 6:09 PM
Post #1 of 70 (30647 views)
Permalink
This is to all Persons thinking SRS is usable.

I will show you with empirical logic that SRS really sucks.

1. SRS makes a good thing as SPF really useless.

Why?

We at UCEPROTECT-Network noticed an increasing of Spam and Phishingmails
claiming to be legal forwardet mail (with SRS) within the last days.
Worst on all, these faked Mails were delivered by well known providers.

Investigating this, we found, that those providers do not even check for
SPF-Records
and are accepting such crap, but then they are forwarding it with SRS !!!

They just do an SRS on all forwardet mail, only to have the mails out of
their queue :-(
No matter if an SPF-Record is set for the claimed sender domain or not ...
This actually begins to become wideley used practice.

Those providers should better check on mails to be forwardet, if the domain
has an
SPF-Record set, and if an SPF-Record persist, if it allows the provider to
send (forward) the mail.
If they found not to be autorized for doing so they could simply reject the
acceptance,
instead of accepting and forwarding them.

Why should an Domain owner set SPF-records for his Domain, if any idiot out
there
can (thanks to SRS) still fake to be a legal sender?

Do you really think you can trust anyone out there?

This means SPF is on the way to get useless (thanks to SRS).

2. SRS is absolute unnecessary.

Why ?

As a Domain owner i can choose, whatever i put into my SPF-Records.
So if i have a need, that my Mails may be forwardet by any Provider or i
have
a need that mails claiming to be from me can be sent by Ebay or Paypal,
it should not be a Problem to set an apropiate SPF-Record, which allows
forwarding by selected hosts or Domains.

I need no SRS for this if i really want my mail to get forwardet.
I only have to use my brian while setting my SPF-record

But if i choose that my mail should not be allowed to be forwardet, it is
also
my restriction ...

SPF stands for SENDER POLICY FRAMEWORK

So the real question must be:

Who do you think you are, that you can break a SENDER POLICY?

If i would be too stupid to set my SPF-Records in a way that they match my
needs,
it should logically be my problem not yours ....

This indicates SRS was made because of lamers out there not able to set
their
SPF-Records matching their needs :-)

Why do you risk, that SPF will go down, only to have some lamers not able to

set apropiate SPF-Records get their mail deliverd with a nonsense called
SRS?

People which do not want restrictions on their mail could easily choose not
to set
SPF-Records, or ever maching SPF-Records.

3. What is my personal suggestion?

Implementing SPF in software is cool (we also did it), but it really
sucks if you also implement SRS (we will never do it - not in this life !!!)


Furthermore we implemented in our default ruleset to block every mail which
is
identified to have an SRS envelope from.

Why ?

We consider anyone, who thinks he can ignore the domain owners restriction
as abuser.

I recommend to stop SRS, before more people and providers beginn fooling
around
with this nonsense.

IMO it is ony a question of time up till SRS will be widely abused ...
In some month you will probably find about 90% of all SRS Mails to be Spam /
Phishing / Viruses....

What will you do then?
Starting another foolish project to fix problems which you would not have
with SPF alone,
but you have them thanks to SRS?

Sorry for beeing very ironic, but i really hate, if people doing things that
are not consequent.

Telling people SPF breaks mailforwarding is only half the truth.
The complete truth is: SPF breaks unauthorized mailforwarding.
Thats the consequence of the policy, you can also call it a feature.
And finally: SRS breaks SPF.
Thats not a feature - it is inconsequence and therfore it should not exist.

Best Regards

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 26, 2006, 6:27 PM
Post #2 of 70 (30254 views)
Permalink
On Mon, 27 Mar 2006, Johann Steigenberger wrote:

> 1. SRS makes a good thing as SPF really useless.

> Investigating this, we found, that those providers do not even check for
> SPF-Records and are accepting such crap, but then they are forwarding it with
> SRS !!!

This shows that these "well know providers" are providing the equivalent
of an open-relay - and you should treat them as such. (But you
have a better idea below.)

> 2. SRS is absolute unnecessary.

You are mostly correct on that score.

> I need no SRS for this if i really want my mail to get forwardet.
> I only have to use my brian while setting my SPF-record

*And*, SPF checkers need to use their brain and not reject mail
from forwarders that they as a receiver have set up.

> 3. What is my personal suggestion?
>
> Implementing SPF in software is cool (we also did it), but it really
> sucks if you also implement SRS (we will never do it - not in this life !!!)
>
> Furthermore we implemented in our default ruleset to block every mail which
> is identified to have an SRS envelope from.
>
> Why ?
>
> We consider anyone, who thinks he can ignore the domain owners restriction
> as abuser.

This is a reasonable policy - except for one very important thing.
While SRS for forwarding is only needed for braindead SPF recipients,
SRS is *very* useful for "signing" MFROM to eliminate "bounce spam" -
spam with an empty mail from that is not a bounce of anything you sent
(even though that was not the original purpose of SRS).

You can tell when SRS is used in this mode because the two domains are the
same - or else the original domain is empty.

> I recommend to stop SRS, before more people and providers beginn fooling
> around with this nonsense.

The premise of the 'block SRS' policy is that SRS should never be
used for "outgoing" mail from a domain. It should only be used to
deliver forwarded mail. Therefore, if you receive an SRS MFROM
that is

a) not a signature (both domains same or one empty)

and

b) not from a forwarder that you as a receiver have configured

then it is spam and should be rejected.


Anyone see a problem with these assumptions? Is SRS ever legitimate
for anything other than receiver requested forwarding or MFROM signing?

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 26, 2006, 7:03 PM
Post #3 of 70 (30251 views)
Permalink
>a) not a signature (both domains same or one empty)
>
>and
>
>b) not from a forwarder that you as a receiver have configured
>
>then it is spam and should be rejected.
>
>
>Anyone see a problem with these assumptions? Is SRS ever legitimate
>for anything other than receiver requested forwarding or MFROM signing?

Not good enough. "Signatures" can be for virtualized domains, where
the virtual domain and the local domain of the mail host will both
appear in the signature.


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 26, 2006, 9:03 PM
Post #4 of 70 (30197 views)
Permalink
> Not good enough. "Signatures" can be for
> virtualized domains, where the virtual
> domain and the local domain of the mail
> host will both appear in the signature.

I should have also said that any email, whether SRS signed or not, is
subject to RFC 2821 and 2822. One of these documents (I can look it up
later when I'm at my full computer and not a PDA) says that only a mail host
for the domain in the envelope address can assign any semantics at all to
the local part. Which means: if you detect SRS signatures in the local part
and drop mail, then you are violating RFC. You should treat SRS signed mail
exactly as you would any other mail from the domain in the domain part of
the envelope.

-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
j.steigenberger at admins
Mar 27, 2006, 2:28 AM
Post #5 of 70 (30272 views)
Permalink
> Which means: if you detect SRS signatures in the local part
> and drop mail, then you are violating RFC.

You are right and we know that.

Trust me, we normally act RFC compliant whereever this makes sense.

But if we find something which is contraproductive, and there is no other
way to circumvent the problem, we are (from time to time) violating RFCs.

Example:

A Server connects to us and tries to deliver mail to multiple recipients.
S = Sending server
R = Recipient System

As soon as S hits a Spamtrap on R we simply drop him, we are also violation
RFCs
by acting as follows:

Connection to UCEPROTECT-Server established.
R: 220 recipientdomain SMTP ready.
S: HELO anything :-)
R: 250 Ok
S: mail from: anything@faked
R: 250 Maybe OK
S: rcpt to: validuser1@recipeientsystem
R: 250 OK (by Policy)
S: rcpt to: spamtrap@recipientsystem
R: 571 Game over. Your IP is now blacklisted
R: 421 Hasta la vista ...
Connection dropped by UCEROTECT-Server

This really makes sense.

Beeing RFC conform would mean to act like this:

Connection established.
R: 220 recipientdomain SMTP ready.
S: HELO anything :-)
R: 250 Ok
S: mail from: anything@faked
R: 250 Maybe OK
S: rcpt to: validuser1@recipeientsystem
R: 250 OK (by Policy)
S: rcpt to: spamtrap@recipientsystem
R: 550 I know you are a Spammer but RFCs force me to be fooled by you ...
S: rcpt to: nextvalidrecipient@recipientsystem
R: 250 OK (i dont like it but im conform to RFCs)
S: DATA
and so on ... resulting the Spam will be delivered to your valid recipients
..

This makes no sense, but is conform to RFCs :-)

So you see it is not always good to follow RFCs ...

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net



-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 27, 2006, 5:20 AM
Post #6 of 70 (30342 views)
Permalink
On Sun, 26 Mar 2006, Tom Lahti wrote:

> I should have also said that any email, whether SRS signed or not, is
> subject to RFC 2821 and 2822. One of these documents (I can look it up
> later when I'm at my full computer and not a PDA) says that only a mail host
> for the domain in the envelope address can assign any semantics at all to
> the local part. Which means: if you detect SRS signatures in the local part
> and drop mail, then you are violating RFC. You should treat SRS signed mail
> exactly as you would any other mail from the domain in the domain part of
> the envelope.

a) There was no proposal to "drop" mail - only to reject it (via 5xx).
You are allowed to refuse mail for local policy reasons and
provide an explanation via the 5xx message. E.g.

550 5.7.1 The example.com domain has become an open relay via SRS abuse

b) When a domain is abusing SRS to the point of clogging your
quarantine, my choices (and any other admin dealing with
40000+ forged emails to a 6 person office) are to reject *all*
mail from the domain, or heuristically try to reject only the mail
they are abusing.

> > Not good enough. "Signatures" can be for
> > virtualized domains, where the virtual
> > domain and the local domain of the mail
> > host will both appear in the signature.

I'm not sure what you mean here. Is this a limitation with some
SRS implementations? For instance, here is a config with virtual
domains and signing:

[srs]
secret = "don't you wish"
fwdomain = hostdomain.com
sign = hostdomain.com, virtual1.com, sub.domain.com
maxage=8
hashlength=8

The virtual domains are signed for outgoing mail just the same as the
forwarding domain, and look like this:

SRS0=4Jl0EjKl=5S==carlos@hostdomain.com
SRS0=/aZCHAFV=5R==wendy@virtual1.com

or like this:

SRS0=4Jl0EjKl=5S=hostdomain.com=carlos@hostdomain.com
SRS0=/aZCHAFV=5R=virtual1.com=wendy@virtual1.com

Are you saying that some implementations don't explicitly support
SRS signing, and we get this instead for the virtual domain?

SRS0=uTwRdA+E=5R=virtual1.com=wendy@hostdomain.com

Even for those implementations, you just need to have a separate
SRS config for each virtual domain.

However, the "reject SRS" policy that was proposed should probably apply only
to specific domains that were abusing SRS - at least until the
distinction between SRS "signing" and "forwarding" is more widely
understood.

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
dwmw2 at infradead
Mar 27, 2006, 5:43 AM
Post #7 of 70 (30204 views)
Permalink
On Mon, 2006-03-27 at 04:09 +0200, Johann Steigenberger wrote:
> And finally: SRS breaks SPF.

Yes. But SRS is the natural reaction to SPF, on the part of the many
people out there who just don't care about SPF, or who think it is
entirely broken in the first place. Something like SRS is _necessary_
because forwarding _does_ happen in the real world. Those people have
implemented SRS because they think it's the best option for them, to
work around the breakage which SPF has caused. That was always expected.

I've always said that as soon as SRS became common, SPF would be
entirely defeated. Thanks for making that point so well.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 27, 2006, 6:42 AM
Post #8 of 70 (30275 views)
Permalink
On Mon, 27 Mar 2006, David Woodhouse wrote:

> On Mon, 2006-03-27 at 04:09 +0200, Johann Steigenberger wrote:
> > And finally: SRS breaks SPF.
>
> Yes. But SRS is the natural reaction to SPF, on the part of the many
> people out there who just don't care about SPF, or who think it is
> entirely broken in the first place. Something like SRS is _necessary_
> because forwarding _does_ happen in the real world. Those people have
> implemented SRS because they think it's the best option for them, to
> work around the breakage which SPF has caused. That was always expected.

If they really "just didn't care" about SPF, then there would be
no need for SRS. It is only needed by forwarders because of clueless admins
who reject mail based on SPF - yet make no provision for the forwarders they or
their customers have themselves configured.

And even when SRS is abused, SPF is still fulfilling its promised
function - to keep MFROM domain owners responsible for the mail they send.
When a domain abuses SRS by forwarding to all and sundry (not just those
who asked for it), it becomes an open relay. They need to be treated just
like plain open relays were last decade - only we can be a little more
merciful because of the additional control provided by SPF.

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
j.steigenberger at admins
Mar 27, 2006, 7:30 AM
Post #9 of 70 (30215 views)
Permalink
> *And*, SPF checkers need to use their brain and not reject mail
> from forwarders that they as a receiver have set up.

Exactley. They have to make exceptions for their own forwarding service ...
They can not expect others to break sender policys too, only to compensate
their clueless

> This is a reasonable policy - except for one very important thing.
> While SRS for forwarding is only needed for braindead SPF recipients,
> SRS is *very* useful for "signing" MFROM to eliminate "bounce spam" -
> spam with an empty mail from that is not a bounce of anything you sent
> (even though that was not the original purpose of SRS).

There are more easy way to deal with faked bounces.
If you have for e.G a good policy, those will not impact on you ...
Think about this:
What will never be in an authentic bounce?
Links to remote hosted pictures, HTML, Non English charsets ....
Those could be found in an attached message but not in the bounce itself
Should i continue ?
Anything which claims to be an NDR and contains such crap will
logically not be a bounce, simply reject or discard it :-)

You do not need SRS to deal with that :-)

>The premise of the 'block SRS' policy is that SRS should never be
>used for "outgoing" mail from a domain. It should only be used to
>deliver forwarded mail. Therefore, if you receive an SRS MFROM
>that is

My point of view is that it should NOT be used for anything.

It breakes SPF. And this is the Problem.

Accept that SPF is a thing usefull for experts and not for lamers.
So why supporting lamers with something like SRS?
There is no thing that does the job right for all.

Domainowners are the only People which have the right to decide,
what is allowed on their domains.
If Users of those Domains can not live with Domainowners decision,
they should probably register their own Domains :-)

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
julian at mehnle
Mar 27, 2006, 8:09 AM
Post #10 of 70 (30214 views)
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On srs-discuss, Johann Steigenberger wrote:
> [...]
> SRS makes a good thing as SPF really useless.
>
> Why?
>
> We at UCEPROTECT-Network noticed an increasing of Spam and
> Phishingmails claiming to be legal forwardet mail (with SRS) within the
> last days. Worst on all, these faked Mails were delivered by well known
> providers.
>
> Investigating this, we found, that those providers do not even check for
> SPF-Records and are accepting such crap, but then they are forwarding it
> with SRS !!!
>
> They just do an SRS on all forwardet mail, only to have the mails out of
> their queue :-(

- From a receiver's POV there is just no meaningful difference between
"forwarding" and "originally sending" mail. Some misguided RFCs and their
advocates may be telling you otherwise, but it just ain't true. Nobody
except the sender can know whether a mail was forwarded or originally sent
by the sending host.

The difference between forwarders rewriting the sender address (using SRS
or other schemes) and forwarders not doing it is that the former accept
responsibility (to their domain) for the mail they send and the latter
don't (blaming responsibility on the supposed original sender domain).
SPF prevents forwarders (and other senders) from blaming responsibility on
others.

Sender rewriting is indeed a good thing for forwarders to do. It does in
no way circumvent SPF, which is not meant as an anti-spam solution, just
as an anti-forgery solution, and SPF-protected domains can't be forged in
the envelope sender, not even using SRS.

It is true that forwarders should do SPF checking, especially those doing
sender rewriting. If they don't, and essentially forward (=send!) any
crap that someone inputs into their system, then they (i.e. their domains)
deserve to get a bad reputation!

You speak of "well known providers". Have you tried contacting them and
telling them that not checking for SPF, spam, etc. when forwarding is
going to discredit their domains?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKA4pwL7PKlBZWjsRAs7ZAKCZWrMif/ThInTOReVxaHs95qLIgACdHhEx
RZ9Ec1j0Cwb56RqN3XzyjyM=
=qObx
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 27, 2006, 9:17 AM
Post #11 of 70 (30242 views)
Permalink
On Mon, 27 Mar 2006, Johann Steigenberger wrote:

> There are more easy way to deal with faked bounces.
> If you have for e.G a good policy, those will not impact on you ...

Only if every MTA in the world correctly implements SPF. MFROM
signing (via BATV or SRS or SES) is for mail bounced from MTAs
that *don't* check SPF.

> Think about this:
> What will never be in an authentic bounce?
> Links to remote hosted pictures, HTML, Non English charsets ....
> Those could be found in an attached message but not in the bounce itself
> Should i continue ?

Apparently, you've never encountered bounce spam.

> Anything which claims to be an NDR and contains such crap will
> logically not be a bounce, simply reject or discard it :-)

But this is heuristic decision. By signing MFROM, you have a
solid mechanical means of discarding fake NDRs.

> My point of view is that it should NOT be used for anything.
>
> It breakes SPF. And this is the Problem.

SRS is also fine when legitimately forwarding mail. It is simply a
way for a 3rd party forwarder and the recipient to work together
with no special configuration required for the recipient. Of course,
if the forwarder doesn't check SPF, there is no point in the recipient
doing so either...

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 9:50 AM
Post #12 of 70 (30287 views)
Permalink
>You are right and we know that.
>Trust me, we normally act RFC compliant whereever this makes sense.

RFC's weren't made for you to break whenever you feel like it. If
that is their purpose, then why have them at all? The reason for
RFC's is so that one can have _some_ basis for knowing what other
systems will do. "You are right and we know that" means: RFC's are
useless for determining what another domain will do with a piece of
mail, while at the same time pretending to "conform to them in most
cases". This isn't a matter of degree, its all-or-nothing. You're
either compliant, or you're not.

>But if we find something which is contraproductive, and there is no other
>way to circumvent the problem, we are (from time to time) violating RFCs.
>
>Example:

[snip] Your example is worthless and not a representative example of
the type of traffic being discussed. The RFC (and I in my previous
mail) said that an MTA cannot assign semantics to the local part
UNLESS THE ADDRESS IS THE MTA'S OWN DOMAIN. This means your example
is perfectly legitimate mail handling, and also means it has nothing
to do with SRS signing from a separate domain. Basically, we're
talking about MAIL FROM:, not RCPT TO:.

What do you do in this case (using your own pseudo-SMTP)?

Connection to UCEPROTECT-Server established.
R: 220 recipientdomain SMTP ready.
S: HELO anything :-)
R: 250 Ok
S: mail from: SPAMTRAP@senderdomain

What comes next? Will you reject this mail? Can you be certain it
is not a valid email?

My point is that in the MAIL FROM: your MTA has NO BUSINESS
WHATSOEVER determining what meanings may be encoded in the local part
of the address. When looking at the MAIL FROM:, your MTA _must_
consider ONLY the domain part of the address.


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
j.steigenberger at admins
Mar 27, 2006, 9:59 AM
Post #13 of 70 (30208 views)
Permalink
> Yes. But SRS is the natural reaction to SPF, on the part of the many
> people out there who just don't care about SPF, or who think it is
> entirely broken in the first place.

A natural reaction should be to think about twice about consequences,
before implementing something without using the brain, and then clamining
the thing is broken... :-)

> Those people have implemented SRS because they think it's the best option
for them, to
> work around the breakage which SPF has caused. That was always expected.

Logically, it is the best thing for THEM, they have their crap out of their
queue, resulting
they have not to deal with idiots (their customers) who mostly can not count
from 0 to 1,
and think they must use each thing what is available for free on the web,
mostly
without reading the f... manual ...

We know this type of user, but we are every day newly surprised by them,
once again ;-)

> I've always said that as soon as SRS became common, SPF would be
> entirely defeated. Thanks for making that point so well.

This was the reason for me to open that thread.
I want to prevent SPF to become useless.

I´m known to be a hardliner. I hate spammers and this implements i hate
email forgery.
Every technics that makes it easier for spammers is therefore evil, no
matter what the
intention was, which did lead to its existence.

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net






-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 10:00 AM
Post #14 of 70 (30242 views)
Permalink
>a) There was no proposal to "drop" mail - only to reject it (via 5xx).
> You are allowed to refuse mail for local policy reasons and
> provide an explanation via the 5xx message. E.g.

By "drop" I meant "not deliver". Rejecting mail based on the local
part of the MAIL FROM: is a violation of RFC just as much as dropping
it. When your boss doesn't get my very important SRS signed email,
be prepared to explain to him why you are violating RFC, because I
will be prepared to explain to him that you are and what that means.

> 550 5.7.1 The example.com domain has become an open relay via SRS abuse

Yes, that's fine if the implementation does not automatically detect
SRS signing in the local part and start rejecting mail based only on
that criteria. If SRS is implemented improperly then certainly its
valid to reject the entire domain (but note: regardless of the local
part of MAIL FROM: coming from that domain).

>b) When a domain is abusing SRS to the point of clogging your
> quarantine, my choices (and any other admin dealing with
> 40000+ forged emails to a 6 person office) are to reject *all*
> mail from the domain, or heuristically try to reject only the mail
> they are abusing.

The former is your only RFC-compliant alternative. If you
heuristically try to reject only the mail they are abusing, its is
[a] a violation of RFC, and [b] allows the abuser to continue what
he's doing, shifting the burden of his own administration onto those
trying to sort out his garbage. The right thing to do is to force
him to sort out his own garbage but rejecting the whole domain until
he fixes it.

>Are you saying that some implementations don't explicitly support
>SRS signing, and we get this instead for the virtual domain?
>
>SRS0=uTwRdA+E=5R=virtual1.com=wendy@hostdomain.com

That's exactly what I'm saying. In this case the receiving MTA
should treat this MAIL FROM: the same as it would for any in
hostdomain.com. It has NO BUSINESS even noticing that "virtual1.com"
occurs in the local part, or that the local part begins with
"SRS". For all you know, this isn't truly SRS signing but a
complete, valid account name with no additional semantics.

>However, the "reject SRS" policy that was proposed should probably apply only
>to specific domains that were abusing SRS - at least until the
>distinction between SRS "signing" and "forwarding" is more widely
>understood.

Not at least until we feel like it. Until either the end of time or
the RFC's are changed. Take your pick :P


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 27, 2006, 10:31 AM
Post #15 of 70 (30212 views)
Permalink
On Mon, 27 Mar 2006, Tom Lahti wrote:

> >b) When a domain is abusing SRS to the point of clogging your
> > quarantine, my choices (and any other admin dealing with
> > 40000+ forged emails to a 6 person office) are to reject *all*
> > mail from the domain, or heuristically try to reject only the mail
> > they are abusing.
>
> The former is your only RFC-compliant alternative. If you
> heuristically try to reject only the mail they are abusing, its is
> [a] a violation of RFC, and [b] allows the abuser to continue what
> he's doing, shifting the burden of his own administration onto those
> trying to sort out his garbage. The right thing to do is to force
> him to sort out his own garbage but rejecting the whole domain until
> he fixes it.

I hate to tell you this, but we block specific users all the time -
irrespective of SRS. When 'simon@yahoo.com' (to take a recent example) sends
us hundreds of spam, into the blacklist he goes. There is no
reason for us to block legit yahoo users just because of one
miscreant. If a bunch of users whose cryptic localpart begins
with 'SRS' start spamming us - into the blacklist they go.

(Spamming via SRS has not actually happened to me. I am just taking the
original posters complaint seriously. It is entirely possible
that the "well known provider" forwarding him all the spam via SRS
is legitimately doing so because he himself asked them to - which
is not a good idea if you check SPF and the forwarder does not.)

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stephan-menzel at web
Mar 27, 2006, 10:42 AM
Post #16 of 70 (30239 views)
Permalink
Am Montag, 27. März 2006 19:50 schrieb Tom Lahti:
> RFC's weren't made for you to break whenever you feel like it. If
> that is their purpose, then why have them at all?

Well, basically I can agree to this. However, we are doing in some
circumstances pretty much the same Johann showed in his example. Not because
we don't want to be complaint but we are simply forced to do so.
During heavy spam waves and major virus outbreaks our MXes would be lost
without this behaviour. We tried. But always to wait till DATA is done is
simply impossible. I think RFC 822 and even 2822 were made in a time when
Botnet spamming was not the problem it is today and just like a human
language lives and evolves to fit the needs of it's time, protocols like SMTP
should also be considered flexible as long as it doesn't do any considerable
collateral damage. Which Johanns example does not.

> The reason for
> RFC's is so that one can have _some_ basis for knowing what other
> systems will do. "You are right and we know that" means: RFC's are
> useless for determining what another domain will do with a piece of
> mail, while at the same time pretending to "conform to them in most
> cases". This isn't a matter of degree, its all-or-nothing. You're
> either compliant, or you're not.

Indeed. But if I'm faced with the choice to even be absolutely compliant or
watch our MXes die, I think I know what to choose. Especially since I
believe, to be absolutely 2822 compliant means to be an open relay.

Greetings...

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 10:46 AM
Post #17 of 70 (30191 views)
Permalink
>I hate to tell you this, but we block specific users all the time -
>irrespective of SRS. When 'simon@yahoo.com' (to take a recent example) sends
>us hundreds of spam, into the blacklist he goes. There is no
>reason for us to block legit yahoo users just because of one
>miscreant. If a bunch of users whose cryptic localpart begins
>with 'SRS' start spamming us - into the blacklist they go.

Yes, of course. But you are not assigning SEMANTICS to "simon", you
are just dropping it. You are not trying to determine that "si"
means something and "mon" means something else, which is what
"assigning semantics" means.

To do THAT -- to rip apart the local part of a MAIL FROM: that is not
in your own domain and try to determine what parts of it mean, is the
RFC violation.

I don't think that having a one-to-one policy of localpart@domainpart
=> action is bad or a violation of RFC. If you try to take the local
part apart and divide it up somehow and try to decide what the pieces
mean, then you have a problem. The sending MTA constructed that, and
you really don't know how, even when you think you do.

Of course, "blacklisting" specific SRS signed MAIL FROM: only works
for a short time period, until the hash changes. In this case, if
you want to be effective and stay RFC compliant, you are left with
blocking the entire domain. This is not your fault -- the sending
domain administrator made that choice when he decided to SRS
sign. Don't treat him special just because he might have a
"well-known" domain.

I suspect that this is precisely why domains like yahoo.com will
probably never use SRS. They know they will leave administrators
wishing to remain RFC compliant with only one choice.


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
j.steigenberger at admins
Mar 27, 2006, 10:50 AM
Post #18 of 70 (30264 views)
Permalink
> This isn't a matter of degree, its all-or-nothing. You're
> either compliant, or you're not.

You see this too much in black and white :-)

Think about:
Many RFCs were made in times of good old internet was just beginning to
exist,
some even before.
If their creators would have been aware of all todays problems, they had
shurley
made some things very different to what they are today.

>Example:

The example was just here to demonstrate, that it can make sense
to violate RFCs, as long as you know, what you are doing :-).

>This means your example is perfectly legitimate mail handling,

No it is not conform to RFCs - you re not allowed to say bye bye
if a Sender gets a 5xx rcpt, you have to let him start the Data
Phase for the previously allowed rcpt .....

But in the real world most newer MTAs do so :-)

>S: mail from: SPAMTRAP@senderdomain

>What comes next? Will you reject this mail? Can you be certain it
>is not a valid email?

That depends on the policy.
If you have a rule in it which says block all envelope froms beginning with
spam:
Then YES, otherwise NO :-)
Actually we have one in our default Ruleset saying all evelopefrom which
are:
srs*=*.*=*@* should be rejected ...

Hope you see its not the Product which is not conform to RFCs,
it is a policy made decision not to accept mails having such envelope froms
:-)
Since you can make the policy on your system, it is your choice if you
follow RFCs or not ...

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 10:51 AM
Post #19 of 70 (30205 views)
Permalink
>Well, basically I can agree to this. However, we are doing in some
>circumstances pretty much the same Johann showed in his example.

Which means: not an example of what we're discussing. Johann's
example is perfectly compliant.

We're discussing an MTA examining the local part of MAIL FROM: where
the domain is not the MTA's domain, and trying to parse out meaning
from it (beyond a simple one-to-one comparison). Are you doing THAT?


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 11:06 AM
Post #20 of 70 (30204 views)
Permalink
>You see this too much in black and white :-)

I don't even know what that means. 1+1=2. Always. It's never 1.9 or 2.1.

>No it is not conform to RFCs - you re not allowed to say bye bye
>if a Sender gets a 5xx rcpt, you have to let him start the Data
>Phase for the previously allowed rcpt .....

Your example was compliant with respect to assigning semantics to the
local part of an address where the domain is your not own domain
which is the context of the discussion. The context-dropping won't
buy you anything, except with fools that don't recognize it.


>Hope you see its not the Product which is not conform to RFCs,
>it is a policy made decision not to accept mails having such envelope froms
>
>ince you can make the policy on your system, it is your choice if you
>follow RFCs or not ...

Absolutely. Make your policy and live with the consequences. Your
RFC-violating policy will drop all mail emanating from the hundreds
of domains that source from my MTA's, while I am RFC compliant. When
your boss doesn't get my customer's very important email and I
explain to your boss why, you'll be out of a job and we'll get
someone else in there who knows what they're doing. That's progress. :P



--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
j.steigenberger at admins
Mar 27, 2006, 11:24 AM
Post #21 of 70 (30250 views)
Permalink
>We're discussing an MTA examining the local part of MAIL FROM: where
>the domain is not the MTA's domain, and trying to parse out meaning
>from it (beyond a simple one-to-one comparison). Are you doing THAT?

And i just read RFC 821:

MAIL <SP> FROM:<reverse-path> <CRLF>

This command tells the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers, including any recipients or mail data. It gives the
reverse-path which can be used to report errors. If accepted,
the receiver-SMTP returns a 250 OK reply.

If accepted means i can logically reject if i do not want ....
I cannot find anything there not compliant to RFC821 :-)

Where in which RFC did you find a passage that forces me to accept
any given envelope mail from ?

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 11:38 AM
Post #22 of 70 (30218 views)
Permalink
>Where in which RFC did you find a passage that forces me to accept
>any given envelope mail from ?


Not any given MAIL FROM:. I never said that. What I said is that
you can interpret the domain part in MAIL FROM: but you cannot
interpret the local part of the address in MAIL FROM:. What will it
take to stop the equivocation? I suppose it would be easier for your
argument if I actually said that, but I didn't.

RFC 2821 section 2.3.10 Mailbox and Address:

>The standard mailbox naming convention is defined to be
>"local-part@domain": contemporary usage permits a much broader set of
>applications than simple "user names". Consequently, and due to a
>long history of problems when intermediate hosts have attempted to
>optimize transport by modifying them, the local-part MUST be
>interpreted and assigned semantics only by the host specified in the
>domain part of the address.

Due to a long history of problems, that you, Johann, are perpetuating.

The local-part MUST be interpreted and assigned semantics only by the
host specified in the domain part!!!!!!



--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stephan-menzel at web
Mar 27, 2006, 11:48 AM
Post #23 of 70 (30273 views)
Permalink
Am Montag, 27. März 2006 20:51 schrieb Tom Lahti:
> >Well, basically I can agree to this. However, we are doing in some
> >circumstances pretty much the same Johann showed in his example.
>
> Which means: not an example of what we're discussing. Johann's
> example is perfectly compliant.

Yes.
I know, the example was not supposed to emphasize the original point of this
discussion but rather to show a general acceptance to violate certain RFC
demands simply to be able to survive in a scenario of heavy spamming. I just
wanted to add my two cents there.

> We're discussing an MTA examining the local part of MAIL FROM: where
> the domain is not the MTA's domain, and trying to parse out meaning
> from it (beyond a simple one-to-one comparison). Are you doing THAT?

Well, if I understand you right here, yes we do.
But consider a scenario with many user dependend configurations. Let's say,
you offer SPF checks for your users. And some users have it activated with a
setting like 'deliver to spam folder', some users say 'no, I want this
blocked' and there will also be users who say 'I don't want any SPF
checkings'. Same thing goes not only for SPF but for many other spam
protection modules you might invoke there like internal or external
blacklists etc.
In this case, you have almost no chance to give the error right after MAIL
FROM. You must be able to know, which user this mail will be adressed to to
determine which settings apply. Regarding the RFC, afaik this won't let you
any option other than receiving the DATA.
Or did I get you wrong here?

Greetings...

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
tom at tx3
Mar 27, 2006, 11:54 AM
Post #24 of 70 (30226 views)
Permalink
>Actually we have one in our default Ruleset saying all evelopefrom which
>are:
>srs*=*.*=*@* should be rejected ...

What I put in my local part is none of your business, and you
shouldn't assume anything about its meaning. Suppose I invent a new
addressing scheme for some purpose here that has nothing to do with
SRS. It happens to fit your pattern match, but its not SRS. You'll
reject my mail, thinking that I'm doing SRS, when I'm not. Or
suppose someone creates a mailbox named "srs==", and my MTA doesn't
interpret it at all (its a literal username). Will you reject his mail too?

Neither of these are very likely, but likelihood is not the
issue. The issue here is principle, and the principle is that you
DON'T REALLY KNOW what it means, even if you think you do, and so you
can't interpret meaning into its parts (beyond a simple equivalence test).


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Why SRS really sucks [ In reply to ]
stuart at bmsi
Mar 27, 2006, 12:02 PM
Post #25 of 70 (30217 views)
Permalink
On Mon, 27 Mar 2006, Tom Lahti wrote:

> >I hate to tell you this, but we block specific users all the time -
> >irrespective of SRS. When 'simon@yahoo.com' (to take a recent example) sends
> >us hundreds of spam, into the blacklist he goes. There is no
> >reason for us to block legit yahoo users just because of one
> >miscreant. If a bunch of users whose cryptic localpart begins
> >with 'SRS' start spamming us - into the blacklist they go.
>
> Yes, of course. But you are not assigning SEMANTICS to "simon", you
> are just dropping it. You are not trying to determine that "si"
> means something and "mon" means something else, which is what
> "assigning semantics" means.

Exactly. And we are not assigning semantics when we notice that
local parts beginning with 'SRS' from a particular domain are all
spam. It is just a pattern that we blacklist.

> To do THAT -- to rip apart the local part of a MAIL FROM: that is not
> in your own domain and try to determine what parts of it mean, is the
> RFC violation.

Of course! We don't know the hashkey, and can't even certain whether
the signature is valid! Perhaps the braindead ISP is actually
an old fashioned open-relay, and the spammers are adding the SRS
coding to make the spam pass SPF and look like it is coming from
the ISP.

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

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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal