Mailing List Archive

>Stuart D. Gathman writes:
> > I was able to stop problems with idiots rejecting
> > '+' in localpart by switching to SES.
>
>I've had several confirmed cases of mail being rejected because the
>mail-from had '=', but as best I know, I've had no problems from '+'
>so far.
>
>There's even a commercial anti-spam package for Windows servers that
>has an option to refuse mail with '='.

I concur with Dick on that. I haven't had any problems with "+",
just "=". My response is usually to educate the sysadmins on RFC
2821 section 4.1.2 which defines the local-part as being a dot-string
('atoms' connected by "."), and RFC 2822 section 3.2.4 which defines
"atom" as being a string of "atext" elements, and "atext" being any
of ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" /
"-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~".

So, clearly both "=" and "+" are legal address characters in the
local-part, per RFC.

Only once has this education failed to remove the offending policy
from the receiving MTA. In that case, the admins removed it for that
specific user, which apparently also increased the spam they
received. I imagine this is because they disabled a whole anti-spam
package for that mailbox in order to accomplish this.

Why they can't just remove the "=" from the ruleset system-wide, I
can't fathom. They must be rejecting mail from every SRS signer on
the planet, and anyone who quite legitimately uses "=" in their mailbox name.


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

Am Donnerstag, 1. Januar 1970 01:00 schrieb Johann Steigenberger:
> 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.

I would like to raise another question there:

If I only do SRS when the sending domain is SPF protected, what would happen
to te other protection forms similar to SPF like Sender ID?
Those protection schemes also benefit from SRS and I would break them if I
only perform SRS when a 'real' SPF record is there.

So the way I see it, SRS should be done in those cases too, shouldn't it?

Greetings....

Stephan








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

-------
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 Sun, 2 Apr 2006, Stephan Menzel wrote:

> If I only do SRS when the sending domain is SPF protected, what would happen
> to te other protection forms similar to SPF like Sender ID?

Sender-ID does not validate MAIL FROM. So it is unaffected by
whatever you do with MAIL FROM.

However, Sender-ID wants you to do something similar with the 'Sender'
mail header field.

> Those protection schemes also benefit from SRS and I would break them if I
> only perform SRS when a 'real' SPF record is there.

Those other protection schemes are concerned with the RFC2822 mail
headers fields. They don't validate MAIL FROM (except SES).

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

On Sun, 2006-04-02 at 20:27 +0200, Stephan Menzel wrote:
> If I only do SRS when the sending domain is SPF protected, what would happen
> to te other protection forms similar to SPF like Sender ID?
> Those protection schemes also benefit from SRS and I would break them if I
> only perform SRS when a 'real' SPF record is there.
>
> So the way I see it, SRS should be done in those cases too, shouldn't it?

That depends. There are _always_ going to be people out there who will
make up random new rules about email, diverging from the known and
accepted norms and deciding unilaterally to reject the mail you send.
But mangling the recipient address unnecessarily would be bad -- there's
useful information in there which you'd be obscuring, so it's best to do
it only when you _need_ to.

My approach is to have a list of recipient domains for which SRS will be
done. I add recipient domains to the list only if they meet all three
criteria below:

1. They reject mail for spurious non-standard reasons, such as SPF
failure or their own random inventions (like gmx.de).

2. They fail to fix this error when I explain it to them.

3. I still actually care about getting mail through to those particular
domains, and their users don't just migrate elsewhere after #2.

There aren't actually many domains in my list -- most people don't get
to #2.

In fact, my list of broken domains contains a 'reason' for each domain
-- so some domains have only their own addresses rewritten, some have
all addresses with SPF records rewritten, etc.

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

On Sun, 2 Apr 2006, David Woodhouse wrote:

> But mangling the recipient address unnecessarily would be bad -- there's
> useful information in there which you'd be obscuring, so it's best to do
> it only when you _need_ to.

What exactly is your point? Recipiet address exist solely for purposes
of providing routing information on how to deliver the message. What
different does it make if you see tom@example.com or 123456@example.com
as long as message will get to Tom (btw - we're talking about RCPT TO
address not pretty visible address in To field that user will see).

--
William Leibzon
Elan Networks
william@elan.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

