. With ADSP, of course, there's also a chance of spotting spoofed
messages.
And, if multiple From: headers become a popular spoofing mechanism, I guess
sites will stop accepting them.
I accept that DKIM doesn't solve every problem, but that doesn't mean that it
has no value.
--
Ian Eiloart
won't display an unsigned From: header in preference to a signed one.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
with respect to emails
signed by, for example, subdomains of .gov.uk, which might well be better
managed.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-11
The change in 3.4.5 has introduced a grammatical error: the domain name is
need not be…. The word is should have been removed.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL
than with
non-list mail, though.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for
Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
disappear. Also, done well, the utility of
the meta-data could be improved. Increased safe passage of DKIM signatures
might be regarded as a positive benefit with respect to motivating DKIM
deployment.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
, then
you'll find future messages from the same sender will likely end up being
delivered to your spam mailbox.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, we're straying off topic here, I guess.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, or even if they are, will decode to the same value.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 23 May 2011, at 17:10, Hector Santos wrote:
Ian Eiloart wrote:
On 23 May 2011, at 15:19, Hector Santos wrote:
But why skip? Usually the message won't be downgraded. And even if they
are, usually a broken signature will cause no harm.
Thats the problem - define usually and also define
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org
On 19 May 2011, at 18:19, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Ian Eiloart
Sent: Thursday, May 19, 2011 3:21 AM
To: John Levine
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim
developers have 8bitmime development as a priority now). And,
it's also an option for the recipient's MTA to add a new signature (whatever
that's worth).
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list
then SKIP signing.
But why skip? Usually the message won't be downgraded. And even if they are,
usually a broken signature will cause no harm.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according
On 23 May 2011, at 15:19, Hector Santos wrote:
Ian Eiloart wrote:
On 20 May 2011, at 05:24, Hector Santos wrote:
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add
On 23 May 2011, at 16:00, Hector Santos wrote:
Ian Eiloart wrote:
Sorry, Pareto Efficiency (an economics concept) isn't something that I was
familiar with. I was referring to an analysis Pareto charts (a quality
engineering tool). Same guy, different concept.
Actually, different guys
ways to declare that it may be bleeding
heavily but it's not dead yet.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 18 May 2011, at 18:42, Murray S. Kucherawy wrote:
-Original Message-
From: Ian Eiloart [mailto:i...@sussex.ac.uk]
Sent: Wednesday, May 18, 2011 2:39 AM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
According to what we have
of domains, then it's entirely feasible that top 1000 signing domains
are not spammers, but that spammers collectively are (or will one day be)
responsible for over 50% of signatures. I don't know whether that's the case
though.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87
% relaxed), such
percentages would be superb for tools like Spamassassin. I'd expect
at least 99% from a cryptographic tool.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http
in Spanish to say that something bad has happened without
assigning direct responsibility to some person involved.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
evidence that email needs fixing. I use, and like, the additional information
that SPF publishers give me.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
that header. If the
recipient trusts the list, then it should examine that header to check that the
original message was compliant. If not, then it should discard the message.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
can specify in dkim to sign only a certain length of the body and not the
whole body.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
with the overall quality.
On 3/15/2011 9:45 AM, Ian Eiloart wrote:
Hi,
Subscribers to this list, especially those located in the UK, may be
interested to give their views in this UK Government Open Standards
Survey.
It gets rather tedious after the first couple of pages, but page 22 asks
about email
for
suggestions of standards that they've not listed.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
with SRS, or similar, *forwarding* can
result in SPF failure. Since forwarders generally don't change the message
content, DKIM signatures should remain intact.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
--On 24 November 2010 09:53:41 -0500 Wietse Venema wie...@porcupine.org
wrote:
Ian Eiloart:
Unless the intermediary co-operates by re-signing, mailing lists can
break DKIM signatures. Since mailing lists generally use their own
rfc5321 return paths, SPF failures should not result
results, and haven't had any complaints. For DKIM it's harder, but for
certain author domains (including those that publish ADSP discardable, it
might be worth considering downgrading messages - especially when combined
with SPF fail/neutral/softfail).
--
Ian Eiloart
IT Services, University
of messages at SMTP time permits the sender to
be aware of problems with false positives.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates
and 5.4 for further
discussion.
h= ... from:from:to:to:subject:subject:date:date ...
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates
nothing about the frequency,
but readers may infer that the problem will be infrequent.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list
down the
validity of the author address. If it wasn't a required binding, then
there begins some truth to the statement.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
error in public key record
31 verification failed - body hash mismatch (body probably modified in
transit)
285 verification failed - signature did not verify (headers probably
modified in transit)
1776 verification succeeded
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
--On 21 October 2010 12:20:33 -0700 Dave CROCKER d...@dcrocker.net wrote:
On 10/19/2010 3:11 AM, Ian Eiloart wrote:
It's that, in order to get the marking, she can't spoof a trusted
person's sender address.
DKIM makes no statement about the validity of a sender address.
d/
I guess I
implementers about the security risks that we've identified.
-Doug
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support
more suitable for domains like the large email service
providers, which have a mix of good and bad users.
http://www.dkim-reputation.org/start/ offers address based reputation
service. I've not used the service, so can't vouch for it.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148
to
pressure the real owner into fixing their machine (say, by emailing them or
their domain support, or by blacklisting their email)
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
that they need to be sure they're highlighting
the correct header.
Any chance you can tell me which MUAs have this misfeature, so I can tell
people to return them and ask for a refund?
R's,
John
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http
--On 18 October 2010 20:07:39 -0400 John R. Levine jo...@iecc.com wrote:
So, uh, can we agree that Jim's SHOULD language to tell people to do this
is a good idea?
+1 Yes, please.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http
, that the markup requires that the
signing domain have some connection with the Author domain. I don't know if
there's a standard for that, but some heuristics might be usefully
implemented in the MUA. For example, it might only display the validity
information if there's an exact match.
--
Ian Eiloart
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE
, Siren Mail had just ceased
development. We've only just (in the last few months) got Siren Mail out of
the hands of the last user hanging on. And the motivation there was that
Siren Mail didn't do authenticated SMTP!
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new
?
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
DKIM signed Double From Accepted, Resigned by mipassoc.org
Yes, we saw that.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list
RFC5322 recommends
only one 5322.From should be used. This will mitigate any
replay that prepends a new 5322.From header to a DKIM signature
valid message. Some MUAs have should to display only the first
5322.From header found.
--
Ian Eiloart
IT Services, University of Sussex
)
would be nice, though harder to do. Having said all that, I have my own log
files that I could analyze, so I'll shut up.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
saying only
that.
Good plan. That would be rather pointless.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http
, the correct solution is worth discovering. Our
configurations deal with a lot of corner cases already.
R's,
John
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE
.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. Therefore, I expect to be able
to reduce the load on our hosts when good DKIM signatures are present.
For domains like gmail.com, I'm considering working on rate-limiting by
author address. Of course, the rate limit would be different for a message
with a dkim pass.
--
Ian Eiloart
IT Services
, then later bounce, messages with good DKIM signatures?
That should be acceptable where the signing domain and return-path domain
match, should it not? Otherwise, send the notification to the author.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
it locally.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--On 28 September 2010 13:10:51 +0100 Graham Murray gra...@gmurray.org.uk
wrote:
Ian Eiloart i...@sussex.ac.uk writes:
Oh, but I already know that my MLM is going to break any message with a
signed body. UK law practically mandates the addition of unsubscription
information in a message
, you have to be using DKIM, you have to get an
invitation from someone already on the whitelist, and you must not already
be on a Spamhaus blocklist.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
an opportunity to fix the problem.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
to MLMs that they
may or may not be able to identify?
I think they'd only do this for email that's to a mailing list, not for the
whole stream. Hard to implement, and perhaps infeasible for large domains,
but it's possible.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new
--On 16 September 2010 09:49:40 -0700 Murray S. Kucherawy
m...@cloudmark.com wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Ian Eiloart
Sent: Thursday, September 16, 2010 3:20 AM
To: Hector Santos; ietf-dkim
from the MLM is required, too. Thus,
the original DKIM signature is only valid for messages going through the
list - off list replay isn't possible. On-list replay can be limited by
ALSO including a full DKIM signature, for the list to check before
redistributing.
--
Ian Eiloart
IT Services
).
We're not talking about email with broken signatures, we're talking about
email with good signatures that are about to become broken.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
quo of non-resolution of
conflicting issues regarding the author domain, 3rd party signers
and/or list servers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
email
domain. :) So, Paypal have collectively learned that separating mailstreams
is important (or, at least helpful) when using ADSP. It makes all the
discussion of ADSP/MLM incompatibility moot, if you can route around it
like that.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148
to pursue, +1 it because I am trying to
see if its worth the effort to reintroduce it.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list
will be able to make a
call forward to Mailman to determine (a) whether the list exists, and (b)
whether the sender is permitted to post messages to the list. Exim will
know whether the message is signed, and can do simple DNS lookups to find
ADSP records.
--
Ian Eiloart
IT Services, University
signature.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
by the MTA rather than the MLM). In fact
the MTA should reject (at SMTP time)
rather than discard such messages, I think.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
while the TCP session is
open. We have four very old OSX servers doing this, but one could cope with
the load reasonably well.
R's,
John
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
), because any account might be compromised by phishing.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http
DKIM down
increases the risk that we'll never get widespread domain based reputation
services.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL
or a viewpoint that
might suggest where there might be a payoff with DKIM.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according
with a higher trust level, and -for example- file them accordingly.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http
and the
signing domain. For example, if the return path address matches the From
header address, and the From header is DKIM signed.
I'm sure you're not the only one doing it, but as I recall, the standards
to no institutionalize anything that forces it.
d/
--
Ian Eiloart
IT Services, University
the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation
during the SMTP session.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http
--On 4 August 2010 15:22:32 +0100 Graham Murray gra...@gmurray.org.uk
wrote:
Ian Eiloart i...@sussex.ac.uk writes:
So, in an ideal world, mail clients would expose the List-* headers
(especially the unsubscribe* header) in ways that are useful to the
user, and obviate the need for MLMs
to which you have subscribed?
B. I use the List-ID: to sort list traffic into separate mail folders, so
that I can prioritise other stuff. Where there's no List-ID, I try to use
some proxy for it, like a Subject line tag.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
problem is one of deliverability, not security.
However, if there's a need to trust the original sender, and you don't
quite trust the list to get that right for you, then the implication is
that the recipient (the person with the need) should not select a digest
mode.
--
Ian Eiloart
IT Services
attacks. But there
is, at least, a way of making DKIM, ADSP and lists work together if the
sender wants to do that.
For MLM managers, they should simply reject at SMTP time if they are about
to break ALL the DKIM signatures of a message from a discardable domain.
--
Ian Eiloart
IT Services
, MLMs are required in UK law to add unsubscribe information in
a way that users can easily find it. The List-unsubscribe header isn't
adequate, only because very few clients display it.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http
--On 29 July 2010 20:53:40 +0200 J.D. Falk
jdfalk-li...@cybernothing.org wrote:
On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
--On 26 July 2010 18:24:34 +0200 J.D. Falk
jdfalk-li...@cybernothing.org wrote:
I think it's because, when you implement most protocols, if your end is
broken
, but the
other end may silently discard your message. There's no feedback.
About 90% of the email sent to my personal email address ends up in a Gmail
junk mail folder, that I never check. There's no feedback there, either.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
engine, or an EHLO string reputation engine. I guess those
reputation engines might all be the same domain keyed machine, but they
could also encompass user-driven whitelists for authenticated email
addresses (return paths, From addresses with domain matches, etc).
--
Ian Eiloart
IT Services
in
reputation for envelope sender addresses when SPF passes, and you have *per
sender* reputation database for (for us) the majority of inbound mail
(that's passed IP reputation tests).
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http
--On 16 July 2010 08:40:55 -0700 Douglas Otis do...@mail-abuse.org wrote:
On 7/16/10 7:11 AM, Ian Eiloart wrote:
Yes, but why ask on a DKIM mailing list? I speculate that Dave wants
to modify it to build a reputation engine based on Author address, for
DKIM signed messages. With that, you
problem, the best thing to do is to 5xx messages
which don't appear to be from mailing lists, but to discard (silently or
otherwise) those that do.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help
arguing about
what you wrote.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
of the sort. The question isn't whether one SHOULD notify the
recipient, but whether one MAY do so.
R's,
John
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273
are the first and
second parties respectively. This may or may not be damage, but it's not
collateral.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL
-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
discovers a likely error should feel free to advise the publisher of that
error.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates
operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http
sauce lies for vendors.
Addressing an issue and solving it aren't the same things. Heck, neither is
even a prerequisite for the other, given that some problems are
self-resolving or solved accidentally.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support
. In future, I'll bet they'll display the DKIM/ADSP status, too.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list operates according to
http
of those IP addresses don't belong to the top 5
or so mailbox providers.
If paypal want to broaden the uptake of ADSP, then contributing DKIM/ADSP
code or config recipes to open source MTA projects would be useful!
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
NOTE WELL: This list
systems can also benefit.
3. Discussability: given that it's a standard, potential users can read
about best practice, and senders and receivers have a common language to
talk about how things should work.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support
1 - 100 of 158 matches
Mail list logo
