Mailing List Archive

More on Testing SRS
Interesting i just got a bounce from the dk mailing list on sourceforge.
net as in the following:

The original message was received at Sun, 13 Jun 2004 11:16:23 -0400
from dsl-eth0.userfriendly.net [68.22.33.182] (may be forged)

----- The following addresses had permanent fatal errors -----
<dk-milter-discuss-request@lists.sourceforge.net>
(reason: 550-Verification failed for
<SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>)

----- Transcript of session follows -----
... while talking to mail.sourceforge.net.:
>>> DATA
<<< 550-Verification failed for
<SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
<<< 550-Called: 68.22.33.177
<<< 550-Sent: RCPT TO:
<SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
<<< 550-Response: 550 5.1.1
<SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>... User
unknown
<<< 550 Sender verify failed
550 5.1.1 <dk-milter-discuss-request@lists.sourceforge.net>... User
unknown
<<< 503 valid RCPT command must precede DATA

At least this confirms that my MTA is truly doing the envelope rewriting
but IS this verification failing on MY end or as i take it, on SF's
end???

Michael Weiner
Systems Administrator
The UserFriendly Network (UFN)

-------
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: More on Testing SRS [ In reply to ]
On Sun, 2004-06-13 at 08:15, Michael Weiner wrote:
> Interesting i just got a bounce from the dk mailing list on sourceforge.
> net as in the following:
>
> The original message was received at Sun, 13 Jun 2004 11:16:23 -0400
> from dsl-eth0.userfriendly.net [68.22.33.182] (may be forged)
>
> ----- The following addresses had permanent fatal errors -----
> <dk-milter-discuss-request@lists.sourceforge.net>
> (reason: 550-Verification failed for
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>)
>
> ----- Transcript of session follows -----
> ... while talking to mail.sourceforge.net.:
> >>> DATA
> <<< 550-Verification failed for
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
> <<< 550-Called: 68.22.33.177
> <<< 550-Sent: RCPT TO:
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
> <<< 550-Response: 550 5.1.1
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>... User
> unknown
> <<< 550 Sender verify failed
> 550 5.1.1 <dk-milter-discuss-request@lists.sourceforge.net>... User
> unknown
> <<< 503 valid RCPT command must precede DATA
>
> At least this confirms that my MTA is truly doing the envelope rewriting
> but IS this verification failing on MY end or as i take it, on SF's
> end???

It helps a lot if you can include the e-mail with the full un-cut
headers. Its hard to speculate otherwise. It appears as you you sent
an email to yourself through sourceforge or ?

Cheers,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
XML is WRONG, and here it doesn't BELONG.
Neither in SPF, nor inside of DNS,
its fat and its bloated and so I express:
JSON - "The FAT FREE alternative to XML"
http://www.crockford.com/JSON/xml.html
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: More on Testing SRS [ In reply to ]
> From: Michael Weiner
> Sent: Sunday, June 13, 2004 10:16 AM
>
>
> Interesting i just got a bounce from the dk mailing list on sourceforge.
> net as in the following:
>
> The original message was received at Sun, 13 Jun 2004 11:16:23 -0400
> from dsl-eth0.userfriendly.net [68.22.33.182] (may be forged)

OK, this is your domain. The PTR record for this IP is
adsl-68-22-33-182.dsl.bcvloh.ameritech.net, which probably explains the (may
be forged) warning. The A record for that host name point to the same IP,
so it's could just be your HELO string.

>
> ----- The following addresses had permanent fatal errors -----
> <dk-milter-discuss-request@lists.sourceforge.net>
> (reason: 550-Verification failed for
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>)

It looks like they are running a DomainKeys milter, but it is smart enough
to recognize an SRS-rewritten address.

>
> ----- Transcript of session follows -----
> ... while talking to mail.sourceforge.net.:
> >>> DATA
> <<< 550-Verification failed for
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
> <<< 550-Called: 68.22.33.177

Their milter did a sender callback (CBV) to your MX to validate the
SRS-signed MAIL FROM: address. Nice anti-spoofing touch on their part.

> <<< 550-Sent: RCPT TO:
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>
> <<< 550-Response: 550 5.1.1
> <SRS0=fTrgIqYi=JG=userfriendly.net=hunter@userfriendly.net>... User
> unknown

Your MX responded negatively to the CBV. It looks like the problem is at
your end.

> <<< 550 Sender verify failed
> 550 5.1.1 <dk-milter-discuss-request@lists.sourceforge.net>... User
> unknown
> <<< 503 valid RCPT command must precede DATA

SourceForge did the right thing. The sending system said the MAIL FROM:
address was no good, so SourceForge the mail.

>
> At least this confirms that my MTA is truly doing the envelope rewriting
> but IS this verification failing on MY end or as i take it, on SF's
> end???

Look like you need to configure your MX to respond to CBV's, and it must
have the capability of validating SRS-signed addresses.

--

Seth Goodman
RE: More on Testing SRS [ In reply to ]
On Sun, 2004-06-13 at 12:17 -0500, Seth Goodman wrote:
> Your MX responded negatively to the CBV. It looks like the problem is at
> your end.

> SourceForge did the right thing. The sending system said the MAIL FROM:
> address was no good, so SourceForge the mail.
>
> Look like you need to configure your MX to respond to CBV's, and it must
> have the capability of validating SRS-signed addresses.

Where i wouldnt disagree, i DO have the SRS stuff in sendmail, so i am
not sure why thats not working. I have sendmail currently configured as
in the description found at:

http://asarian-host.net/srs/sendmailsrs.htm

and the checks performed there work correctly.

As for CBV responses, what is your suggestion for a sendmail MTA ? Any
helpful "tip" pages?

Michael Weiner

-------
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: More on Testing SRS [ In reply to ]
> On Sun, 2004-06-13 at 12:17 -0500, Seth Goodman wrote:
>
> > SourceForge did the right thing. The sending system said the MAIL
> > FROM: address was no good, so SourceForge the mail.
> >
> > Look like you need to configure your MX to respond to CBV's, and it
> > must have the capability of validating SRS-signed addresses.
>
> i DO have the SRS stuff in sendmail, so i am not sure why thats
> not working. I have sendmail currently configured as in the
> description found at:
>
> http://asarian-host.net/srs/sendmailsrs.htm
>
> and the checks performed there work correctly.
>
> As for CBV responses, what is your suggestion for a sendmail MTA?

As Seth has already pointed out, your MX needs to be able to validate SRS
signed addresses. You can easily test this by generating a valid SRS address
(your outgoing mailserver already does that correctly), and telnet to your
MX, on port 25, to validate the SRS signed RCPT TO address.

You will need to tell a bit more about your setup. Does your MX use a Milter
at the gate? Or do you have sendmail validate the SRS recipients directly,
using the srs2envtol.pl script? A Milter will, of course, give you a bit
more colorful error codes, but requires some extra steps.

Cheers,

- Mark

System Administrator Asarian-host.org

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