Re: Newbie-esque SPF deployment questions
On Fri, Jun 03, 2005 at 01:38:53AM +0200, Alex van den Bogaerdt wrote:
> > Important to note: sendmail is bound to mx1.parodius.com (64.62.145.229),
> > which is an IP alias on the same physical machine as the A record you
> > see for the actual domain itself (parodius.com). All SMTP traffic
> > (incoming and outgoing) is done over 64.62.145.229; and yes, I am 100%
> > sure of this. I just wanted to make that crystal clear. 
>
> That does include SpamAssassin+SPF ? You're sure that part
> isn't handled by pentarou.parodius.com ?
Well, technically it's all the same physical machine. But yes, I
suppose that statement would be true. SA (with SPF support) is run
under procmail using using spamc + spamd. spamd is bound to 127.0.0.1,
and spamc connects to 127.0.0.1 (when procmail is spawned). All of
these probably just blindly use gethostname(3) to look up the local
machine name...
Would binding spamd to mx1.parodius.com (and making spamc connect to
mx1.parodius.com) fix this situation? This is more of a SpamAssassin
question, I suppose. The problem I have with binding spamd to
mx1.parodius.com is that that's a public network interface, which means
more IP filters (for port 783).
> > However, since doing this, his own Emails are getting marked with a +0.5
> > in SpamAssassin score due to SPF lookups claiming SOFTFAIL:
> >
> > >> pts rule name description
> > >> ---- ---------------------- --------------------------------------------------
> > >> 0.5 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
> > >> [SPF failed: Please see http://spf.pobox.com/why.html?sender=username%40parodius.com&ip=65.95.32.147&receiver=pentarou.parodius.com]
>
> According to _your_ SpamAssassin, the host delivering this message
> you _your_ hosts is 65.95.32.147
>
> If the user is submitting the message, don't run it through SPF (or
> make sure he's allowed, whitelisted, whatever).
>
> If the SpamAssassin is called on the receiving end, the user is
> delivering the message directly from home in stead of via your
> infrastructure.
>
> user -> your infra (incl. SA+SPF) -> remote user (incl. himself)
> user -> your infra (no filter) -> remote user (himself, via SA+SPF)
>
> Maybe you can find out which of these two possibilities is the case.
Hmm, I'm slightly confused by your later comments, but here's how the
pathing works for what I call "outgoing" mail:
1. End-user (65.95.32.147) sends mail using mail client. Client is
configured to use mx1.parodius.com:587 as their SMTP server.
Client is sending mail to foobar <at> someplace.com.
2. mx1.parodius.com:587 receives connection from 65.95.32.147. This
IP is in the sendmail access_db list, and is permitted to do
relaying (i.e. send mail through us).
3. mx1.parodius.com accepts the message.
4. mx1.parodius.com does standard lookups (MX record, A record) on
someplace.com, and attempts to deliver the message to
foobar <at> someplace.com.
For "incoming" mail, the pathing works as follows:
1. Some SMTP server on the Internet (1.2.3.4) connects to
mx1.parodius.com:25. Mail is destined for username <at> parodius.com.
2. 1.2.3.4 isn't blocked by SBL+XBL, or listed as a spammer in our
access_db list, so the mail is accepted.
3. sendmail uses procmail as the LDA (local delivery agent).
4. procmail is spawned, and reads /etc/procmailrc, which requests
that the entire mail message by piped through spamc.
5. spamc connects to spamd (running on 127.0.0.1:783).
6. spamd does numerous spam checks (Bayes learning, rules matching,
and SPF lookups). spamd is configured with trusted_networks
64.62.145.224/27 (our network block) and internal_networks
64.62.145.229 (which is mx1.parodius.com).
7. spamd responds to spamc with the appropriate data, i.e. is the
mail spam, is it not spam, etc., does the appropriate changes
(modification to Subject: line to contain [spam], SpamAssassin
X-* headers, etc.)
8. spamc returns the modified content of the message to procmail
via the pipe in Step #4.
9. procmail delivers the mail to the mailbox /var/mail/username.
I'm still confused as to why SPF is claiming SOFTFAIL for the scenario
of when the user is sending mail to himself.
Is the problem caused by the fact that SA is doing the SPF lookup "too
late" in the mail delivery stage, via spamc+spamd across a procmail
pipe, rather than, for example, using a sendmail SPF milter?
Would adding an additional "a:" entry (for pentarou.parodius.com) to
our SPF record be the Right Thing(tm) to do?
Thanks so much, so far everyone here has been very helpful.
--
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. |
RSS Feed