Mailing List Archive

On Thu, 30 Nov 2006, Camart Office wrote:

> i would like to provide a private SMTP relay so anyone (with any email
> address) on a particular network could use this SMTP server for outgoing
> mail. We can assume that this server will never be listed in any
> domain's SPF records.
>
> i think (please correct me if i'm wrong!) this would cause spf failure
> .... if someone@domain.com is using SPF on domain.com, this would cause
> spf failure if delivered via my relay

It depends on what the SPF records for the domains using your relay
publish. If they really want to use your relay, they should publish
it in their SPF record. However...

> i wondered if i could use srs to get round this in some way .... treat
> each email as if it were being forwarded from the server's default email
> address insted. does this sound feasable? if so, am i right in thinking
> that the final recipient would see the 'tagged' srs address as the
> 'from' in their email client?

Yes, SRS will make your relay domain responsible for any mail you relay.
SRS changes MAIL FROM. It does *not* change the "From:" header field
displayed by email clients.

--
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/?list_id=1129

On Thu, 2006-11-30 at 13:22 +0000, Camart Office wrote:
> hi folks,
>
> i would like to provide a private SMTP relay so anyone (with any email
> address) on a particular network could use this SMTP server for outgoing
> mail. We can assume that this server will never be listed in any
> domain's SPF records.
>
> i think (please correct me if i'm wrong!) this would cause spf failure
> .... if someone@domain.com is using SPF on domain.com, this would cause
> spf failure if delivered via my relay

Yes, but that would be the fault of the recipient -- they should stop
using SPF if it's rejecting valid mail.

I _have_ set up my relay so it's able to use SRS for relayed mail -- but
it only needs to do so in the case where:
1. The sender address has an SPF record.
2. The recipient is known to check SPF and reject for failure.

I have a 'blacklist' of the second type of recipient, but in fact it's
empty apart from the test cases, because whenever forwarded mail has
been rejected and I've contacted the admin of the offending server
they've fixed it by no longer using SPF. So I basically never do SRS on
forwarded mail because it never matches condition #2.

> i wondered if i could use srs to get round this in some way .... treat
> each email as if it were being forwarded from the server's default email
> address insted. does this sound feasable? if so, am i right in thinking
> that the final recipient would see the 'tagged' srs address as the
> 'from' in their email client?

It wouldn't appear in the From: address; only in the Return-Path:. But
the return-path is the most reliable way of filtering traffic from
mailing lists into the appropriate folder, so some people _do_ use it
and care about it. I would be reluctant to mangle it without good
reason.

I recommend that you don't use SRS on forwarded mail. If you find you
have problems with people rejecting mail for SPF failure, contact them
and explain that they should not be using SPF. It usually seems to work
on the people who've been taken in by the SPF 'marketing' and who didn't
realise that SPF was incompatible with mail in the real world today.

--
dwmw2

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

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

David Woodhouse wrote:
> I recommend that you don't use SRS on forwarded mail. If you find you
> have problems with people rejecting mail for SPF failure, contact them
> and explain that they should not be using SPF. It usually seems to work
> on the people who've been taken in by the SPF 'marketing' and who didn't
> realise that SPF was incompatible with mail in the real world today.

All those who prefer to retain "mail in the real world [as it is] today"
will have to put up with e-mail forgery forever.

All the others will probably be glad to tolerate some changes in how "mail
in the real world" works.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcAeywL7PKlBZWjsRAqK1AKDbdHhnDsGH9Lo/yTSTH/DMdRkuPwCfYbP9
kTo6ePJ7dPzZjDdJnMTpCzw=
=OEuU
-----END PGP SIGNATURE-----

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

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: vrijdag 1 december 2006 11:13
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] private relay ... could i use srs
> to avoid spffail?
>
>
> > i wondered if i could use srs to get round this in some way
> > .... treat each email as if it were being forwarded from
> > the server's default email address insted. Does this sound
> > feasable? if so, am i right in thinking that the final
> > recipient would see the 'tagged' srs address as the 'from'
> > in their email client?
>
> It wouldn't appear in the From: address; only in the Return-Path:. But
> the return-path is the most reliable way of filtering traffic from
> mailing lists into the appropriate folder, so some people _do_ use it
> and care about it. I would be reluctant to mangle it without good
> reason.

SPF is an SMTP layer protocol (extension). Unlike RFC 2822 layer protocols
like DomainKeys and SenderID, SMTP envelope information, while the MTA may
make parts of it visible in headers, belongs to a different layer. An MUA
relying on SMTP session info to filter traffic from mailing lists into the
appropriate folder, runs the risk of finding a discrepancy between what
occurs in the SMTP dialogue and what addresses are actually listed in the
mail headers (from the DATA phase). Without having grounds to complain,
that is: if you've always relied on using SMTP envelope data in an MUA,
then SPF "breaking" your little setup really only accentuates your
ill-reliance on it.

> I recommend that you don't use SRS on forwarded mail. If you find you
> have problems with people rejecting mail for SPF failure, contact them
> and explain that they should not be using SPF. It usually seems to work
> on the people who've been taken in by the SPF 'marketing' and who didn't
> realise that SPF was incompatible with mail in the real world today.

I recommend you use SRS on forwarding mail. It's an excellent way for MTAs
to take responsibility for the relay. And "breaks" nothing, save the
ill-conceived schemes of those who can't tell their layers apart.

> It usually seems to work
> on the people who've been taken in by the SPF 'marketing' and who didn't
> realise that SPF was incompatible with mail in the real world today.

With those scare-tactics we'd all still have open relays.

SMTP "in the real world today" is simply broken. It was designed with the
now naive looking thought that people would never take advantage of it and
abuse it. If SPF "breaks" anything, then it's that precise breakage.

- 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/?list_id=1129

David Woodhouse wrote:

>On Thu, 2006-11-30 at 13:22 +0000, Camart Office wrote:
>
>
>>hi folks,
>>
>>i would like to provide a private SMTP relay so anyone (with any email
>>address) on a particular network could use this SMTP server for outgoing
>>mail. We can assume that this server will never be listed in any
>>domain's SPF records.
>>
>>i think (please correct me if i'm wrong!) this would cause spf failure
>>.... if someone@domain.com is using SPF on domain.com, this would cause
>>spf failure if delivered via my relay
>>
>>
>
>Yes, but that would be the fault of the recipient -- they should stop
>using SPF if it's rejecting valid mail.
>
>I _have_ set up my relay so it's able to use SRS for relayed mail -- but
>
>
Aha! That was my next question - whether it is easy/possible to use SRS
for *relay* rather than *forwarding* ... all the documentation I have
been able to find has, understandably, only discussed forwarding.

Which MTA did you use? Did you need to do anything exotic to make it use
SRS for relay?

>it only needs to do so in the case where:
> 1. The sender address has an SPF record.
>
>
That seems very sensible - absolutely no point monkeying around if SPF
isn't used!

> 2. The recipient is known to check SPF and reject for failure.
>
>I have a 'blacklist' of the second type of recipient, but in fact it's
>empty apart from the test cases, because whenever forwarded mail has
>been rejected and I've contacted the admin of the offending server
>they've fixed it by no longer using SPF. So I basically never do SRS on
>forwarded mail because it never matches condition #2.
>
>
In this case it really needs to work first time with unknown destination
servers. I'm looking to provide a relay for random guests who are just
'dropping in' to our network. Some of them are non technical people
whose mail client is configured to use their ISP's SMTP server. They
don't understand why they can't send mail from our network, so we are
considering rerouting all outgoing SMTP through our own relay.....
simple enough, but we don't want to introduce SPF Fail problems for
people who would otherwise have sent mail fine through their own SMTP
server.

Thanks again for your reply

Aparimana

>
>
>>i wondered if i could use srs to get round this in some way .... treat
>>each email as if it were being forwarded from the server's default email
>>address insted. does this sound feasable? if so, am i right in thinking
>>that the final recipient would see the 'tagged' srs address as the
>>'from' in their email client?
>>
>>
>
>It wouldn't appear in the From: address; only in the Return-Path:. But
>the return-path is the most reliable way of filtering traffic from
>mailing lists into the appropriate folder, so some people _do_ use it
>and care about it. I would be reluctant to mangle it without good
>reason.
>
>I recommend that you don't use SRS on forwarded mail. If you find you
>have problems with people rejecting mail for SPF failure, contact them
>and explain that they should not be using SPF. It usually seems to work
>on the people who've been taken in by the SPF 'marketing' and who didn't
>realise that SPF was incompatible with mail in the real world today.
>
>
>

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

> -----Original Message-----
> From: Camart Ltd [mailto:office@camart.co.uk]
> Sent: vrijdag 1 december 2006 13:25
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] private relay ... could i use srs
> to avoid spffail?
>
>
> Aha! That was my next question - whether it is easy/possible
> to use SRS for *relay* rather than *forwarding* ... all the
> documentation I have been able to find has, understandably,
> only discussed forwarding.

I use SRS on *all* outgoing mail. It's extremely useful for detecting fake
DSNs. That alone makes it very worthwhile. I never get even a single fake
DSN here.

If you want an introduction to the concepts, I wrote some info about it, a
while back:

http://srs-socketmap.info/documentation.html


- 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/?list_id=1129

Mark wrote:

>>-----Original Message-----
>>From: Camart Ltd [mailto:office@camart.co.uk]
>>Sent: vrijdag 1 december 2006 13:25
>>To: srs-discuss@v2.listbox.com
>>Subject: Re: [srs-discuss] private relay ... could i use srs
>>to avoid spffail?
>>
>>
>>Aha! That was my next question - whether it is easy/possible
>>to use SRS for *relay* rather than *forwarding* ... all the
>>documentation I have been able to find has, understandably,
>>only discussed forwarding.
>>
>>
>
>I use SRS on *all* outgoing mail. It's extremely useful for detecting fake
>DSNs. That alone makes it very worthwhile. I never get even a single fake
>DSN here.
>
>If you want an introduction to the concepts, I wrote some info about it, a
>while back:
>
>http://srs-socketmap.info/documentation.html
>
>
fantastic, exactly what i need,

many thanks

ap

>
>- 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/?list_id=1129
>
>
>

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

On Fri, 2006-12-01 at 12:22 +0000, Camart Ltd wrote:
> Aha! That was my next question - whether it is easy/possible to use SRS
> for *relay* rather than *forwarding* ... all the documentation I have
> been able to find has, understandably, only discussed forwarding.

I was talking about forwarding. I assume that by 'relay' you just mean
operating as an MX backup? In that case, the recipients _definitely_
shouldn't be rejecting mail due to SPF failures. Or you mean operating
as an _outgoing_ SMTP smarthost for people? In which case they shouldn't
be publishing SPF records which don't include your server(s).

> Which MTA did you use? Did you need to do anything exotic to make it use
> SRS for relay?

I use Exim -- it's fairly simple to do stuff like that purely in Exim's
ACL configuration language. http://www.infradead.org/rpr.html has my
original write-up; the one I'm currently using is slightly modified, at
http://david.woodhou.se/eximconf/include/routers-ses

Note that I do something similar to SRS on all outgoing mail, so that I
don't ever send MAIL FROM:<dwmw2@infradead.org> and hence don't ever
have to accept bounces to such addresses.

> >it only needs to do so in the case where:
> > 1. The sender address has an SPF record.
> >
> >
> That seems very sensible - absolutely no point monkeying around if SPF
> isn't used!
>
> > 2. The recipient is known to check SPF and reject for failure.
> >
> >I have a 'blacklist' of the second type of recipient, but in fact it's
> >empty apart from the test cases, because whenever forwarded mail has
> >been rejected and I've contacted the admin of the offending server
> >they've fixed it by no longer using SPF. So I basically never do SRS on
> >forwarded mail because it never matches condition #2.
> >
> >
> In this case it really needs to work first time with unknown destination
> servers. I'm looking to provide a relay for random guests who are just
> 'dropping in' to our network. Some of them are non technical people
> whose mail client is configured to use their ISP's SMTP server. They
> don't understand why they can't send mail from our network, so we are
> considering rerouting all outgoing SMTP through our own relay.....
> simple enough, but we don't want to introduce SPF Fail problems for
> people who would otherwise have sent mail fine through their own SMTP
> server.

There will _always_ be receiving mailservers out there which reject your
mail for spurious reasons. Some people even reject if your HELO greeting
doesn't contain the same domain name as the one in MAIL FROM!. You can't
be expected to deal with everyone's misconfiguration -- I really would
suggest that you don't bother with it. And perhaps give a _warning_ to
those whose sender address _is_ afflicted with SPF, so that they know
their mail might not get through. There are other situations where their
mail would be rejected even when they send from the 'normal' mailhosts,
anyway.

--
dwmw2

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

>>>>> "Mark" == Mark
>>>>> "RE: private relay ... could i use srs to avoid spffail?"
>>>>> Fri, 01 Dec 2006 12:32:36 GMT

Mark> I use SRS on *all* outgoing mail. It's extremely useful for
Mark> detecting fake DSNs. That alone makes it very worthwhile. I
Mark> never get even a single fake DSN here.

Indeed!

Mark> If you want an introduction to the concepts, I wrote some
Mark> info about it, a while back:

Mark> http://srs-socketmap.info/documentation.html

Where is the part on SRS integration with Postfix? Anybody?

jam

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

On Fri, 01 Dec 2006 08:32:55 -0500 "John A. Martin" <jam@jamux.com> wrote:
>>>>>> "Mark" == Mark
>>>>>> "RE: private relay ... could i use srs to avoid spffail?"
>>>>>> Fri, 01 Dec 2006 12:32:36 GMT
>
> Mark> I use SRS on *all* outgoing mail. It's extremely useful for
> Mark> detecting fake DSNs. That alone makes it very worthwhile. I
> Mark> never get even a single fake DSN here.
>
>Indeed!
>
> Mark> If you want an introduction to the concepts, I wrote some
> Mark> info about it, a while back:
>
> Mark> http://srs-socketmap.info/documentation.html
>
>Where is the part on SRS integration with Postfix? Anybody?
>
> jam
>
I think you'd have to use a filter. I'm not aware of an appropriate
implementation. I have hopes for milter enhancements in Postfix 2.4.

Scott K

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

On Fri, 1 Dec 2006, David Woodhouse wrote:

> > i think (please correct me if i'm wrong!) this would cause spf failure
> > .... if someone@domain.com is using SPF on domain.com, this would cause
> > spf failure if delivered via my relay
>
> Yes, but that would be the fault of the recipient -- they should stop
> using SPF if it's rejecting valid mail.

This is correct in the case of forwarding initiated by the receiver.
Receivers should never check SPF for non-SRS forwarders.

However, it doesn't sound like this is not a case of receiver forwarding,
because he said "from a certain network". It sounds like he is
providing an SMTP relay service for senders. In which case, the
*senders* need to mention the relay in their SPF records (if any).
If they can't do that for some reason, then you can't use the original
sender domain in MAIL FROM, and must rewrite MAIL FROM is some fashion
(e.g. SRS).

> I recommend that you don't use SRS on forwarded mail. If you find you
> have problems with people rejecting mail for SPF failure, contact them
> and explain that they should not be using SPF. It usually seems to work
> on the people who've been taken in by the SPF 'marketing' and who didn't
> realise that SPF was incompatible with mail in the real world today.

This is basically correct, except David seems to be anti-SPF, and you should
actually contact them and explain that they should not be using SPF *for their
own forwarders* - duh. Since David is a forwarder, that takes care of his
problem without throwing the baby out with the bathwater.

Many large domains do not provide a way to configure or track their
end-users forwarders. Those domains should indeed stop rejecting on SPF
at all. But it is still helpful to publish SPF so that the rest of us
can reject all the forgeries - since these domains (yahoo.com,
hotmail.com, etc) tend to be the most forged. (Yahoo doesn't publish
SPF, but I configure a subsitute policy of "v=spf1 ptr -all" since all
their outgoing server names end in "yahoo.com".)

--
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/?list_id=1129

David Woodhouse writes:
> On Fri, 2006-12-01 at 12:22 +0000, Camart Ltd wrote:
> > Aha! That was my next question - whether it is easy/possible to use SRS
> > for *relay* rather than *forwarding* ... all the documentation I have
> > been able to find has, understandably, only discussed forwarding.
>
> I was talking about forwarding. I assume that by 'relay' you just mean
> operating as an MX backup? In that case, the recipients _definitely_
> shouldn't be rejecting mail due to SPF failures. Or you mean operating
> as an _outgoing_ SMTP smarthost for people? In which case they shouldn't
> be publishing SPF records which don't include your server(s).

He said his interest was in intercepting outgoing SMTP connections
from temporary visitors to his network. Whether such intercepting
should be considered relaying or forwarding is immaterial if you use
SRS for all outgoing mail. I use SRS for all outgoing mail, and I
have done intercepting occasionally. (Intercepting allows me to
AV-scan outgoing mail and block outgoing viruses from hosted servers
that have become infected, while allowing uninfected mail flow to
continue.)

> There will _always_ be receiving mailservers out there which reject your
> mail for spurious reasons.

This is one of the few things David and I agree on, although we
disagree considerably about what reasons are 'spurious'. In my view,
the benefits of SPF outweigh the drawbacks, so I encourage people to
use SPF, and I work around the forwarding rejections by using SRS.

However, SRS itself has its own drawbacks. If you rewrite MAIL FROM
adresses with SRS, some sites will reject mail from you due to the
unusual (but RFC-allowed) characters in the return addresses.

If you use SRS to reject bogus DSNs, you will also reject return
receipts from Outlook (and probably Outlook Express) users. This
isn't much of an issue for most people, but I happen to have a number
of users who use and want return receipts, so I have to make provision
for these special cases.

Rejecting non-SRS DSNs also rejects responses from some
autoresponders. While many people might think of this as a Good
Thing, I have users who consider out-of-office notifications
valuable.

Rejecting non-SRS DSNs naively also rejects postmaster-verification
callbacks, causing some sites to reject your mail.

--
Dick St.Peters, stpeters@NetHeaven.com
Gatekeeper, NetHeaven, Saratoga Springs, NY

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

In <200612011232.kB1CWW2n038619@asarian-host.net> Mark <admin@asarian-host.net> writes:

> I use SRS on *all* outgoing mail. It's extremely useful for detecting fake
> DSNs. That alone makes it very worthwhile. I never get even a single fake
> DSN here.

Doesn't doing SRS on all outgoing email cause problems with certain
mailing lists (ezlm?), vacation programs and other (broken) stuff that
assumes the 2821.MAILFROM stays constant?

Some people have also suggested that by using SRS on all outgoing
email lets you reject bogus bounces, but in order to do that you have
to make sure that *ALL* legitimate email sent using your domain name
gets processed by SRS. Roaming users and people working form home and
such have to be tought to always use RFC2476's SMTP submission port
(587).


-wayne

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

On Fri, 2006-12-01 at 08:39 -0600, wayne wrote:
> Doesn't doing SRS on all outgoing email cause problems with certain
> mailing lists (ezlm?), vacation programs and other (broken) stuff that
> assumes the 2821.MAILFROM stays constant?

Yes, that's the theory. Ironically, in practice the only mailing list
with which I've had a problem was the one we set up to discuss precisely
this, which ended up being called 'SES' before people starting hanging
all kinds of other things on it and it went off into the weeds.

I haven't actually noticed any broken vacation messages going missing,
although I'm sure it'll have happened. In practice, most broken vacation
messages which don't use MAIL FROM:<> will _also_ make the mistake of
sending back to the From: address instead of the reverse-path. So they
get through anyway.

> Some people have also suggested that by using SRS on all outgoing
> email lets you reject bogus bounces, but in order to do that you have
> to make sure that *ALL* legitimate email sent using your domain name
> gets processed by SRS. Roaming users and people working form home and
> such have to be tought to always use RFC2476's SMTP submission port
> (587).

In my case it's a per-user setting. Users can opt in (or opt out; it
varies from domain to domain).

--
dwmw2

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

In <17776.15222.910009.720786@saint.heaven.net> "Dick St.Peters" <stpeters@netheaven.com> writes:

> If you use SRS to reject bogus DSNs, you will also reject return
> receipts from Outlook (and probably Outlook Express) users.

Are you saying that Outlook doesn't send DSNs to the 2821.MAILFROM, as
RFC3834 says to? If so, what does it send it to instead?


> Rejecting non-SRS DSNs also rejects responses from some
> autoresponders. While many people might think of this as a Good
> Thing, I have users who consider out-of-office notifications
> valuable.

Again, it sounds like those systems are broken by not sending to the
2821.MAILFROM.


> Rejecting non-SRS DSNs naively also rejects postmaster-verification
> callbacks, causing some sites to reject your mail.

Again, those systems sound broken. If a call-back verification is
checking the 2821.MAILFROM, it should give use a NULL MAIL FROM on the
check (and a RCPT TO do the original 2821.MAILFROM). If the call-back
verification is using something like the 2822.From: header, it should
use something like <postmaster@domain-using-cbv.tld> as the
2821.MAILFROM.



Yeah, I know, lots of broken systems out there and people may well
want to accept email from them. I'm just curious about your
experiences with using SRS on everything.


-wayne

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

On Fri, 1 Dec 2006, wayne wrote:

> Doesn't doing SRS on all outgoing email cause problems with certain
> mailing lists (ezlm?), vacation programs and other (broken) stuff that
> assumes the 2821.MAILFROM stays constant?

Yes it does. Another problem is broken MTAs that think '+' is an
illegal localpart char. I have a small list of broken MTAs and disable
SRS when sending to those domains. I reject DSNs from the
broken MTAs (if they do CBV *and* have broken MTA, I just don't deal
with them). Ironically, one of the broken MTAs is/was the MTA
for the SES mailing list (which suffers from the same problem).
This approach might not scale, however.

> Some people have also suggested that by using SRS on all outgoing
> email lets you reject bogus bounces, but in order to do that you have
> to make sure that *ALL* legitimate email sent using your domain name
> gets processed by SRS. Roaming users and people working form home and
> such have to be tought to always use RFC2476's SMTP submission port
> (587).

Making roaming users always relay through home is essential for a decent
SPF policy also. Note that Outlook must use smtps (465) instead.
Another solution is an SSH tunnel (e.g. Putty for Windows) or a VPN.

--
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/?list_id=1129

In <Pine.LNX.4.44.0612010948500.14609-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> On Fri, 1 Dec 2006, wayne wrote:
>
>> Doesn't doing SRS on all outgoing email cause problems with certain
>> mailing lists (ezlm?), vacation programs and other (broken) stuff that
>> assumes the 2821.MAILFROM stays constant?
>
> Yes it does. Another problem is broken MTAs that think '+' is an
> illegal localpart char.

Huh... I thought "plus addressing" was very common. I wonder how
much legitimate email those systems lose.

Are there any other characters used by SRS that cause problems? The
equals or the dash?

I seem to recall several other characters causing way too many
problems, even though they are valid according to RFC2821.



>> Some people have also suggested that by using SRS on all outgoing
>> email lets you reject bogus bounces, but in order to do that you have
>> to make sure that *ALL* legitimate email sent using your domain name
>> gets processed by SRS. Roaming users and people working form home and
>> such have to be tought to always use RFC2476's SMTP submission port
>> (587).
>
> Making roaming users always relay through home is essential for a decent
> SPF policy also. Note that Outlook must use smtps (465) instead.
> Another solution is an SSH tunnel (e.g. Putty for Windows) or a VPN.

Right, and using the submission port is also important for things like
DK/DKIM. I strongly support this in all cases, but I realize that it
will take a fair amount of work on the domain owners part to make sure
that this happens.

This is actually one place that SPF can help, even if you prefer other
systems. By putting a "tracking exists" in an SPF record and
monitoring your name server logs, you can often tell who is not
relaying email through your authorized MTAs. Just use something like:

domain.tld TXT "v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all"


-wayne

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

On Fri, 2006-12-01 at 08:51 -0600, wayne wrote:
> In <17776.15222.910009.720786@saint.heaven.net> "Dick St.Peters" <stpeters@netheaven.com> writes:
>
> > If you use SRS to reject bogus DSNs, you will also reject return
> > receipts from Outlook (and probably Outlook Express) users.
>
> Are you saying that Outlook doesn't send DSNs to the 2821.MAILFROM, as
> RFC3834 says to? If so, what does it send it to instead?
>
>
> > Rejecting non-SRS DSNs also rejects responses from some
> > autoresponders. While many people might think of this as a Good
> > Thing, I have users who consider out-of-office notifications
> > valuable.
>
> Again, it sounds like those systems are broken by not sending to the
> 2821.MAILFROM.

Thankfully, a significant number of systems which are broken enough to
send to the wrong address will _also_ send _from_ the wrong address, and
thus their brokenness cancels itself out :)

