Douglas Otis wrote:
In theory IANA could publish one _spf.arpa v=spf1 mx a -all
record, and everybody could use it with v=spf1 redirect=_spf.arpa.
That one SPF record can (kind of) reference an unlimited number of
MX records doesn't depend on SPF's local-part macro.
This adds
On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Do you expect everyone to use inbound servers to send?
No. Of course I'd expect that mail to postmaster to the IP of an
MTA talking to an MX I care about works. BTW, it would be nice if
only the MXs of the
Douglas Otis wrote:
By using the local-part in a spam campaign, one cached SPF record
is able to reference an unlimited sequence of MX records.
In theory IANA could publish one _spf.arpa v=spf1 mx a -all
record, and everybody could use it with v=spf1 redirect=_spf.arpa.
That one SPF
On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote:
Douglas Otis wrote:
By using the local-part in a spam campaign, one cached SPF record
is able to reference an unlimited sequence of MX records.
In theory IANA could publish one _spf.arpa v=spf1 mx a -all
record, and everybody
Douglas Otis wrote:
Macro expansion and text strings can be combined with any SPF record
mechanism and CIDR mask. Any email-address differing in just the
local-part must then be iteratively processed across the SPF record
set (up to 10 follow-on SPF records or mechanisms).
Yes, an attacker
On Oct 11, 2007, at 2:23 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Macro expansion and text strings can be combined with any SPF
record mechanism and CIDR mask. Any email-address differing in
just the local-part must then be iteratively processed across the
SPF record set (up to
Douglas Otis wrote:
Due to the macro nature of SPF, full processing is required for
each name evaluated.
If what you call full processing is the procedure to fetch the
policy record of the domain in question, and match the connecting
IP against this policy for a PASS / FAIL / DUNNO verdict,
On Oct 10, 2007, at 12:12 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Due to the macro nature of SPF, full processing is required for
each name evaluated.
If what you call full processing is the procedure to fetch the
policy record of the domain in question, and match the connecting
Douglas Otis wrote:
There is a real risk SPF might be used as basis for acceptance
You can combine white lists with SPF PASS as with DKIM PASS,
the risk is very similar.
Much of the danger of auto responses has to do with DDoS
concerns.
It depends on the definition of DDoS. From my POV
On Oct 9, 2007, at 3:59 AM, Frank Ellermann wrote:
Douglas Otis wrote:
There is a real risk SPF might be used as basis for acceptance
You can combine white lists with SPF PASS as with DKIM PASS, the
risk is very similar.
Due to the macro nature of SPF, full processing is required for
Returned message content in DSNs is often essential information for
debugging of mail system problems. Blindly insisting that DSNs should
not return subject message content is shortsighted. We have already
crippled the mail system too much as the result of naive and
shortsighted spam
On Tue, 9 Oct 2007, Douglas Otis wrote:
On Oct 9, 2007, at 1:52 PM, Keith Moore wrote:
Returned message content in DSNs is often essential information for
debugging of mail system problems. Blindly insisting that DSNs
should not return subject message content is shortsighted. We
Douglas Otis wrote:
On Oct 9, 2007, at 1:52 PM, Keith Moore wrote:
Returned message content in DSNs is often essential information for
debugging of mail system problems. Blindly insisting that DSNs
should not return subject message content is shortsighted. We have
already crippled the
On Oct 8, 2007, at 4:37 AM, Frank Ellermann wrote:
SM wrote:
TMDA may cause backscatter.
After an SPF PASS, the backscatter by definition can't hit an
innocent bystander. By the same definition any backscatter after
an SPF FAIL hits an innocent bystander, and therefore is net abuse.
14 matches
Mail list logo