>What exactly is your point? Recipiet address exist solely for purposes
>of providing routing information on how to deliver the message. What
>different does it make if you see tom@example.com or 123456@example.com
>as long as message will get to Tom (btw - we're talking about RCPT TO
>address not pretty visible address in To field that user will see).

It makes a difference if you want to get your mail delivered to a System,
which
uses envelope data only for making decisions, if a mail should be rejected
or accepted.

Example:
If the recipient System is an UCEPROTECT-Server, and your System or settings
do not match
the requirements to be accepted, you get a NDR which tells you why your mail
was rejected, and how
you can whitelist your emailadress.

If you go to the Whitelist - Page and enter tom@example.com it will cause
your mail will get throu
if your envelope-from reflects that.
But if your Envelope-From is 123456@example.com, and your User does not know
that, whitelisting
tom@example.com will not work for you ....

And: UCEPROTECT is not the only System which uses envelope data for making
decisions ....

Having the possibility that a sender can enter his emailadress is the only
way to get still accepted,
if for. e.G. the Network with the Sender machine is blacklisted or something
else your sender
can not change ....

SRS makes that also impossible for senders .... thats the consequence of
faking envelope datas ...
And it is one more reason why SRS really sucks...

--

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

On Mon, 2006-04-03 at 04:05 -0700, william(at)elan.net wrote:
> > But mangling the recipient address unnecessarily would be bad -- there's
> > useful information in there which you'd be obscuring, so it's best to do
> > it only when you _need_ to.
>
> What exactly is your point? Recipiet address exist solely for purposes
> of providing routing information on how to deliver the message.

Sorry, I meant to say 'mangling the _sender_ address unnecessarily would
be bad'.

It's true for the recipient address _too_, mind you -- as a general
principle, unnecessary mangling of _anything_ is bad, and loses
information.

> What different does it make if you see tom@example.com or
> 123456@example.com as long as message will get to Tom (btw - we're
> talking about RCPT TO address not pretty visible address in To field
> that user will see).

(Still talking about the _recipient_ address, due to my mistake...)

I don't think anyone was really suggesting that we could mangle
recipient addresses and get away with it.

As an outsider, you _couldn't_ know that it would still get to Tom, if
you changed it to RCPT TO:<123456@example.com>. In fact, it's a fairly
safe bet that it _wouldn't_ get to Tom.

Even if it _did_ get to one of his mailboxes, it still might not get
read -- it might be treated differently according to the address it was
delivered to. I certainly have filters such that mail will end up in a
different folder depending on the recipient address. Because my
cellphone isn't able to store its outgoing messages in an IMAP folder
but _is_ able to Bcc, there's one recipient address which will store the
mail in my outgoing folder, marked as already having been read. In that
case, I suppose that in one sense the message has 'got to me' because
it's in my mail store. But the chances of me reading it are slim.

Other people have catch-all aliases which collect mail to
_anyone_@example.com and dump it into a spamtrap mailbox. That wouldn't
be particularly useful either.


(Now, switching back to what I was _intending_ to say and answering the
equivalent question -- what difference does it make if you see
tom@example.com or 123456@example.com in the _sender_ address? ...)

As I said, there's valid information in the reverse-path. It allows
sender verification callouts to work, so that you can refuse to accept
mail unless you know you can generate a bounce. If you trick the next
system into doing callouts back to your own mail server, instead of the
originating mail server, then you're bypassing that check. And you're
likely to end up with bounces to the SRS addresses which aren't actually
deliverable to the final destination, unless you've done callouts of
your own to verify the addresses.

It's also the most reliable way of filtering mailing lists...

Some people filter by looking at To: and Cc: headers. That gets false
positives when messages are cross-posted or Cc'd to you directly.
Instead of getting one copy in each list folder, or one in your inbox
and one in each list folder as appropriate, you'll end up with them all
in one folder. That may be a folder you never (or _rarely_ visit).
It also gets false negatives when messages are Bcc'd to lists.

Some people filter by looking for List-Id: headers. That gets false
positives when someone sees a mail on a list they _know_ you aren't
actually paying any attention to right now, and redirects it to you with
all the headers intact. That happens to me a lot, and if I filtered on
List-Id: it would land in the list folder again and still be ignored --
instead of landing in my inbox where I see it.

