<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang">
    <title>gmane.mail.mimedefang</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17725"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17724"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17723"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17722"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17721"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17720"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17719"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17718"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17717"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17716"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17715"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17714"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17713"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17712"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17711"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17710"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17709"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17708"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17707"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17706"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17725">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17725</link>
    <description>&lt;pre&gt;On Wed, 22 May 2013 15:35:28 +0200
Renaud Pascal &amp;lt;renaud.pascal&amp;lt; at &amp;gt;atos.net&amp;gt; wrote:


SPF was created by Meng Wong of pobox.com, not by Microsoft.  Microsoft
had it's own invention called "Caller ID for Email" that was later
merged into "Sender ID" which is a (IMO) defective bastardization
of SPF and Caller ID for Email.

DKIM emerged from Yahoo!'s DomainKeys specification and addresses the
problem from a completely different viewpoint; instead of specifying
machines allowed to relay for a domain, DKIM provides
cryptographically-secure evidence that a message passed through a
"responsible" relay.  Unlike SPF, DKIM can validate the From:
header field.

DMARC adds feedback to DKIM/SPF so that domain owners can see if their
domain is being abused (for example, in phishing attacks.)

Every single one of these protocols has defects that make them completely
useless for combatting spam and mostly useless for combatting phishing.
Welcome to Internet email.

Regards,

David.
&lt;/pre&gt;</description>
    <dc:creator>David F. Skoll</dc:creator>
    <dc:date>2013-05-22T14:02:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17724">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17724</link>
    <description>&lt;pre&gt;From: Renaud Pascal &amp;lt;renaud.pascal&amp;lt; at &amp;gt;atos.net&amp;gt;


No, that was CallerID, later SenderID.  SPF was from Meng Wong at 
POBOX.com, based on the work of others.  The MARID working group tried to 
merge SenderID with SPF, but that effort failed.

SenderID was a bloated mess of XML jammed into DNS TXT records.  Sometimes 
EDNS0  (if it was even available) wouldn't keep it from failing over to 
TCP for the DNS query.



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
&lt;/pre&gt;</description>
    <dc:creator>WBrown&lt; at &gt;e1b.org</dc:creator>
    <dc:date>2013-05-22T13:57:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17723">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17723</link>
    <description>&lt;pre&gt;On Wed, 22 May 2013 15:15:13 +0200
Jan-Pieter Cornet &amp;lt;johnpc&amp;lt; at &amp;gt;xs4all.nl&amp;gt; wrote:


at least it'd give us a solid presence in the streets, nice wheels !


well, after all wasn't SPF an idea from Microsoft, a gang of squares thinking they're geeks...

&lt;/pre&gt;</description>
    <dc:creator>Renaud Pascal</dc:creator>
    <dc:date>2013-05-22T13:35:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17722">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17722</link>
    <description>&lt;pre&gt;
Try talking to an organization that has a serious phishing problem.


I'm sure glad someone did, or we would all still be using this:
http://www.dreamstime.com/stock-photography-stone-wheel-image5121882

Or in the case of SPF, more likely this:
http://thumbs.dreamstime.com/thumblarge_593/1300952810s9s08A.jpg
:-)

&lt;/pre&gt;</description>
    <dc:creator>Jan-Pieter Cornet</dc:creator>
    <dc:date>2013-05-22T13:15:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17721">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17721</link>
    <description>&lt;pre&gt;
Seriously, don't go there. Hardly anyone implements ADSP. Certainly none of the "big mail receivers", where most big ISPs do support DMARC...

Note that you should be careful before using DMARC on your own domain, though. Notably, it breaks mail to mailinglists... it's most effective on domains that are often the victim of phishing.

&lt;/pre&gt;</description>
    <dc:creator>Jan-Pieter Cornet</dc:creator>
    <dc:date>2013-05-22T12:58:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17720">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17720</link>
    <description>&lt;pre&gt;