> > Rejecting non-SRS DSNs naively also rejects postmaster-verification
> > callbacks, causing some sites to reject your mail.
>
> Again, those systems sound broken. If a call-back verification is
> checking the 2821.MAILFROM, it should give use a NULL MAIL FROM on the
> check (and a RCPT TO do the original 2821.MAILFROM). If the call-back
> verification is using something like the 2822.From: header, it should
> use something like <postmaster@domain-using-cbv.tld> as the
> 2821.MAILFROM.

Postfix gets this wrong -- it does callouts to the MAILFROM address but
with a non-empty MAILFROM of its own. I had to accept mail from
postmaster@.* to the SRS addresses. Other than that, I haven't really
had any problem (apart from the ses list, as I just said).


Btw, you don't actually _need_ to submit mail through the official
servers to use SRS on all mail -- my laptop will do the SRS for itself
on outgoing mail, and can send via any route.

--
dwmw2

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

On 12/1/06 10:08 AM, "wayne" <wayne@schlitt.net> wrote:
>
> This is actually one place that SPF can help, even if you prefer other
> systems. By putting a "tracking exists" in an SPF record and
> monitoring your name server logs, you can often tell who is not
> relaying email through your authorized MTAs. Just use something like:
>
> domain.tld TXT "v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all"
>

