<?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/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:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17705"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17704"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17703"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17702"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17701"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.mimedefang/17700"/>
      </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/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>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17704">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17704</link>
    <description>&lt;pre&gt;
1)  Not always.  For example, with a dictionary attack, for most of the attempts, there will be no valid user to pass on such information, and it's pretty obvious that when such an attack does hit a valid mailbox, that recipient should NOT get malicious message at all.

2)  Because I'm not a target of spammers like Google is.

Passing on a message to the user means accepting responsibility for it, which in turn implies to the spammer that the mailbox was valid (and it usually is or is a spamtrap).  Such messages cannot be rejected during the SMTP transaction (because one is accepting them to let the user determine its maliciousness).  Under your theory, an MTA should pass on messages containing e-mail virii too, so the user can determine it (or get infected for the not-so-savvy users).  This latter point I clearly disagree with.
&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-07T00:12:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17703">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17703</link>
    <description>&lt;pre&gt;
So, you can pass your knowledge on to the recipient, leaving the
disposition up to them.   For example, I think google is probably as
good as anyone at that sort of bulk-discovery, and yet I regularly
find things they've tossed in the spam folder that are not spam.   Why
do you think you have less false positives then they do?

--
   Les Mikesell
     lesmikesell&amp;lt; at &amp;gt;gmail.com
&lt;/pre&gt;</description>
    <dc:creator>Les Mikesell</dc:creator>
    <dc:date>2013-05-06T20:00:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17702">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17702</link>
    <description>&lt;pre&gt;
These do solve a problem - a different but related problem which coexists with the one you target.  Due to overlap, by itself it does eliminate much of your problem messages too.  That doesn't mean it's not useful.

A standard way:  See RFC 5451 - "Authentication-Results:" header.
Title:  "Message Header Field for Indicating Message Authentication Status."

Spammy content is not the only type of malicious message out there.  Forged messages are clearly malicious yet need not be spammy at all.  Content alone need not indicate the maliciousness of a message.


No, because some types of scanning and responses can only be administered site-wide by the administrator (i.e. the software configuration) which cannot be changed on a per-user basis.  Take for an example a message cross- or multi-posted to many users (e.g. perhaps from a mailbox dictionary attack):  Individual users will be unaware of its bulk nature and perhaps ONLY the bulk nature will classify it as spam.  Conversely, some types of bulk mail will no&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-06T19:37:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17701">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17701</link>
    <description>&lt;pre&gt;
No, but I claim that wasting time and effort on things that don't
solve the problem are a waste of time and effort.  So you claim the
problem is solved?   Does an end-user recipient have a standard way of
seeing who thinks any particular message was forged and why?


Do you agree that end user recipients should have the final decision
about message disposition?   And that they probably do want forwarded
messages whether or not the forwarder handles them in a way you deem
appropriate?

--
   Les Mikesell
      lesmikesell&amp;lt; at &amp;gt;gmail.com
&lt;/pre&gt;</description>
    <dc:creator>Les Mikesell</dc:creator>
    <dc:date>2013-05-06T18:53:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17700">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17700</link>
    <description>&lt;pre&gt;
So you claim that message forgery isn't a problem?  Get a clue.
I agree that spaminess and source authentication are separate issues, but most recipients don't want forged messages either, spam or not.
&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-06T18:29:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.mimedefang/17699">
    <title>Re: How to change envelope sender?</title>
    <link>http://permalink.gmane.org/gmane.mail.mimedefang/17699</link>
    <description>&lt;pre&gt;
I do a sender "rewrite" but don't use the ugly socketmap solution you cite.  This can be done PURELY with a rewriting ruleset and a small external program to generate the rewritten sender plus a log file to track them.  This isn't a problem at all.


Guess what?  You're misconstruing DKIM if that's what you think.  The mailing list software should be validating the message then generating its OWN DKIM headers (replacing as necessary) when altering the message to conform to those sent out by the list.  You skipped that step.  Messages to the list are considered delivered when received by the list server, not the list members.


Filter spam with PGP?  How?  It's not a spam filter.  It's an authenticator.
 

That's because you're confusing spam filtering with source authentication.  These are not the same.  Granted, much spam is also forged but these characteristics are orthogonal - one can occur without the other.
&lt;/pre&gt;</description>
    <dc:creator>kd6lvw&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2013-05-06T18:14:36</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>