The only reliable way of filtering mailing lists that I've found is to
filter on the reverse-path. If you get three copies of a mail -- one
from each of two lists and one direct, you get those three copies in the
appropriate folders because each arrives with a distinct reverse-path.

Some people don't like that outcome -- they _want_ to eliminate
duplicates. I could never find a suitable way to eliminate duplicates
while still having even vaguely predictable behaviour, so for me that
would be worse.

It'd be quite nice if all three could be marked as 'read' when one of
them is, but that's getting off-topic...

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johann Steigenberger wrote:
> Example:
> If the recipient System is an UCEPROTECT-Server, and your System or
> settings do not match the requirements to be accepted, you get a NDR
> which tells you why your mail was rejected, and how you can whitelist
> your emailadress.
>
> If you go to the Whitelist - Page and enter tom@example.com it will
> cause your mail will get throu if your envelope-from reflects that.
> But if your Envelope-From is 123456@example.com, and your User does not
> know that, whitelisting tom@example.com will not work for you ....

Challenge/response systems are broken by design (and if UCEPROTECT does
that kind of thing, it is, too). And even then, they will usually not
require manual entry of envelope sender addresses.

> SRS makes that also impossible for senders .... thats the consequence of
> faking envelope datas ...

SRS does not fake envelope sender addresses. If you believe that, then you
have understood _neither_ the point of SRS _nor_ that of SPF.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMQ7ewL7PKlBZWjsRAlXMAKChNHIrrKN818vmnuOkgy8++4y1NQCgsKs3
NOHfelet6kaAxoNirjZ08Vc=
=51Em
-----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

>Challenge/response systems are broken by design (and if UCEPROTECT does
>that kind of thing, it is, too). And even then, they will usually not
>require manual entry of envelope sender addresses.

UCEPROTECT does not make challenge response ....
You have whitelists and blacklists followed by your policy.

If something for ever reason can not get thru your policy,
then your mail is rejected.
for e.G.
We make a decision on smtp dialog after rcpt to:

RCPT TO: Recipient@example.com
550 Your mail was rejected, because your Server has no PTR. To have an
exception made for you emailaddress contact us using the form on ...

So you see not we send the NDR, the System which tried to deliver will do
that ...
Thats no challenge response ...

If that user enters his emailadress at the form, it becomes whitelisted, so
it will pass next time ...

We know many Systems out there which do similair things
As soon as your reciever System uses Envelope data for deciding if or if not
to accept your
mail you will always loose by using SRS

>> SRS makes that also impossible for senders .... thats the consequence of
>> faking envelope datas ...

>SRS does not fake envelope sender addresses. If you believe that, then you
>have understood _neither_ the point of SRS _nor_ that of SPF.

I have understood what it does ...
And i found SPF is cool.
But modifying anything in envelope is logically considered as a fake to me..
.
Every technology which modifies envelope data is poorly designed ....

--

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johann Steigenberger wrote:
> Julian Mehnle wrote:
> > Challenge/response systems are broken by design (and if UCEPROTECT does
> > that kind of thing, it is, too). And even then, they will usually not
> > require manual entry of envelope sender addresses.
>
> UCEPROTECT does not make challenge response ....
> You have whitelists and blacklists followed by your policy.
>
> If something for ever reason can not get thru your policy,
> then your mail is rejected.
> for e.G. We make a decision on smtp dialog after rcpt to:
> RCPT TO: Recipient@example.com
> 550 Your mail was rejected, because your Server has no PTR. To have an
> exception made for you emailaddress contact us using the form on ...
>
> So you see not we send the NDR, the System which tried to deliver will
> do that ... Thats no challenge response ...

Well, yes, it is. The instruction in the SMTP response to enter the e-mail
address manually is the challenge, and the original sender entering his
e-mail address manually into the form is the response. A challenge does
not have to be a generated bounce to be a challenge. A response does not
have to be a reply message to be a response.

It may be a _different_form_ of C/R, but it is still C/R.

> As soon as your reciever System uses Envelope data for deciding if or if
> not to accept your mail you will always loose by using SRS

Only if your goal is to reject as much mail as possible, legitimate or not.
But then you could just as well reject _all_ mail you receive, and no
longer have to worry about someone trying to comply with -- and thus
"bypass" -- your security measures.

Look, complying with security measures isn't the same thing as bypassing
them. Doing SRS is "complying with", not "bypassing" SPF.