On May 13, 2013, at 2:15 PM, David F. Skoll &amp;lt;dfs&amp;lt; at &amp;gt;roaringpenguin.com&amp;gt; wrote:



By the way, is the record:

$ORIGINmydomain.tld

_domainkeyINTXT"o=-; r=postmaster&amp;lt; at &amp;gt;mydomain.tld"

or is the ADSP record sufficient?

_adsp._domainkeyINTXT"dkim=discardable;"

Does everyone implement ADSP?  Even though it's apparently been an RFC for 4 years…

-Philip

&lt;/pre&gt;</description>
    <dc:creator>Philip Prindeville</dc:creator>
    <dc:date>2013-05-22T01:08:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17719">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17719</link>
    <description>&lt;pre&gt;On Mon, 13 May 2013 14:01:57 -0600
Philip Prindeville &amp;lt;philipp_subx&amp;lt; at &amp;gt;redfish-solutions.com&amp;gt; wrote:


Entire message.


I'm not sure how that would handle SMTP line endings.  It's been a while
since I wrote the code, so I can't remember if I tried what you just
wrote and it didn't work, or if I didn't try it.



It's not the same thing.  My code would convert:

     foo\n      to     foo

whereas yours would leave it as foo\n

Regards,

David.
&lt;/pre&gt;</description>
    <dc:creator>David F. Skoll</dc:creator>
    <dc:date>2013-05-13T20:15:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17718">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17718</link>
    <description>&lt;pre&gt;
On May 9, 2013, at 3:30 PM, David F. Skoll &amp;lt;dfs&amp;lt; at &amp;gt;roaringpenguin.com&amp;gt; wrote:


Thanks for sharing that.

Couple of questions: Is the SHA computed over the header or the entirety of the message?  If it's just over the header, then all you'd need is:

$dkim-&amp;gt;PRINT($entity-&amp;gt;head()-&amp;gt;as_string());

right? But then if it were just over the header, you could replay the header so there wouldn't be much point to that…

If it's over the entirety of the message, then you could do:

$dkim-&amp;gt;PRINT($entity-&amp;gt;as_string());

for the entire serialized message, yes?

Also, looking at:

                       chomp;
                       s/\015$//;

