Re: New warning message...
In message <20130724094623.gb12...@nic.fr>, Stephane Bortzmeyer writes: > On Mon, Jul 22, 2013 at 12:39:53PM +0200, > Matus UHLAR - fantomas wrote > a message of 28 lines which said: > > > This was discussed here already, and imho this is anti-spf bullshit > > like all those "spf breaks forwarding" FUD. The SPF RR is already > > here and is preferred over TXT that is generik RR type, unlike SPF. > > I don't see any connection with anti-SPF stances. Whether you love or > despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF" > record (type 99) is not used at all and that the TXT record is now the > only one recommended (if you do SPF, which probably means you did not > believe the FUD). Which was a total mis-reporting of facts at the time. The current libraries DO lookup SPF records and fall back to TXT records. New implementations use SPF records. This was just a WG that was just plain impatient drawing wrong conclusions by doing surveys. Then deciding that the was a problem when there wasn't one at all. That over reacted and in doing so created even more long term problems that can't correct themselves over time. Then didn't want to hear that they were impatient and have overreacted. Mark > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
Hi Dan, At 03:07 24-07-2013, McDonald, Dan wrote: SPF RR types are already standards track - see RFC 6652. An informational rfc warning that the standard is not being adopted should be seen as a call to fix the admins, not discard the standard. The SPF specification is not on the Standards Track. RFC 6652 is about ARF. Regards, -sm ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
In message <20130724093737.ga12...@nic.fr>, Stephane Bortzmeyer writes: > On Mon, Jul 22, 2013 at 03:01:47PM +1000, > Mark Andrews wrote > a message of 56 lines which said: > > > It SHOULD have record of type SPF as per RFC 4408. Named will > > complain if both types are not present. > > Then, named is now wrong, since RFC 6686. RFC 6686 does *not* update RFC 4408. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Jul 24, 2013, at 4:48 AM, "Stephane Bortzmeyer" wrote: > On Mon, Jul 22, 2013 at 12:39:53PM +0200, > Matus UHLAR - fantomas wrote > a message of 28 lines which said: > >> This was discussed here already, [...] >> The SPF RR is already >> here and is preferred over TXT that is generik RR type, unlike SPF. > > Whether you love or > despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF" > record (type 99) is not used at all And so, to speed adoption of the SPF RR type, ISC is prompting admins to go back and look at their settings so that they can migrate. If a critical mass of admins publish SPF RR types, then the results of the experiment documented in rfc 6686 would be vastly different if repeated. SPF RR types are already standards track - see RFC 6652. An informational rfc warning that the standard is not being adopted should be seen as a call to fix the admins, not discard the standard. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, Jul 22, 2013 at 12:39:53PM +0200, Matus UHLAR - fantomas wrote a message of 28 lines which said: > This was discussed here already, and imho this is anti-spf bullshit > like all those "spf breaks forwarding" FUD. The SPF RR is already > here and is preferred over TXT that is generik RR type, unlike SPF. I don't see any connection with anti-SPF stances. Whether you love or despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF" record (type 99) is not used at all and that the TXT record is now the only one recommended (if you do SPF, which probably means you did not believe the FUD). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, Jul 22, 2013 at 03:01:47PM +1000, Mark Andrews wrote a message of 56 lines which said: > It SHOULD have record of type SPF as per RFC 4408. Named will > complain if both types are not present. Then, named is now wrong, since RFC 6686. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On 7/23/13 7:36 AM, "Matus UHLAR - fantomas" wrote:
>> In article ,
>> Matus UHLAR - fantomas wrote:
>>> No, it does not. If a mail gets delivered to address, which is sending it
>>> further ("forwarding it"), the envelope sender has to be changed, because
>>> it's not the original sender who sends the another mail. Forwarding without
>>> changing envelope address is already broken, it's just people don't care
>>> without SPF.
>
> On 22.07.13 12:22, Barry Margolin wrote:
>> They're talking about auto-forwarding, not people resending a message
>> they received. For instance, mail to bar...@alum.mit.edu is
>> automatically forwarded by the alum.mit.edu server to my ISP email
>> address. Many people also have vanity domains with auto-forwarding
>> enabled like this.
>
Ok, but in this case you are trusting alum.mit.edu as a forwarder. And it
is specific to you as the recipient, not all of the people in the world
getting your mail. So add them to trusted-hosts and apply spf before the
last trusted... Problem solved. Or add enough whitelist points to
counteract SPF problems when a /^Received.{5,40}\balum.mit.edu/ header is
found in your mail. In either case, you have to either trust your forwarder
to evaluate SPF for you and trust the SPF evaluation headers they insert, or
consider that forwarder part of your mail infrastructure and instruct your
spf evaluator to ignore those headers.
But again, that's your choice for outsourcing part of your mail solution to
another entity.
> ...OK this is off-topic here. However this was already discussed and the
> conclusion was that the SPF record is NOT dead. We just need enough time to
> deal with these issues.
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
In article ,
Matus UHLAR - fantomas wrote:
No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.
On 22.07.13 12:22, Barry Margolin wrote:
They're talking about auto-forwarding, not people resending a message
they received. For instance, mail to bar...@alum.mit.edu is
automatically forwarded by the alum.mit.edu server to my ISP email
address. Many people also have vanity domains with auto-forwarding
enabled like this.
I'm afraid the same applies even in these cases.
How can you differ between vanity forwarder and spam/phish with fake from
address?
Rewrite the sender's address. You have more choices, SRS is one of them.
This would help in other ways too - at my former employer we've had to deal
with broken forwardings, therefore undeliverable mail and undeliverable
bounces. Rewriting sender and properly detecting undeliverable garbage
helps there too.
Who should the sender be changed to? AFAIK, it has never been standard
practice to rewrite the sender when simply forwarding to an alias, which
is what this is.
Because they did not care. Long time ago even open relays were not an issue
until people started abusing them.
...OK this is off-topic here. However this was already discussed and the
conclusion was that the SPF record is NOT dead. We just need enough time to
deal with these issues.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, 2013-07-22 at 08:50 -0500, Barry S. Finkel wrote: > > This was discussed here already, and imho this is anti-spf bullshit like > > all those "spf breaks forwarding" FUD. The SPF RR is already here and is > > preferred over TXT that is generik RR type, unlike SPF. > > > It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding". > SPF *DOES* break forwarding. I have a case I am researching right now > where forwarded mail is undeliverable due to SPF checking at the > new destination. > Nothing is perfect, every single gmail user coming via mailing lists also fails DKIM. There is no magic answer, but I wish more would enforce SPF, especially banks, but cant expect them to have any clue, their only expertise is ripping people off. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Jul 22, 2013, at 1:24 PM, Barry S. Finkel wrote:
> On 7/22/2013 11:17 AM, bind-users-requ...@lists.isc.org wrote:
This was discussed here already, and imho this is anti-spf bullshit like
>>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>preferred over TXT that is generik RR type, unlike SPF.
>> On 22.07.13 08:50, Barry S. Finkel wrote:
>>> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
>>> >SPF*DOES* break forwarding.
>
>> No, it does not. If a mail gets delivered to address, which is sending it
>> further ("forwarding it"), the envelope sender has to be changed, because
>> it's not the original sender who sends the another mail. Forwarding without
>> changing envelope address is already broken, it's just people don't care
>> without SPF.
>
>>> > I have a case I am researching right now
>>> >where forwarded mail is undeliverable due to SPF checking at the
>>> >new destination.
>> Rewrite the sender's address. You have more choices, SRS is one of them.
>>
>> -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>
> I have no control over what my Mail User Agent does. And a quick reading
> of section 3.6.6 of RFC 5322 does not tell me what is the correct action
> on a forwarded message:
>
> 1) Change the "From:" address, or
>
> 2) Keep the "From:" address.
>
> My MUA, Thunderbird, does 1). And I do not see any configuration
> option. I am not sure which action is "correct".
>
> I do not know what implications for forwarding SMTP (RFC 5321) has.
Do not be confused by the From: address shown by your mail client. That is not
the envelope sender.
Chris
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On 7/22/2013 11:17 AM, bind-users-requ...@lists.isc.org wrote:
This was discussed here already, and imho this is anti-spf bullshit like
>>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>preferred over TXT that is generik RR type, unlike SPF.
On 22.07.13 08:50, Barry S. Finkel wrote:
>It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
>SPF*DOES* break forwarding.
No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.
> I have a case I am researching right now
>where forwarded mail is undeliverable due to SPF checking at the
>new destination.
Rewrite the sender's address. You have more choices, SRS is one of them.
-- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
I have no control over what my Mail User Agent does. And a quick reading
of section 3.6.6 of RFC 5322 does not tell me what is the correct action
on a forwarded message:
1) Change the "From:" address, or
2) Keep the "From:" address.
My MUA, Thunderbird, does 1). And I do not see any configuration
option. I am not sure which action is "correct".
I do not know what implications for forwarding SMTP (RFC 5321) has.
--Barry Finkel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
In article ,
Matus UHLAR - fantomas wrote:
> >>This was discussed here already, and imho this is anti-spf bullshit like
> >>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
> >>preferred over TXT that is generik RR type, unlike SPF.
>
> On 22.07.13 08:50, Barry S. Finkel wrote:
> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
> >SPF *DOES* break forwarding.
>
> No, it does not. If a mail gets delivered to address, which is sending it
> further ("forwarding it"), the envelope sender has to be changed, because
> it's not the original sender who sends the another mail. Forwarding without
> changing envelope address is already broken, it's just people don't care
> without SPF.
>
> > I have a case I am researching right now
> >where forwarded mail is undeliverable due to SPF checking at the
> >new destination.
>
> Rewrite the sender's address. You have more choices, SRS is one of them.
They're talking about auto-forwarding, not people resending a message
they received. For instance, mail to bar...@alum.mit.edu is
automatically forwarded by the alum.mit.edu server to my ISP email
address. Many people also have vanity domains with auto-forwarding
enabled like this.
Who should the sender be changed to? AFAIK, it has never been standard
practice to rewrite the sender when simply forwarding to an alias, which
is what this is.
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
This was discussed here already, and imho this is anti-spf bullshit like
all those "spf breaks forwarding" FUD. The SPF RR is already here and is
preferred over TXT that is generik RR type, unlike SPF.
On 22.07.13 08:50, Barry S. Finkel wrote:
It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
SPF *DOES* break forwarding.
No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.
I have a case I am researching right now
where forwarded mail is undeliverable due to SPF checking at the
new destination.
Rewrite the sender's address. You have more choices, SRS is one of them.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
This was discussed here already, and imho this is anti-spf bullshit like all those "spf breaks forwarding" FUD. The SPF RR is already here and is preferred over TXT that is generik RR type, unlike SPF. It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding". SPF *DOES* break forwarding. I have a case I am researching right now where forwarded mail is undeliverable due to SPF checking at the new destination. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, 22 Jul 2013, Jason Hellenthal wrote: It's exactly as it says... Instead of ... TXT "SPF ..." You now do ... SPF "SPF ..." On 22.07.13 11:26, G.W. Haywood wrote: Caution! The SPF record type is near enough dead. See in particular RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4. This was discussed here already, and imho this is anti-spf bullshit like all those "spf breaks forwarding" FUD. The SPF RR is already here and is preferred over TXT that is generik RR type, unlike SPF. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
Hi there, On Mon, 22 Jul 2013, Jason Hellenthal wrote: It's exactly as it says... Instead of ... TXT "SPF ..." You now do ... SPF "SPF ..." Caution! The SPF record type is near enough dead. See in particular RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
Basically a SPF record type in place that's new but you could carry both for new and older clients. -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 22, 2013, at 0:48, SH Development wrote: > I just started noticing these in my log: > > 7/21/13 11:33:13 PMnamed[355]21-Jul-2013 23:33:13.646 general: > warning: zone domain.com/IN: 'domain.com' found SPF/TXT record but no SPF/SPF > record found, add matching type SPF record > > The zone does have an SPF record. I'm not sure I understand what else I'm > supposed to be doing. > > Jeff > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, 2013-07-22 at 02:51 -0400, Jason Hellenthal wrote: > It's exactly as it says... > > > Instead of > ... TXT "SPF ..." > > > You now do > > > ... SPF "SPF ..." > > Mark Andrews wrote: No. It has a legacy SPF TXT record. It SHOULD have record of type SPF as per RFC 4408. Named will complain if both types are not present. ^ signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
It's exactly as it says... Instead of ... TXT "SPF ..." You now do ... SPF "SPF ..." -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 22, 2013, at 0:48, SH Development wrote: > I just started noticing these in my log: > > 7/21/13 11:33:13 PMnamed[355]21-Jul-2013 23:33:13.646 general: > warning: zone domain.com/IN: 'domain.com' found SPF/TXT record but no SPF/SPF > record found, add matching type SPF record > > The zone does have an SPF record. I'm not sure I understand what else I'm > supposed to be doing. > > Jeff > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
In message , SH Development writes: > I just started noticing these in my log: > > 7/21/13 11:33:13 PM named[355] 21-Jul-2013 23:33:13.646 general: > warning: zone domain.com/IN: 'domain.com' found S > PF/TXT record but no SPF/SPF record found, add matching type SPF record > > The zone does have an SPF record. I'm not sure I understand what else I'm > supposed to be doing. No. It has a legacy SPF TXT record. It SHOULD have record of type SPF as per RFC 4408. Named will complain if both types are not present. 3.1.1. DNS Resource Record Types This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII]. It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. For example, instead of publishing just one record as in Section 3.1 above, it is better to publish: example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" Example RRs in this document are shown with the TXT record type; however, they could be published with the SPF type or with both types. > Jeff > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
New warning message...
I just started noticing these in my log: 7/21/13 11:33:13 PM named[355] 21-Jul-2013 23:33:13.646 general: warning: zone domain.com/IN: 'domain.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record The zone does have an SPF record. I'm not sure I understand what else I'm supposed to be doing. Jeff ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