I do not follow this 'tracking exists' record...could you explain in a
little more detail please?!?

Thanks
Michael Weiner


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

>>>>> "David" == David Woodhouse
>>>>> "Re: private relay ... could i use srs to avoid spf fail?"
>>>>> Fri, 01 Dec 2006 15:13:20 +0000

David> Postfix gets this wrong -- it does callouts to the MAILFROM
David> address but with a non-empty MAILFROM of its own.

Postfix gets it right by providing a configuration option. Try

postconf -e "address_verify_sender = <>"

One might argue about the default value but it is the responsibility
of the administrator of the MTA to select the appropriate options.
That is why there are options.

jam

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

> -----Original Message-----
> From: wayne [mailto:wayne@schlitt.net]
> Sent: vrijdag 1 december 2006 15:40
> To: SRS discussions
> Subject: Re: [srs-discuss] private relay ... could i use srs
> to avoid spffail?
>
>
> In <200612011232.kB1CWW2n038619@asarian-host.net> Mark
> <admin@asarian-host.net> writes:
>
> > I use SRS on *all* outgoing mail. It's extremely useful for
> > detecting fake DSNs. That alone makes it very worthwhile. I never
> > get even a single fake DSN here.
>
> Doesn't doing SRS on all outgoing email cause problems with certain
> mailing lists (ezlm?), vacation programs and other (broken) stuff
> that assumes the 2821.MAILFROM stays constant?