> > SRS does not fake envelope sender addresses. If you believe that, then
> > you have understood _neither_ the point of SRS _nor_ that of SPF.
>
> I have understood what it does ... And i found SPF is cool.
> But modifying anything in envelope is logically considered as a fake to
> me...

So if I take your message and resend it with all the headers unmodified,
just using my own envelope sender, then it is a fake? No, it isn't! It
is a perfectly legal case of the layer separation between RFC 2821 and RFC
2822.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMRklwL7PKlBZWjsRAra0AJ41MM/PhZPIV2Svlr3b6gHbCxWNiACfV6OV
3NM1elxX6THGqS28wBZ7WME=
=t37S
-----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

On Mon, 2006-04-03 at 12:46 +0000, Julian Mehnle wrote:
> So if I take your message and resend it with all the headers unmodified,
> just using my own envelope sender, then it is a fake? No, it isn't! It
> is a perfectly legal case of the layer separation between RFC 2821 and RFC
> 2822.

If _you_ (the user) resend it, then yes -- of course it's not a fake.
The accepted norm is to add Resent-From:, Resent-To, Resent-Message-Id:
headers when you do that.

If the message is just passing through a system in transit, and the
reverse-path is mangled from its original form to some new form, then
that's understood by many to be 'fake'. But you're just arguing about a
choice of words -- to suggest that he doesn't understand SRS or SPF just
because he considers SRS-mangled addresses to be 'fake' addresses is
somewhat disingenuous of you.

Of _course_ SRS provides 'fake' addresses. That's the whole _point_ of
it. They're not real addresses with a mailbox (and a person) behind them
-- they're fake addresses because you decided you didn't want to send
the mail on with the original and correct reverse-path.

What I said (or at least what I _intended_ to say) was that you
shouldn't do this mangling except where it's actually necessary to work
around a problem which can't be fixed in other ways.

Mostly I find that the problem _can_ be fixed in other ways -- usually
by getting the offending recipient to stop using SPF to reject mail, or
by getting the offending sender to stop publishing SPF records with
'-all'.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> On Mon, 2006-04-03 at 12:46 +0000, Julian Mehnle wrote:
> > So if I take your message and resend it with all the headers
> > unmodified, just using my own envelope sender, then it is a fake? No,
> > it isn't! It is a perfectly legal case of the layer separation
> > between RFC 2821 and RFC 2822.
>
> If _you_ (the user) resend it, then yes -- of course it's not a fake.
> The accepted norm is to add Resent-From:, Resent-To, Resent-Message-Id:
> headers when you do that.
>
> If the message is just passing through a system in transit, and the
> reverse-path is mangled from its original form to some new form, then
> that's understood by many to be 'fake'. But you're just arguing about a
> choice of words -- to suggest that he doesn't understand SRS or SPF just
> because he considers SRS-mangled addresses to be 'fake' addresses is
> somewhat disingenuous of you.
>
> Of _course_ SRS provides 'fake' addresses. That's the whole _point_ of
> it. They're not real addresses with a mailbox (and a person) behind them
> -- they're fake addresses because you decided you didn't want to send
> the mail on with the original and correct reverse-path.

So all e-mail aliases and mailing lists are 'fake' addresses? Is a
postmaster@ address 'fake' because it is forwarded to some real person's
address? Does my work address become fake while I'm on vacation just
because it gets forwarded to someone else? I don't think this definition
of 'fake' is very helpful.

> What I said (or at least what I _intended_ to say) was that you
> shouldn't do this mangling except where it's actually necessary to work
> around a problem which can't be fixed in other ways.
>
> Mostly I find that the problem _can_ be fixed in other ways -- usually
> by getting the offending recipient to stop using SPF to reject mail, or
> by getting the offending sender to stop publishing SPF records with
> '-all'.

What problem?

