Mailing List Archive

Would SRS solve this problem?
I need help solving a situation where a sender's message is being rejected
after going through a legitimate e-mail spam/virus filtering service.
Here is the 'real-world' example:

Sender is someone at kroll.com.

kroll.com's TXT record is:
"v=spf1 redirect=krollworldwide.com"
krollworldwide.com has this:
"v=spf1 ip4:208.71.237.0/24 ip4:193.37.237.0/24 ip4:207.12.234.129
ip4:208.71.238.38 ip4:217.77.181.100 ip4:204.13.136.221 -all"

The recipient is someone at platecoinc.com. The MX record for platecoinc.com
has mail going to server24.appriver.com

AppRiver is a spam/virus filtering company. When they have finished checking
for spam and viruses, mail is sent to 'mail.wegtech.com', which is where
the e-mail mailboxes for platecoinc.com are hosted.

When AppRiver attempts to pass along the 'clean' message from sender@kroll.com
to recip@platecoinc.com, the mail server (mail.wegtech.com) won't
accept it based on SPF. I discussed this with AppRiver a bit and they assure
me that "we do not 're-write the sender address from SPF checks.'"

Here's what shows up in AppRiver's log files:
-------------------------
4/21/2008
8:18:00 AM
SERVER25B sender@kroll.com
RE: paperless billing To: recip@platecoinc.com
IP: 208.71.237.35
VALID FROM UNITED STATES
08:18:02.467 4 SMTP-520276(mail.wegtech.com:25) Connected. SIZE AUTH
08:18:02.467 4 SMTP-520276(mail.wegtech.com:25) [286452055] sending
08:18:02.467 4 SMTP-520276(mail.wegtech.com:25) cmd: MAIL
FROM:<sender@kroll.com> SIZE=8372
08:18:02.748 4 SMTP-520276(mail.wegtech.com:25) rsp: 250 ok
08:18:02.748 4 SMTP-520276(mail.wegtech.com:25) cmd: RCPT
TO:<recip@platecoinc.com>
08:18:02.780 4 SMTP-520276(mail.wegtech.com:25) rsp: 553 See
http://spf.pobox.com/why.html?sender=sender%40kroll.com&ip=207.97.229.125&receiver=mail.powerwebhost.net
(#5.7.1)
08:18:02.780 1 DEQUEUER [286452055]
SMTP(mail.wegtech.com:25)recip@platecoinc.com failed: host
mail.wegtech.com:25 says:\r\n 553 See
http://spf.pobox.com/why.html?sender=sender%40kroll.com&ip=207.97.229.125&receiver=mail.powerwebhost.net
(#5.7.1)
-------------------------

My question is: Who is at fault and what needs to be done to correct the
situation? Is SRS the answer? How/where would SRS be applied in this case?

--
Cliff Nieuwenhuis
President
Foresite Software LLC
www.foresitesoftware.com
(608)356-0286

Foresite Software LLC is an IBM Business Partner

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/1129/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1129/
Powered by Listbox: http://www.listbox.com
Re: Would SRS solve this problem? [ In reply to ]
On Wed, 23 Apr 2008, Cliff Nieuwenhuis wrote:

> The recipient is someone at platecoinc.com. The MX record for platecoinc.com
> has mail going to server24.appriver.com
>
> AppRiver is a spam/virus filtering company. When they have finished checking
> for spam and viruses, mail is sent to 'mail.wegtech.com', which is where
> the e-mail mailboxes for platecoinc.com are hosted.
>
> When AppRiver attempts to pass along the 'clean' message from sender@kroll.com
> to recip@platecoinc.com, the mail server (mail.wegtech.com) won't
> accept it based on SPF. I discussed this with AppRiver a bit and they assure
> me that "we do not 're-write the sender address from SPF checks.'"

AppRiver is behaving reasonably - it is not their fault. The problem is the
recipient at platecoinc.com. Checking SPF for your own MX servers has got
to be the most idiotic thing people keep doing when implementing SPF.
Try to find someone at platecoinc.com and explain to them nicely
why checking SPF on your own MX is not the smartest idea.

There is no point in platecoinc.com checking SPF at all, in fact, since
essentially all their mail goes through AppRiver. Unless AppRiver
checks it, or they look at the Received header from AppRiver instead
of using the connect IP, they cannot check SPF. When talking to
AppRiver, suggest that they add a Received-SPF header for clients to use.

Would SRS solve the problem? Well, it would stop the incorrect bounces,
but checking SPF would still be pointless for platecoinc, since the sending
domain would always be AppRiver! So there is no reason for AppRiver to waste
their time doing it.

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

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/1129/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1129/
Powered by Listbox: http://www.listbox.com