Dunno about constant; but ezlm, for one, uses the envelope-from to
determine a person's subscription-status (I think it's configurable
actually). They, too, should not be doing that, really (and use mail
header info instead). So, yes; those rare cases can cause an issue. I have
a short SRS exempt-list for those.

But like M$ doing pseudo-callbacks, with the From: identity, that's just a
matter of dealing with very broken software. And no, I do not compensate
for Outlook (Express) idiocy. If ppl complain, let them write a letter to
M$ and ask them to read an RFC or two.

> Some people have also suggested that by using SRS on all outgoing
> email lets you reject bogus bounces, but in order to do that you have
> to make sure that *ALL* legitimate email sent using your domain name
> gets processed by SRS. Roaming users and people working form home and
> such have to be tought to always use RFC2476's SMTP submission port
> (587).

Indeed. That's a good thing to teach em anyway; not just for SRS. :)

- 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/?list_id=1129

> -----Original Message-----
> From: Stuart D. Gathman [mailto:stuart@bmsi.com]
> Sent: vrijdag 1 december 2006 15:57
> To: SRS discussions
> Subject: Re: [srs-discuss] private relay ... could i use srs
> to avoid spffail?
>
>
> Yes it does. Another problem is broken MTAs that think '+' is
> an illegal localpart char.