I know you're going to reply: "The problem that SPF rejects forwarded mail
w/o the sender address rewritten", but that is one of the fundamental
points of SPF. If you don't want that to happen to the mail you send,
don't publish SPF. However if you _do_ want it, there is no problem.
Please accept that there are people who do not want their mail to be
forwarded w/o the envelope sender address rewritten. (Like me and many
others, Johann seems to belong to that crowd.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMSN6wL7PKlBZWjsRAkLyAKCbB8tu0gD9r0YHPh17mxwW8xHhkACgvut+
715KQS/mOwBkbv1Q+iRKmRo=
=S/cc
-----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

On Mon, 2006-04-03 at 13:30 +0000, Julian Mehnle wrote:
> So all e-mail aliases and mailing lists are 'fake' addresses? Is a
> postmaster@ address 'fake' because it is forwarded to some real person's
> address? Does my work address become fake while I'm on vacation just
> because it gets forwarded to someone else? I don't think this definition
> of 'fake' is very helpful.

'virtual' is a better word, perhaps. Where you cross the line between
'virtual' and 'fake' is subjective. I don't think there's any point in
us trying to _agree_ on precisely where that line is -- and there's no
point in you haranguing Johann about it either.

He seems to think, and I certainly _do_ think, that mangling the
reverse-path of a mail in transit constitutes 'faking' the reverse-path.
That doesn't mean that either he or I don't understand SRS and SPF,
which is what you suggested.

Your analogy of resending, where you deliberately reintroduced the mail
to the system, perhaps shows a misunderstanding on your part... but in
fact I think you were just being disingenuous.

> What problem?

Er, the problem which led to SRS being invented in the first place?

> I know you're going to reply: "The problem that SPF rejects forwarded mail
> w/o the sender address rewritten", but that is one of the fundamental
> points of SPF.

Well, yes -- I suppose I might have answered that in another context.
The reply above seemed more pertinent though.

It would be very dishonest to claim that to break forwarding is one of
the fundamental _goals_ of SPF.

SPF wasn't invented specifically to stop standard forwarding -- it was
invented to stop _forgery_. It is an unfortunate technical detail that
SPF is unable to tell normal forwarding from 'forgery', as some
forgery-prevention schemes can.

Some people have therefore chosen to declare that their definition of
'forgery' includes such normal forwarding behaviour, just because SPF
can't tell the difference. That doesn't really help much in the real
world, though.

> If you don't want that to happen to the mail you send,
> don't publish SPF. However if you _do_ want it, there is no problem.
> Please accept that there are people who do not want their mail to be
> forwarded w/o the envelope sender address rewritten. (Like me and many
> others, Johann seems to belong to that crowd.)

I accept that there are many people who want many things, not all of
them realistic. I give no credence to their desires -- if they send mail
to my users by SMTP, then I will behave in the manner for which there is
decades of precedent. If that user has a .forward file or other similar
mechanism set up, that will include forwarding the mail _intact_, unless
the recipient domain is specifically listed in my list of known-broken
recipients.

I can't really tell if Johann belongs to that crowd -- I've seen only
two emails from him that I recall, and one of those was HTML so I didn't
pay much attention to it. He certainly doesn't seem to be keen on SRS,
because he considers it to be fakery. But I certainly won't argue with
you about what we think Johann might think. If he wants us to know that,
he can state it himself.

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

Hi Julian,

>Only if your goal is to reject as much mail as possible, legitimate or not.

>But then you could just as well reject _all_ mail you receive, and no
>longer have to worry about someone trying to comply with -- and thus
>"bypass" -- your security measures.

The goal is not to reject as much mail as possible:-)
The goal is to reject as much spam as possible ...
Facts are that, if you have a really good policy, you will not have
many cases, for which an exception must be done.

Do not think we are only using:
IP, PTR, HELO, MAIL FROM and RCPT TO :-)
There are multiple other things we detect and which find their way
into the policys decision ...
Only decision happens always after rcpt to ...

>So if I take your message and resend it with all the headers unmodified,
>just using my own envelope sender, then it is a fake? No, it isn't! It
>is a perfectly legal case of the layer separation between RFC 2821 and RFC
>2822.

If you regulary resend the message this is something different to just
rewrite the Env-from.
Resend means headers would reflect that ...
If you leave headers unmodified it is logically a fake even if RFCs do not
explicitley forbid it....

--

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

Julian said it right:

>Please accept that there are people who do not want their mail to be
>forwarded w/o the envelope sender address rewritten. (Like me and many
>others, Johann seems to belong to that crowd.)

Yes. That was the reason that threat was started.

To show people which think they need to use SRS, that they are
always at risk to have mail not delivered, because they are using SRS.

