You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by John Andersen <js...@pen.homeip.net> on 2006/09/04 22:17:26 UTC
Use Fetchmail = SPF_FAIL
I notice (on my personal machine) that mail I fetch via Fetchmail will fail
the SPF tests if the original sender's system used SPF.
This does not seem all that unusual a setup to use in the linux world, and one
that SPF tests should be able to handle, so I'm suspecting there may be a
setup problem somewhere.
In this case the spf tests were seemingly applied to the last mailserver
(my ISP's mail server) rather than the originator's mail server, and then this
last mail server is tested against the originator's SPF records.
The (simplified) route was:
Received: from pen.homeip.net
Received: from v-msgmmp.gci.net by pen.homeip.net with POP3 (fetchmail-6.3.2)
Received: from msgmta-3.gci.net by mailstore-1.gci.net
Received: from psmtp.com by msgmta-3.gci.net
Received: from <aweb-site-of-mine> by exprod6mx139.postini.com
Received: from utl-lnx3.puk.ac.za by <aweb-site-of-mine>.com with
Received: from pcm-nov-gwia-server.puk.ac.za by utl-lnx3.puk.ac.za
Received: from PUKGWIA-MTA by pcm-nov-gwia-server.puk.ac.za
The spf-fail was reported because is msgmta-3.gci.net (my ISP)
is not a sender for puknet.puk.ac.za.
--
_____________________________________
John Andersen
Re: Use Fetchmail = SPF_FAIL
Posted by jdow <jd...@earthlink.net>.
From: "John Andersen" <js...@pen.homeip.net>
> Received: from pen.homeip.net
You appear to run the output of fetchmail through a mail server.
FWIW I do not see this error you have and I simply have fetchmail
call procmail to throw the email into the /var/spool/mail folder.
I skip sendmail entirely.
{^_^}
Re: Use Fetchmail = SPF_FAIL
Posted by jdow <jd...@earthlink.net>.
From: "John Andersen" <js...@pen.homeip.net>
>> Did you configure SA to trust msgmta-3.gci.net?
>
> Heck no, its my clueless ISP, from which I get a ton of spam. ;-)
This trust is not "trust them not to send spam." This is trust not
to forge headers even when relaying spam. Trust them and see what
happens.
{^_^}
Re: Use Fetchmail = SPF_FAIL
Posted by John Andersen <js...@pen.homeip.net>.
On Monday 04 September 2006 12:26, Daryl C. W. O'Shea wrote:
> On 9/4/2006 4:17 PM, John Andersen wrote:
> > I notice (on my personal machine) that mail I fetch via Fetchmail will
> > fail the SPF tests if the original sender's system used SPF.
> >
> > This does not seem all that unusual a setup to use in the linux world,
> > and one that SPF tests should be able to handle, so I'm suspecting there
> > may be a setup problem somewhere.
> >
> > In this case the spf tests were seemingly applied to the last mailserver
> > (my ISP's mail server) rather than the originator's mail server, and then
> > this last mail server is tested against the originator's SPF records.
> >
> > The spf-fail was reported because is msgmta-3.gci.net (my ISP)
> > is not a sender for puknet.puk.ac.za.
>
> Did you configure SA to trust msgmta-3.gci.net?
Heck no, its my clueless ISP, from which I get a ton of spam. ;-)
--
_____________________________________
John Andersen
Re: Use Fetchmail = SPF_FAIL
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 9/4/2006 4:17 PM, John Andersen wrote:
> I notice (on my personal machine) that mail I fetch via Fetchmail will fail
> the SPF tests if the original sender's system used SPF.
>
> This does not seem all that unusual a setup to use in the linux world, and one
> that SPF tests should be able to handle, so I'm suspecting there may be a
> setup problem somewhere.
>
> In this case the spf tests were seemingly applied to the last mailserver
> (my ISP's mail server) rather than the originator's mail server, and then this
> last mail server is tested against the originator's SPF records.
> The spf-fail was reported because is msgmta-3.gci.net (my ISP)
> is not a sender for puknet.puk.ac.za.
Did you configure SA to trust msgmta-3.gci.net?
Daryl
Re: Use Fetchmail = SPF_FAIL
Posted by "John D. Hardin" <jh...@impsec.org>.
On Mon, 4 Sep 2006, John Andersen wrote:
> > MTA SPF should only be run on a mail relay that is receiving messages
> > directly from the Internet.
>
> Most of my mail comes direct to pen.homeip.net
> Maybe 2% I pop via Fetchmail
ok.
> > > Received: from utl-lnx3.puk.ac.za by <aweb-site-of-mine>.com with
> >
> > You MAY be able to get SPF within SA on pen.homeip.net to work by
> > extending your trusted hosts list out to include postini, or to
> > <aweb-site-of-mine>.com
>
> Would I not have to trust every thing along the path? My ISP,
> postini, and the hosting company <aweb-site-of-mine>.com ? And
> would this trust also have to mention one of the 6 or 7 mail
> servers my ISP uses and all of them at postini?
Maybe, I am not sure; I've never had to do any complex tweaking of
trust path.
> > Alternatively, you may want to perform MTA SPF checks at
> > <aweb-site-of-mine>.com (assuming, of course, that you have the
> > necessary level of administrative access), as it is directly exposed
> > to inbound email from the Internet at large. You may also want to run
> > SA *there* (same assumption), unless pen.homeip.net aggregates several
> > mail feeds.
>
> No, that's just a hosting company, I have no control of them.
You might lobby them to at least make SPF checks an option and let
their customers decide whether or not they wish to do the checks.
'course, given the direct mail to pen.homeip.net that still wouldn't
fix your problem.
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
-----------------------------------------------------------------------
13 days until The 219th anniversary of the signing of the U.S. Constitution
Re: Use Fetchmail = SPF_FAIL
Posted by John Andersen <js...@pen.homeip.net>.
Thanks John, See comments imbedded
On Monday 04 September 2006 12:37, John D. Hardin wrote:
> On Mon, 4 Sep 2006, John Andersen wrote:
> > This does not seem all that unusual a setup to use in the linux
> > world, and one that SPF tests should be able to handle, so I'm
> > suspecting there may be a setup problem somewhere.
>
> MTA SPF should only be run on a mail relay that is receiving messages
> directly from the Internet.
Most of my mail comes direct to pen.homeip.net
Maybe 2% I pop via Fetchmail
> I'll assume that you're talking about SPF tests within SA.
>
> > In this case the spf tests were seemingly applied to the last
> > mailserver (my ISP's mail server) rather than the originator's
> > mail server, and then this last mail server is tested against the
> > originator's SPF records.
> >
> > The (simplified) route was:
> >
> > Received: from pen.homeip.net
> >
> > Received: from v-msgmmp.gci.net by pen.homeip.net with POP3
> > (fetchmail-6.3.2)
> >
> > Received: from msgmta-3.gci.net by mailstore-1.gci.net
> >
> > Received: from psmtp.com by msgmta-3.gci.net
> >
> > Received: from <aweb-site-of-mine> by exprod6mx139.postini.com
>
> Urk. I suspect shipping all of your mail through Postini will make SPF
> past that point useless. Do they do proper sender rewriting (SRS)?
Yes, this is the problem I suspect, my ISP sends everything thru postini
and as you may know they sort of change their routing at will...
Side rant: I don't trust postini. They are big enough that they attract a
lot of spammer attention I've seen faked headers pretending to be postini
in the past.
> > Received: from utl-lnx3.puk.ac.za by <aweb-site-of-mine>.com with
>
> You MAY be able to get SPF within SA on pen.homeip.net to work by
> extending your trusted hosts list out to include postini, or to
> <aweb-site-of-mine>.com
Would I not have to trust every thing along the path? My ISP, postini,
and the hosting company <aweb-site-of-mine>.com ? And would
this trust also have to mention one of the 6 or 7 mail servers my ISP
uses and all of them at postini?
> > Received: from pcm-nov-gwia-server.puk.ac.za by utl-lnx3.puk.ac.za
> >
> > Received: from PUKGWIA-MTA by pcm-nov-gwia-server.puk.ac.za
> >
> > The spf-fail was reported because is msgmta-3.gci.net (my ISP)
> > is not a sender for puknet.puk.ac.za.
>
> It sounds like <aweb-site-of-mine>.com should be on your trusted hosts
> list. That would probable cue SA in to do the SPF tests from that POV
> rather than from the POV of pen.homeip.net.
>
> I'm not intimately familiar with trust path issues the way some others
> here are. I don't know if having a trusted host in the middle of a
> sequence of untrusted hosts will cause problems.
The wiki is not terribly clear on this point either.
I can try extending trust to the hosting company and see what happens.
> Alternatively, you may want to perform MTA SPF checks at
> <aweb-site-of-mine>.com (assuming, of course, that you have the
> necessary level of administrative access), as it is directly exposed
> to inbound email from the Internet at large. You may also want to run
> SA *there* (same assumption), unless pen.homeip.net aggregates several
> mail feeds.
No, that's just a hosting company, I have no control of them.
--
_____________________________________
John Andersen
Re: Use Fetchmail = SPF_FAIL
Posted by "John D. Hardin" <jh...@impsec.org>.
On Mon, 4 Sep 2006, John Andersen wrote:
> This does not seem all that unusual a setup to use in the linux
> world, and one that SPF tests should be able to handle, so I'm
> suspecting there may be a setup problem somewhere.
MTA SPF should only be run on a mail relay that is receiving messages
directly from the Internet.
I'll assume that you're talking about SPF tests within SA.
> In this case the spf tests were seemingly applied to the last
> mailserver (my ISP's mail server) rather than the originator's
> mail server, and then this last mail server is tested against the
> originator's SPF records.
>
> The (simplified) route was:
>
> Received: from pen.homeip.net
>
> Received: from v-msgmmp.gci.net by pen.homeip.net with POP3 (fetchmail-6.3.2)
>
> Received: from msgmta-3.gci.net by mailstore-1.gci.net
>
> Received: from psmtp.com by msgmta-3.gci.net
>
> Received: from <aweb-site-of-mine> by exprod6mx139.postini.com
Urk. I suspect shipping all of your mail through Postini will make SPF
past that point useless. Do they do proper sender rewriting (SRS)?
> Received: from utl-lnx3.puk.ac.za by <aweb-site-of-mine>.com with
You MAY be able to get SPF within SA on pen.homeip.net to work by
extending your trusted hosts list out to include postini, or to
<aweb-site-of-mine>.com
> Received: from pcm-nov-gwia-server.puk.ac.za by utl-lnx3.puk.ac.za
>
> Received: from PUKGWIA-MTA by pcm-nov-gwia-server.puk.ac.za
>
> The spf-fail was reported because is msgmta-3.gci.net (my ISP)
> is not a sender for puknet.puk.ac.za.
It sounds like <aweb-site-of-mine>.com should be on your trusted hosts
list. That would probable cue SA in to do the SPF tests from that POV
rather than from the POV of pen.homeip.net.
I'm not intimately familiar with trust path issues the way some others
here are. I don't know if having a trusted host in the middle of a
sequence of untrusted hosts will cause problems.
Alternatively, you may want to perform MTA SPF checks at
<aweb-site-of-mine>.com (assuming, of course, that you have the
necessary level of administrative access), as it is directly exposed
to inbound email from the Internet at large. You may also want to run
SA *there* (same assumption), unless pen.homeip.net aggregates several
mail feeds.
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
-----------------------------------------------------------------------
13 days until The 219th anniversary of the signing of the U.S. Constitution