Said the blind person...
Sent from ProtonMail Mobile
On Tue, Feb 13, 2018 at 21:03, @lbutlr wrote:
> On 13 Feb 2018, at 06:57, Rupert Gallagher wrote: > Not sure why you guys are
> still discussing RFCs, though, Because one person keeps insisting that RFC822
> is the relevant active standard
On 13 Feb 2018, at 06:57, Rupert Gallagher wrote:
> Not sure why you guys are still discussing RFCs, though,
Because one person keeps insisting that RFC822 is the relevant active standard
despite being shown multiple times that it’s been obsoleted. Twice.
--
If you [Carrot] were dice, you'd al
Humans tend to confuse Science and Engineering, including professional
journalists: their mistake does not change the facts, but certainly confuses
the weaker minds.
Sent from ProtonMail Mobile
On Mon, Feb 12, 2018 at 08:49, Groach
wrote:
> On 12/02/2018 06:54, Rupert Gallagher wrote:
>
>> A
On 12/02/2018 06:54, Rupert Gallagher wrote:
A "standard" "obsoleted" by a "proposed standard" or a "draft
standard" is nonsense. A standard is obsoleted by a new standard, not
a draft or a proposal. RFC 821-822 are still the standard, until their
obsoleting drafts and proposals become the new
A "standard" "obsoleted" by a "proposed standard" or a "draft standard" is
nonsense. A standard is obsoleted by a new standard, not a draft or a proposal.
RFC 821-822 are still the standard, until their obsoleting drafts and proposals
become the new standard, and are clearly identified as such.
You are wrong. Read again.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 22:51, @lbutlr wrote:
> On 2018-02-11 (11:15 MST), Rupert Gallagher wrote: > > To you, and those like
> you, who claim better knowledge, read twice yourself, because the actual
> standard is still rfc 822. This sta
You confuse the press with the author.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 19:23, Reindl Harald wrote:
> Am 11.02.2018 um 19:15 schrieb Rupert Gallagher: > Who is the ignorant here?
> > > Rfc 822, standard: usa > Rfc 2822, *proposed standard*: usa not USA, IETF
> https://www.i
On Sunday 11 February 2018 at 23:04:52, Bill Cole wrote:
> On 11 Feb 2018, at 16:20 (-0500), Antony Stone wrote:
> > Strange that I can't find SMTP under
> > www.rfc-editor.org/rfc/std/std-index.txt
> > though, other than STD0060 and STD0071, which are both extensions.
>
> STD10 is SMTP (RFC821)
On 11 Feb 2018, at 16:20 (-0500), Antony Stone wrote:
Strange that I can't find SMTP under
www.rfc-editor.org/rfc/std/std-index.txt
though, other than STD0060 and STD0071, which are both extensions.
STD10 is SMTP (RFC821), STD11 is message format(RFC822).
--
Bill Cole
b...@scconsult.com or
On 2018-02-11 (11:15 MST), Rupert Gallagher wrote:
>
> To you, and those like you, who claim better knowledge, read twice yourself,
> because the actual standard is still rfc 822.
This statement is entirely false, irresponsibly so. RFC 822 was obsoleted by
RFC 2822 and RFC 2822 was obsoleted
On Sunday 11 February 2018 at 19:15:59, Rupert Gallagher wrote:
> Who is the ignorant here?
>
> Rfc 822, standard: usa
https://tools.ietf.org/html/rfc822 "Obsoleted by: 2822"
What do you mean by "Standard: USA"? I know what an IETF Standard is, and
it's quite different from an RFC, which we w
Who is the ignorant here?
Rfc 822, standard: usa
Rfc 2822, *proposed standard*: usa
Rfc 5321, *draft standard*: usa
Rfc 5322, *draft standard*: usa
...
The list goes on.
To you, and those like you, who claim better knowledge, read twice yourself,
because the actual standard is still rfc 822.
S
On 2018-02-11 (00:13 MST), Rupert Gallagher wrote:
>
> Interesting to kreme.
Not actually interesting to me, no.
> We are not in USA, where RFC loopholes are written to allow the NSA to send
> anonymous email with spyware, or companies to profit from massmail marketing.
> Spam assassins we a
On Sunday 11 February 2018 at 08:35:42, Rupert Gallagher wrote:
> We are not in USA, where RFC loopholes are written
Er, RFCs are written by IETF Working Groups, which are open to *anyone* to
contribute to, have members from many different countries and companies around
the world, and are not r
> good news is if non spammers begin to use pgp signed/encrypted mails, it
would not be spam anymore
If they send spam from an identifiable server within our legal reach, we turn
it to our local authority who exerts judiciary power to either shut down the
server, in case they are pure spammers,
Interesting to kreme.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 03:14, Benny Pedersen wrote:
> Rupert Gallagher skrev den 2018-02-10 23:26: > Interesting... how ? > >
> Final-Recipient: rfc822; krem...@kreme.com > Original-Recipient:
> rfc822;krem...@kreme.com > Action: failed > Sta
I am not protonmail.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 03:12, Benny Pedersen wrote:
> Rupert Gallagher skrev den 2018-02-10 23:18: > pay their clients for each
> spam message they deliver, they would be > all bankrupt, except us. if
> protonmail worked, spamasassin could not
I read the RFC as anybody else, and get as close as possible to cite it when
rejecting. The fact that the RFC has loopholes is not my fault.
Sent from ProtonMail Mobile
On Sun, Feb 11, 2018 at 01:17, Reindl Harald wrote:
> Am 10.02.2018 um 23:18 schrieb Rupert Gallagher: > We do not serve free
On 2018-02-10 (15:26 MST), Rupert Gallagher wrote:
>
> Interesting...
>
>
> Final-Recipient: rfc822; krem...@kreme.com
> Original-Recipient: rfc822;krem...@kreme.com
> Action: failed
> Status: 5.7.1
> Remote-MTA: dns; mail.covisp.net
> Diagnostic-Code: smtp; 550 5.7.1 : Helo command rejected:
On 2018-02-10 (12:07 MST), Joseph Brennan wrote:
>
> --On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr" wrote:
>> RFC 822 hasn't been valid for nearly two decades.
>
> Yes of course. My point was that even decades ago, To and Cc headers were not
> required by RFC 822, so our contributor shoul
Rupert Gallagher skrev den 2018-02-10 23:26:
Interesting...
how ?
Final-Recipient: rfc822; krem...@kreme.com
Original-Recipient: rfc822;krem...@kreme.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.covisp.net
Diagnostic-Code: smtp; 550 5.7.1 : Helo command
rejected:
Mail for this TLD
Rupert Gallagher skrev den 2018-02-10 23:18:
pay their clients for each spam message they deliver, they would be
all bankrupt, except us.
if protonmail worked, spamasassin could not scan spam :=)
oh well, pgp is cool, but as its implented on protonmail it does not
matter at all
i think this
Interesting...
Final-Recipient: rfc822; krem...@kreme.com
Original-Recipient: rfc822;krem...@kreme.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.covisp.net
Diagnostic-Code: smtp; 550 5.7.1 : Helo command rejected:
Mail for this TLD is not allowed
--
We do not serve freemail or large ISPs, so our use case is different than
yours. We serve businesses who own their email by law. When an employee sends
or receives an email, their employer owns the email, by law. We can, and we do
reject spam: the recipient will never see it, by contract. Possib
On 10 Feb 2018, at 16:00 (-0500), Alex wrote:
Can we really trust end-users to properly classify email and not
infect themselves with something or follow a phish without knowing?
Nope. However, we need to act like we do to some degree while doing the
best we can to make it difficult for them
Hi,
On Sat, Feb 10, 2018 at 12:04 PM, @lbutlr wrote:
> On 2018-02-10 (00:01 MST), Rupert Gallagher wrote:
>>
>> The RFC should be amended. If not, we still reject on common sense. Our
>> mail, our rules.
>
> My rule is that I do everything I can to reject mail. I look at the IPs,
> headers, Su
--On February 9, 2018 at 5:46:39 PM -0700 "@lbutlr"
wrote:
RFC 822 hasn't been valid for nearly two decades.
Yes of course. My point was that even decades ago, To and Cc headers were
not required by RFC 822, so our contributor should not say that he is
blocking for violating RFC 822.
On 2018-02-10 (00:01 MST), Rupert Gallagher wrote:
>
> The RFC should be amended. If not, we still reject on common sense. Our mail,
> our rules.
My rule is that I do everything I can to reject mail. I look at the IPs,
headers, Subject, and content. I look for suspicious attachments, dangerous
If you pick up the snail mail equivalent, you either have spam without address
or a mail with someone else's address. We put the spam where it belongs, and
return the other unopened.
We make no exception to e-mail, because they are mail after all.
The RFC should be amended. If not, we still rej
On 2018-02-09 (14:26 MST), Joseph Brennan wrote:
>
> RFC 822,
RFC 822 hasn't been valid for nearly two decades.
The current RFC is 5322.
"The only required header fields are the origination date field and the
originator address field(s). All other header fields are syntactically
optional."
Objection. RFC 822, section A.3.1 "Minimum required" shows two alternatives
of the minimum. The one on the left has Date and From and Bcc, and the Bcc
has no address in it. The other one on the right has Date and From and a To
field with an address in it.
Now read it again:
C.3.4. DESTINATION
On 2018-02-08 (08:23 MST), David Jones wrote:
>
> But how can you tell the difference based on content then? You can't. Two
> different senders could send the exact same email and one could be spam from
> tricking the recipient to opt-in and another could be ham the recipient
> consciously op
If you agreed to receive news from X, and receive them via mass-mailer Y, be
prepared to also receive from Z via Y, where Z is third party on behalf of X or
Y. Morale: when you agree to X, remember to opt out to their third parties.
Sent from ProtonMail Mobile
On Thu, Feb 8, 2018 at 16:23, Davi
On 20180208 23:24, Reindl Harald wrote:
Am 09.02.2018 um 01:20 schrieb jdow:
On 20180208 07:23, David Jones wrote:
On 02/07/2018 06:28 PM, Dave Warren wrote:
On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
Technically, you asked for the email and they have a valid opt-out
process that
On 20180208 07:23, David Jones wrote:
On 02/07/2018 06:28 PM, Dave Warren wrote:
On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
Technically, you asked for the email and they have a valid opt-out
process that will stop sending you email. Yes, the site has scummy
practices but that is not
On Thu, 2018-02-08 at 09:23 -0600, David Jones wrote:
> On 02/07/2018 06:28 PM, Dave Warren wrote:
> > On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
> > > > Technically, you asked for the email and they have a valid opt-
> > > > out
> > > > process that will stop sending you email. Yes, th
Hi All,
dkimwl.org is a site owned and run by myself.
A little bit of work is required to get the TOU sorted - I'd floated the idea
some time ago but not much interest was seen so I stopped work on the front end
services. The backend and classification/voting system is in place and should
work
On 08-02-18 16:33, Giovanni Bechis wrote:
> On 02/08/18 16:23, David Jones wrote:
>> On 02/07/2018 06:28 PM, Dave Warren wrote:
>>> On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
> Technically, you asked for the email and they have a valid opt-out
> process that will stop sending you
On 02/08/18 16:23, David Jones wrote:
> On 02/07/2018 06:28 PM, Dave Warren wrote:
>> On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
Technically, you asked for the email and they have a valid opt-out
process that will stop sending you email. Yes, the site has scummy
practices
On 02/07/2018 06:28 PM, Dave Warren wrote:
On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
Technically, you asked for the email and they have a valid opt-out
process that will stop sending you email. Yes, the site has scummy
practices but that is not spam by my definition.
Yes, under EU
On Feb 7, 2018, at 06:17, David Jones wrote:
>
> Hypothetical question: If you signed up for a new account on a website and
> they had a small checkbox that was enabled to receive emails from them and
> you didn't see it to uncheck it, when you get an email from them a month
> later, is that s
On Wed, Feb 7, 2018, at 15:52, Martin Gregorie wrote:
> > Technically, you asked for the email and they have a valid opt-out
> > process that will stop sending you email. Yes, the site has scummy
> > practices but that is not spam by my definition.
> >
> Yes, under EU/UK that counts as spam bec
> Technically, you asked for the email and they have a valid opt-out
> process that will stop sending you email. Yes, the site has scummy
> practices but that is not spam by my definition.
>
Yes, under EU/UK that counts as spam because the regulations say that
the signer-upper must explicitly c
On 02/06/2018 07:43 PM, jdow wrote:
On 20180206 16:56, Miles Fidelman wrote:
On 2/6/18 2:47 PM, Anne P. Mitchell Esq. wrote:
I know the definition of spam is very subjective and dependent on
your particular the mail flow along with the expectations of the
recipients.
Back when I was in-hou
Case study...
Well-known MTAs and SA itself allow (do not reject, do not flag) e-mails with
absent or empty "To" header.
If I receive one such snail mail, I know it is not for me, and I know it is
unwanted commercial advertisement that fills the mailbox and litters the floor.
RFC 822, page 42,
On 20180206 16:56, Miles Fidelman wrote:
On 2/6/18 2:47 PM, Anne P. Mitchell Esq. wrote:
I know the definition of spam is very subjective and dependent on your
particular the mail flow along with the expectations of the recipients.
Back when I was in-house counsel at MAPS, Paul (Vixie) and I
On 2/6/18 2:47 PM, Anne P. Mitchell Esq. wrote:
I know the definition of spam is very subjective and dependent on your
particular the mail flow along with the expectations of the recipients.
Back when I was in-house counsel at MAPS, Paul (Vixie) and I came up with this
definition of spam
>
> I know the definition of spam is very subjective and dependent on your
> particular the mail flow along with the expectations of the recipients.
>
Back when I was in-house counsel at MAPS, Paul (Vixie) and I came up with this
definition of spam:
“An electronic message is “spam” IF: (1)
I know the definition of spam is very subjective and dependent on your
particular the mail flow along with the expectations of the recipients.
On 02/06/2018 02:06 PM, David B Funk wrote:
On Tue, 6 Feb 2018, Kris Deugau wrote:
Alex wrote:
These phishes we've received were all from otherwise t
49 matches
Mail list logo
