In <87u0zessd2(_dot_)fsf(_at_)athene(_dot_)jamux(_dot_)com> "John A. Martin"
<jam(_at_)athene(_dot_)jamux(_dot_)com> writes:
The SPF record was presumably something like the following:
,----[ dig +short chepelov.org. txt ]
"v=spf1 ptr ip6:2001:7a8:29d4:/48 -all exp=explain._spf.%{d}"
`----
Yes, and the explanation text was:
: (wayne(_at_)footbone) $ sdig explain._spf.chepelov.org txt
: "This site uses SPF to help reduce email forgery\; see http://spf.pobox.com";
Since the SMTP response was, I believe, merely (ending at the first
semicolon in the NOQUEUE log entry):
554 <user(_at_)example(_dot_)com>: Recipient address rejected: This
site
uses SPF to help reduce email forgery
It seems with the ambiguous "This site" that chepelov.org feels a need
to put words in the mouth of example.com. What might we be caused to
be saying next?
Good point. Maybe SPF implementations should either always prefix the
explanation string with "%{d} says: ", or given an option of what to
prefix the explanation string. This would have made the SMTP
rejection message to be:
554 <user(_at_)example(_dot_)com>: Recipient address rejected:
chepelov.org says: This site uses SPF to help reduce email
forgery; see http://spf.pobox.com
More generally, do we really want to make a SMTP reply containing text
From a source not under our control? This could contain malicious or
slanderous material and thereby become a security concern.
Several SPF implementations have an option to "sanitize" the strings
to make sure they don't contain invalid characters. Libspf-alt also
places a limit of around 250 characters on the length.
However, I suspect you are more concerned with explanation strings of
"this site is run by wankers!" and such.
Now, there are going to be two types of folks that will see this
message. There will be forgers/spammers/phishers, and I really don't
much care what they think about anything. I suspect few other people
much care either.
The other is legitimate users of, in this case, chepelov.org who have
violated chepelov.org's rules about how they should be sending email.
I'm having a hard time thinking of why chepelov.org would want to
create problems for their users. Even if they did want to create
problems, there seems to be a lot easier ways for them to do so.
-wayne