Sendmail has been doing "plussed" addresses for ages. Rejecting "plussed"
addresses is dead wrong. And I honestly cannot believe there's still major
MTA software out there (like sendmail or postfix) that would still do
that.

In abundance perhaps, but neither SPF nor SRS can be blamed for such
gross brokenness, of course. Who'd wanna run a broken mail server like
that anyway?

- 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/?list_id=1129

> -----Original Message-----
> From: Dick St.Peters [mailto:stpeters@netheaven.com]
> Sent: vrijdag 1 december 2006 15:26
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] private relay ... could i use srs
> to avoid spffail?
>
>
> Rejecting non-SRS DSNs naively also rejects postmaster-verification
> callbacks, causing some sites to reject your mail.

I exempt those, too (RCPT TO: postmaster|abuse), cuz I don't want
some crazed person causing me to be RFC-I listed.

- 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/?list_id=1129

On Fri, 2006-12-01 at 10:39 -0500, John A. Martin wrote:
>
> David> Postfix gets this wrong -- it does callouts to the MAILFROM
> David> address but with a non-empty MAILFROM of its own.
>
> Postfix gets it right by providing a configuration option. Try
>
> postconf -e "address_verify_sender = <>"
>
> One might argue about the default value but it is the responsibility
> of the administrator of the MTA to select the appropriate options.
> That is why there are options.

Admins are stupid beasts and are prone to shooting themselves in the
foot. SPF is a wonderful example of that :)

I think Exim has it "right", because although you can configure the
reverse-path used for _recipient_ callouts, you _cannot_ do sender
callouts with anything but the (correct) MAIL FROM:<>. Thus, even the
dimmest of admins doesn't get to make that particular mistake.

--
dwmw2

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