google reads your mail

Linux with Chromium here, gmail no problem, works worldwide. I do have other email addresses though, I like pop email, using fetchmail and alpine. No problems ever. emails I liked are all saved, going back on this Raspberry to year 2006. Older ones on the old PC upstairs, then alpine was called 'pine'.

I can use 'grep' in my email directory to find any subject discussed in emails since 2006.

All backed up too.

If the email doesn't bounce then it is likely to be in the recipient's junk folder which most people either don't check or don't know it exists.

This will likely tell you the reason. It may not be an issue with gmail.

Those of us who don't always want our correspondence read will find other ways to communicate.

It's probably nothing to do with the contents of the emails. I've had several different emails bounce with an error, and then later on, send- ing just worked.

Writing an email, with Gmail, is an exercise in stochastic luck. For imporant emails, I'm now using a different email provider, and I sugg- est you do the same.

Best wishes, and happy emailing.

Or, ensure nothing being said needs to be shielded from prying eyes!

Email is a postcard -- every hand that it passes through has a chance to read its contents (doubly so if those hands are electronic in nature!).

Presumably, you don't have problems contacting other MX's so its not a local block on 25.

Have you tried TELNETing to the particular MX server to see if the connection is blocked? Or, possibly, just "deferred"?

Is your hosting ISP "dubious" and possibly blacklisted (not for YOUR actions but for the actions of others at that origin point)

Is your host's DNS configured properly (esp PTR records)?

Moderation is a thankless job as everyone has a different idea of what is "appropriate".

I built a mailing list moderator that allows the list recipients to determine when posts are inappropriate (because they care being delivered

But, because any "censor's" actions are visible to all (even if taken after-the-fact), folks are hesitant to be too self-righteous in their condemnations. The censor is equally likely to meet with the disdain of other list members for their actions ("You don't have to READ anything that you don't want to read. Set a filter to kill off those messages AND FOLLOWUPS to it so you have no evidence of the offending message in your mbox")

I've heard some Ham-operated (email) networks ban profanities in messages because profanity is banned in spoken word?

I just emailed myself from one account using gmail, sent using postfix, to another account on gmail, using thunderbird internal system. No problem.

Of course, if your mailer does not support oauth2 (mine doesn't), you have to use application passwords (I do).

So let them read about your vacation, unaware of the steganographically encoded message in the picture.

Google wants sending server to cryptographically sign the message. Which means that if things go to the court and receiver presents messages from you they are likely to be accepted as valid proof that you sent them. As a byproduct message that they accept can be traced to the machine that sent it.

This leaks some information, but given that there is a lot of spam and scams I think that this strikes resonable balance between protecting privacy of the sender and legitimate right of receiver to know identity of the sender. Actually, it signature only confirms sending machine, it is up to the sending machine if it clearly discloses your identity or uses some form ot cryptic id. For example sending machine may offer you "one-time" accounts used only for single e-mail exchange. Given a warrant law enforcement is expected to establish your real identity from this data but otherwise is leaks far less information than say visiting a web site would do.

Steganalysis can detect the presence of certain types of hidden/encoded data.

Note, also, that you needn't rely on images (or sound clips or any other "container") to obfuscate the hidden channel. It can be present in plain text (e.g., the Prisoner's Problem) or the *presentation* of that plain text (use of capitalization, interword spacing, line breaks, etc.).

The problem is ensuring that any transforms applied to the container (by the entity used to convey it) don't break/distort the encoded message. E.g., reencoding a JPEG at a snaller size, etc.

/Can/ does not imply that a run of the mill three letter agency stegana- lyst will. Now, I admit I do not have any of their tool-kits, so I wouldn't off hand know what they do and don't detect if they start look- ing. I am however fairly certain I can devise a method to hide infor- mation undetectable by the amateur antisteganographer [1].

I also feel no need to explain to the public at large how I'd do so, but you are free to raise a challenge if you think it amounts to something.

Best wishes, and happy steganography!

Having access to tools and a near-endless stream of data (in digital form best suited to such analysis), I wouldn't doubt *someone* has already considered (and acted upon?) the idea. "Amateurs" likely have neither the tools nor the access.

There are *countless* ways of "hiding information", especially if the bandwidth (or, total amount of data) is unspecified.

Outlook adresses block my messages from Friday afternoons until Monday mornings (the timing varies a bit) some weekends.

I don't know how to do that.

That seems to be the case for USEPROTECTL3

No idea.

ALL outgoing messages? Or, just gmail?

# nslookup -type=MX gmail.com

This asks "your" name server to tell you the MX (Mail eXchange) record associated with "gmail.com" (the messages you can't seem to send). It will produce a list of one or more fully qualified host names that will accept inbound connections for mail destined for "gmail.com".

Each will declare a "preference" as to its usage (the lower the preference number, the more it wants to be contacted -- use higher number preferences if the lower ones are busy, offline, etc.)

This isn't a "privileged" operation; you are asking YOUR name server to get this information for you (it may tell you -- your "resolver" -- to contact ANOTHER name server for the actual details, but the data is publicly accessible)

# telnet <name_of_mail_sever_from_above> 25

This tries to connect to the named host on port 25 (which is the "well known" SMTP port). If this *fails*/refused, then that host doesn't want to talk to you (*there*).

If a connection is established (usually a 220 reply), the remote server will expect you to engage in a series of protocol steps (the 'P' in SMTP) to present mail messages to users in the domains it handles (gmail.com).

HELO <your host name>

MAIL FROM:<you or someone else>

RCPT TO:<some email address>

DATA <message being sent>

CRLF.CRLF

QUIT

Your MUA does this automatically for you when you send a message.

As a crude security check, the mail server may take the IP address that you connected *from* (which it knows while the connection is established) and try to map that back to a host name. So, you can't claim to be someone/something else.

That is unlikly to work with Google. I did not try but I think that Google quite early will try to switch to encrypted connection. Before accepting any mail it will require sender to authenticatate itself (that I know for sure). So, you need valid domain certificate for the sending domain and appropriate MX record in DNS. Google is actualy slightly more liberal in what it accept than some other major companies and the above was enough in the past. I think that now you also need valid DKIM record. There are some alternatives to DKIM and maybe they work, but I know for sure that combination above (domain certificate + DKIM record) works for sending mail to Google.

Mail servers that accept old way without autentication are rare. Some accept mail just based of MX record and domain certificate.

Spoofing DNS was possible in the past, so it used to be weak test (still useful to limit amount of incoming spam). Now most receivers demand cryptographic authentication (at least domain certificate).

We already KNOW that google isn't accepting her mail. The question is WHERE in the protocol the problem manifests.

Oh, my original idea -- the one I was thinking of for the challenge -- is almost certainly /well known/ in the three letter agency world. But given the brief overview of a tool used by a /security expert/, I forgot which or maybe it wasn't named, it didn't seem to be a standard feature.

Then, if I make a custom implementation, there's no guarantee a three letter agency tool will catch it. Just add a little bit of twist, and it may well bypass the filters the three letter agencies use.

Or trigger an alert if a /well known adversary/ has used it before. It's kind of 50/50 that way.

Yes, you could for example use /Linear A/, and relatively few people in the world would be able to tell you're using English -- or another mod- ern language -- rather than whatever language it was originally used for.

As far as I can tell, there are a lot of cocky people out there who talk about /statistical analysis/ but then have never coded their own code breaker, and can't get past Cryptopals set 1, challenge 3.

I've re-added sci.crypt because of the Cryptopals challenge, and added alt.history.ancient-worlds for Linear A.

Happy codebreaking Linear A!