makes me wonder about this (and I've seen it elsewhere).  Why not just do:

local $/ = "\r\n";
chomp;

instead?

Thanks,

-Philip

&lt;/pre&gt;</description>
    <dc:creator>Philip Prindeville</dc:creator>
    <dc:date>2013-05-13T20:01:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17717">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17717</link>
    <description>&lt;pre&gt;On Thu, 09 May 2013 21:43:43 -0400
"Kevin A. McGrail" &amp;lt;KMcGrail&amp;lt; at &amp;gt;PCCC.com&amp;gt; wrote:


No reason; just never bothered.  And I think ADSP has been downgraded
to "experimental" because DMARC is taking over.


I didn't do anything special.  Just created a 2048-bit keypair and
published the record.

Regards,

David.
&lt;/pre&gt;</description>
    <dc:creator>David F. Skoll</dc:creator>
    <dc:date>2013-05-10T11:30:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17716">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17716</link>
    <description>&lt;pre&gt;Thanks for that info.  Out of interest, it doesn't look like you use 
ADSP. Any reason why or why not?

I'd also love to know more about how you would recommend creating the 
key and the DNS records because I've often worried about that and Google 
started bouncing my old 512bit key so I recently disabled that.

Regards,
KAM
&lt;/pre&gt;</description>
    <dc:creator>Kevin A. McGrail</dc:creator>
    <dc:date>2013-05-10T01:43:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17715">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17715</link>
    <description>&lt;pre&gt;On Thu, 9 May 2013 12:14:40 -0600
Philip Prindeville &amp;lt;philipp_subx&amp;lt; at &amp;gt;redfish-solutions.com&amp;gt; wrote:


It is very easy to add.  Use the Mail::DKIM::Signer and Mail::DKIM::TextWrap
modules from CPAN.  This is in our filter and we call it to sign a message
from filter_end:

sub dkim_sign
{
        my $dkim = Mail::DKIM::Signer-&amp;gt;new(
                Algorithm =&amp;gt; "rsa-sha1",
                Method =&amp;gt; "relaxed",
                Domain =&amp;gt; "roaringpenguin.com",
                Selector =&amp;gt; "main",
                KeyFile =&amp;gt; "/etc/ssl/private/roaringpenguin.com.dkim.2048.key");
        if (open(TOSIGN, "&amp;lt;INPUTMSG")) {
                while(&amp;lt;TOSIGN&amp;gt;) {
                        # remove local line terminators
                        chomp;
                        s/\015$//;

                        # use SMTP line terminators
                        $dkim-&amp;gt;PRINT("$_\015\012");
                }
                close(TOSIGN);
                $dkim-&amp;gt;CLOSE();
                my $signature = $dkim-&amp;gt;signature()-&amp;gt;as_string();
   &lt;/pre&gt;</description>
    <dc:creator>David F. Skoll</dc:creator>
    <dc:date>2013-05-09T21:30:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17714">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17714</link>
    <description>&lt;pre&gt;
On May 8, 2013, at 3:06 PM, kd6lvw&amp;lt; at &amp;gt;yahoo.com wrote:


The short answer is our CEO read an article about it and he's anxious to have it. So I need to do my due diligence and investigate what's involved.



And DKIM support for verification is in SpamAssassin, but I'm not seeing any support for signing in MimeDefang.

-Philip

&lt;/pre&gt;</description>
    <dc:creator>Philip Prindeville</dc:creator>
    <dc:date>2013-05-09T18:14:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17713">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17713</link>
    <description>&lt;pre&gt;
Exactly what is the point behind DMARC?

DKIM already has feedback elements in its declarations.

SPF doesn't explicitly have such, but generally the difference between "FAIL" and "SOFTFAIL" implies such (the latter as an indication of a DSN request as opposed to SMTP rejection, as well as macro expansion for the "exists" operator in combination with DNSBL DNS-request logging as suggested in RFC 4408, Section 9).

"Therefore, why reinvent the wheel?"

I would be hesitant of any scheme that claims that its predecessors were "developed over a decade ago" when it is unaware of their histories. SPF didn't come about until 2004 (9 years ago; not published formally as an RFC until 7 years ago), and DKIM was created in 2004 (9 years ago; RFC published in 2007 - 6 years ago).
[References from the http://www.dmarc.org/overview.html web page.]

Additionally, I would also be hesitant to adopt any scheme backed by an organization (Google / Gmail) who can't even provide the simplist of RFC/Standards compliance for their&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-08T21:06:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17712">
    <title>Re: What about DKIM</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17712</link>
    <description>&lt;pre&gt;
On Apr 1, 2013, at 4:22 PM, Jan-Pieter Cornet &amp;lt;johnpc&amp;lt; at &amp;gt;xs4all.nl&amp;gt; wrote:


Any chance of posting your changes?

I'd like to try implementing it outbound…

Thanks,

-Philip

&lt;/pre&gt;</description>
    <dc:creator>Philip Prindeville</dc:creator>
    <dc:date>2013-05-08T19:12:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17711">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17711</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 08.05.2013 00:47, schrieb Richard Laager:

It has been some time since I last had a problem with Spamcop
and I don't remember what the reason for the listing was in
that specific case.

Generally the most frequent causes for blacklistings of our
mailservers are:
- - abuse by the previous owner of our IPv4 address range
  (Our current /24 range was assigned to us only three years
  ago, obviously too short for some RBL operators to notice.)
- - misclassification of our IPv4 address range as dial-up
- - false claims about missing or incorrect DNS or whois entries
- - undisclosed reasons ("We have evidence but we won't show it.")
Any of these disqualifies a blacklist, of course, at least if
there is no quick and easy way to get it corrected.

Occasionally we also get blacklisted because a user account was
bruteforced and abused for spamming. That's easily corrected,
and respectable blacklists quickly delist afterwards, so it's
more of a nuisance than a problem.
&lt;/pre&gt;</description>
    <dc:creator>Tilman Schmidt</dc:creator>
    <dc:date>2013-05-08T10:56:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17710">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17710</link>
    <description>&lt;pre&gt;How are you getting on the Spamcop block list?

Are you doing any outbound filtering?

&lt;/pre&gt;</description>
    <dc:creator>Richard Laager</dc:creator>
    <dc:date>2013-05-07T22:47:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17709">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17709</link>
    <description>&lt;pre&gt;
Rejecting anything for any reason is appropriate as long as the sender
gets a reasonable non-delivery notification.   But, you aren't
providing a particularly useful service if you reject reasonable
content routinely.   As I mentioned, google gets it wrong regularly,
and you didn't answer my question about why you think you can do it
better.   And I only know that google gets it wrong because they toss
it in a spam folder that I can check myself.  Most of what they
misclassify would have been bulk-mailed stuff, but it is stuff that
I've requested or mail list messages where I am subscribed.

--
   Les Mikesell
     lesmikesell&amp;lt; at &amp;gt;gmail.com
&lt;/pre&gt;</description>
    <dc:creator>Les Mikesell</dc:creator>
    <dc:date>2013-05-07T21:58:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17708">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17708</link>
    <description>&lt;pre&gt;
Your theory doesn't permit you to have it both ways.  Since you seem to agree that rejecting virus content at the systemwide level is appropriate, I find your notion of letting the end user decide everything to be nonsense.
&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-07T21:36:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17707">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17707</link>
    <description>&lt;pre&gt;Am 06.05.2013 09:13, schrieb Benoit Panizzon:

There are all kinds of misguided blacklists. So far, the following
procedure has served me well for these cases:

1. Try to contact the blacklist's operators and get the listing removed.

If that fails:

2. Try to contact the administrator of the mailserver using the
blacklist and ask him or her to stop using that blacklist on grounds
that it lists servers (such as mine) without justification and refuses
to remove such listings.

If that fails:

3. Explain to the sender and recipient of the blocked mail exactly why
it was blocked, who is responsible for it, and who refused to do
something about it.

Step 3 usually results in a complaint by someone paying for a service to
the one providing that service, and thereby in a belated success of
either step 1 or step 2.

Specifically, I have convinced more than one mail server administrator
to stop using Spamcop because it blocked legitimate mail to paying
customers of theirs. As Spamcop itself insists: it's never the
r&lt;/pre&gt;</description>
    <dc:creator>Tilman Schmidt</dc:creator>
    <dc:date>2013-05-07T20:26:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17706">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17706</link>
    <description>&lt;pre&gt;
I'm not sure "pretty obvious" is the same as never having false positives, but..

determine its maliciousness).

Delivering a message or rejecting with as appropriate a message for
the sender as possible is a mailer's "responsibility".  Passing
various levels of judgement on the content is an optional feature.


This sort-of depends on the level of confidence you have in your
scanning tools.  I don't think anyone wants to receive virii, although
an end user should have equal quality antivirus protection anyway. In
any case if you reject with an appropriate reason you have fulfilled a
mailer's obligations.

--
   Les Mikesell
     lesmikesell&amp;lt; at &amp;gt;gmail.com
&lt;/pre&gt;</description>
    <dc:creator>Les Mikesell</dc:creator>
    <dc:date>2013-05-07T20:24:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17705">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17705</link>
    <description>&lt;pre&gt;Am 06.05.2013 20:29, schrieb kd6lvw&amp;lt; at &amp;gt;yahoo.com:

Most recipients do not expect or even want the mail system to try doing
source authenticaton, much less to reject mail messages if it fails.

Ym2c,
T.

&lt;/pre&gt;</description>
    <dc:creator>Tilman Schmidt</dc:creator>
    <dc:date>2013-05-07T19:58:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.mail.mimedefang">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.mail.mimedefang</link>
  </textinput>
</rdf:RDF>
