You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by "Kevin A. McGrail" <KM...@PCCC.com> on 2011/06/23 20:41:18 UTC

SPF Record for issues.apache.org

> [Now if only the apache.org DNS administrator would insert an SPF record for
> bugzilla's use, the world would be one step closer to perfect.]  ;-)
>
Are you having deliverability issues that justify opening a JIRA ticket 
for this?  If so, I'm happy to ask.

Regards,
KAM

Re: [SA-dev] SPF Record for issues.apache.org

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> Like the bounce you just got for responding to
> bugzilla-daemon@issues.apache.org (much like responding to
> bugzilla-daemon@bugzilla.spamassassin.org)?  The bugzilla commenter will
> not see your reply.
I actually didn't get a bounce. System likely just ate it. But you are 
right that I shouldn't have emailed that.  Laziness on my part in moving 
the discussion off of bugzilla to dev where it belonged.
> % host -tmx bugzilla.spamassassin.org
> bugzilla.spamassassin.org is an alias for issues.apache.org.
> % host -tmx issues.apache.org.
> issues.apache.org has no MX record
>
> Oddly enough, it actually makes sense for that domain to lack an MX
> record since it doesn't accept /incoming/ mail.  That said,
> challenge-response and sender-verify (sender callouts, SAV) systems
> (both of which are bad practices for other reasons) break when unable to
> find a sender's MX.  Additionally, I believe some MTAs will block
> envelope-from domains lacking MX records wholesale.
An A record in the abscence of MX records is a defacto MX and is RFC Valid.

http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A
> Given that unconventional setup, SPF seems highly appropriate.
>
> Adding an incoming MTA is too, though that's a little bit more work (not
> much, just set the MX record to an existing one, add the virtuserdomain,
> /dev/null a few virtusers, forward the required postmaster@, and
> error:nouser the rest ... alternatively, make it a spam trap e.g. by
> talking to Marc Perkel).
>
I could argue they should configure DKIM and rPTRs and feeback loops 
with large ISPs and lots of other things but unless you are actually 
having delivery problems, I can't justify asking them to do it, sorry.


-- 
*Kevin A. McGrail*
President

Peregrine Computer Consulting Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422

http://www.pccc.com/

703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-359-8451 (fax)
KMcGrail@PCCC.com <ma...@pccc.com>


Re: [SA-dev] SPF Record for issues.apache.org

Posted by Adam Katz <an...@khopis.com>.
On 06/23/2011 11:41 AM, Kevin A. McGrail wrote:
>> [Now if only the apache.org DNS administrator would insert an SPF 
>> record for bugzilla's use, the world would be one step closer to
>> perfect.]  ;-)
>> 
> Are you having deliverability issues that justify opening a JIRA
> ticket for this?  If so, I'm happy to ask.

Like the bounce you just got for responding to
bugzilla-daemon@issues.apache.org (much like responding to
bugzilla-daemon@bugzilla.spamassassin.org)?  The bugzilla commenter will
not see your reply.

% host -tmx bugzilla.spamassassin.org
bugzilla.spamassassin.org is an alias for issues.apache.org.
% host -tmx issues.apache.org.
issues.apache.org has no MX record

Oddly enough, it actually makes sense for that domain to lack an MX
record since it doesn't accept /incoming/ mail.  That said,
challenge-response and sender-verify (sender callouts, SAV) systems
(both of which are bad practices for other reasons) break when unable to
find a sender's MX.  Additionally, I believe some MTAs will block
envelope-from domains lacking MX records wholesale.

Given that unconventional setup, SPF seems highly appropriate.

Adding an incoming MTA is too, though that's a little bit more work (not
much, just set the MX record to an existing one, add the virtuserdomain,
/dev/null a few virtusers, forward the required postmaster@, and
error:nouser the rest ... alternatively, make it a spam trap e.g. by
talking to Marc Perkel).