Many People out there are not accepting, that you are breaking sender
policys
published by SPF, and those people get moore every day ....

Those People (me too) will reject SRS Mail, and worst case (for e.G if your
users did send SPAM or PHISINGMAILS over your SRS) it can easy lead to
your IP or Domain will end up in our blacklists and others too, because you
supported
the Spammer/Phisher...

--

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

On Mon, 3 Apr 2006, David Woodhouse wrote:

> On Mon, 2006-04-03 at 13:30 +0000, Julian Mehnle wrote:
> > So all e-mail aliases and mailing lists are 'fake' addresses? Is a
> > postmaster@ address 'fake' because it is forwarded to some real person's
> > address? Does my work address become fake while I'm on vacation just
> > because it gets forwarded to someone else? I don't think this definition
> > of 'fake' is very helpful.
>
> 'virtual' is a better word, perhaps. Where you cross the line between
> 'virtual' and 'fake' is subjective. I don't think there's any point in
> us trying to _agree_ on precisely where that line is -- and there's no
> point in you haranguing Johann about it either.

A 'virtual' mailbox is one that does not require SRS - because it
was requested by a competent admin or user who is not so stupid as
to reject their own forwards because of SPF fail.

A 'fake' mailbox is one that uses SRS in a misguided attempt to
work around broken recipient SPF configurations.

This does not mean SRS is bad. It is only bad when used as a codependency
inspired workaround for broken SPF configurations.


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

On Mon, 2006-04-03 at 11:01 -0400, Stuart D. Gathman wrote:
> This does not mean SRS is bad. It is only bad when used as a
> codependency inspired workaround for broken SPF configurations.

That's perhaps true, although it's ironic to note that SRS was
_designed_ as a workaround for the brokenness of SPF.

You seem to be agreeing with what I said to Stephan -- which is that SRS
should be used sparingly (if at all), rather than doing it
unconditionally just in _case_ the recipient has invented some spurious
reason to reject normally-forwarded mail. Yes?

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

On Mon, 3 Apr 2006, David Woodhouse wrote:

> On Mon, 2006-04-03 at 11:01 -0400, Stuart D. Gathman wrote:
> > This does not mean SRS is bad. It is only bad when used as a
> > codependency inspired workaround for broken SPF configurations.
>
> That's perhaps true, although it's ironic to note that SRS was
> _designed_ as a workaround for the brokenness of SPF.
>
> You seem to be agreeing with what I said to Stephan -- which is that SRS
> should be used sparingly (if at all), rather than doing it
> unconditionally just in _case_ the recipient has invented some spurious
> reason to reject normally-forwarded mail. Yes?

Yes. I use it unconditionally for *outgoing* mail (including mail
from internal domains through a gateway MTA) to block fake DSNs.
However, it should be used for actual forwarding *only* when the
recipient:

a) actually requested the forward (unless you want to be an open relay)
b) checks SPF
c) has a broken SPF checker that can't be configured with trusted forwarders

I would not use the existence of a sender SPF policy to decide whether
forwarding SRS is required. It is strictly a service for SPF recipients
with poor implementations.

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

Hello!

On Mon, Mar 27, 2006 at 09:48:01PM +0200, Stephan Menzel wrote:
>[...]

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

You did get something wrong: You know the recipient after RCPT TO, so at
*that* point you can lookup the user's settings and apply
recipient-specific policy to perhaps deny the mail. No need to wait for
the DATA command or even the completion of the DATA phase.

Kind regards,

Hannah.

-------
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 Wed, 26 Apr 2006, Hannah Schroeter wrote:

> >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?
>
> You did get something wrong: You know the recipient after RCPT TO, so at
> *that* point you can lookup the user's settings and apply
> recipient-specific policy to perhaps deny the mail. No need to wait for
> the DATA command or even the completion of the DATA phase.

However, REJECTING a RCPT only rejects that recipient. The SMTP protocol
requires you to keep accepting RCPT commands until the DATA command.
Only after the DATA command can you reject the entire message.

Spammers take advantage of this to test hundreds of RCPTs on a
single MAIL FROM. The best you can do is throttle the rate at which
you answer the RCPT commands. (Of course you could always hang up on an abusive
MTA - but that would be a protocol violation, and is usually counter productive
unless coupled with an IP blacklist.)

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