Re: [mailop] IMAP to IMAP

[Ted Cabeen]

On 12/15/2017 12:27 PM, Steve Atkins wrote:

https://github.com/imapsync/imapsync or _maybe_ 
https://github.com/wrzlbrmft/imapcopy

If the destination system is dovecot then they should probably use dsync.

If the destination system is a Large Webmail Provider then they should probably use the 
providers "import a pop3 account" tool if possible.


That will only move INBOX, not sub-folders.

imapsync has a --gmail flag that handles all of the uniquenesses of 
Gmail. I've used it many times to migrate things.


--Ted


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail forwarding blowback

[Ted Cabeen]

I wonder if it would ever work to allow a server to forward a message 
while including headers that indicate the message had signs of spam.  It 
would only work in the negative direction (this message is spam, but not 
this message is ham).


I kind of think of in the way the courts do with declarations against 
interest.  They're admissible because the statement is so prejudicial, 
no one would make it falsely.  Likewise, no sender would have an 
interest in sending an email with spam headers attached, so they had to 
have been truthfully added by a forwarding server.


--Ted

On 11/8/2017 11:46 AM, Brandon Long via mailop wrote:
GSuite users can also denote a host as an inbound gateway to get around 
this problem, but I was never able to get the resources to have gmail 
users have the same ability.  It's possible this is something we could 
use arc for.


Brandon


On Wed, Nov 8, 2017 at 11:41 AM Alan Hodgson > wrote:


On Wed, 2017-11-08 at 12:20 -0700, Warren Volz wrote:


All,

One of my users has their account setup to forward mail to Gmail.
Recently I've started to see lots of rejects that look like the
following:

mailto:us...@gmail.com>> (expanded from
mailto:us...@somelocaldomain.net>>): host
gmail-smtp-in.l.google.com
[2607:f8b0:400e:c04::1a] said:
550-5.7.1
[ipv6 address 18] Our system has detected that
550-5.7.1 this message is likely suspicious due to the very low
reputation
of 550-5.7.1 the sending IP address. To best protect our users
from spam,
the 550-5.7.1 message has been blocked. Please visit 550 5.7.1
https://support.google.com/mail/answer/188131 for more information.
p26si2014836pli.781 - gsmtp (in reply to end of DATA command)

I've looked over the forwarding best practices provided by google
and we are not modifying the envelope sender. I'd rather not start
throwing away what our filter marks as spam since I leave that up
to the user, but is that the only way to stop the bounces? Also,
is the "18]" an artifact or some kind of error?

Thanks for the help.



IMO, you really can't forward mail to Gmail; they will block you if
you forward any spam at all.

Gmail accounts can be setup to pull mail in via POP-3, that's a far
better way for them to get their mail.
___
mailop mailing list
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

[Ted Cabeen]

On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:

STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.


Interestingly, that's not always the case now.  We typoed the cert on 
one of our list servers earlier this year, and discovered that Google 
outbound SMTP will not downgrade from TLS to plain text.  If you offer 
STARTTLS and then break the handshake, they bounce the mail.  I presume 
that it's a protection against downgrade attacks, but that's just a guess.


--Ted

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]

[Ted Cabeen]

On 2/12/2017 4:52 AM, Rich Kulawiec wrote:

On Wed, Jan 11, 2017 at 12:33:47PM -0800, Michael Peddemors wrote:

More and more, if you want to deliver email in today's environments, you
have to ensure your email servers are correctly configured.


I think there's considerable value in slowly enforcing this in stepwise,
announced fashion.


We used to have this, as rfc-ignorant.org.  Unfortunately, as they note 
in their shutdown notice, when the email space is dominated by large 
providers, they drive behavior, and the actions of small fry to enforce 
rules do not deter them from breaking the rules:

http://www.rollernet.us/wordpress/2012/09/dnsbl-rfc-ignorant-org-shutting-down-2/

Action here has to happen at the Google/Yahoo/Hotmail level.

--Ted

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Forwarding issues, was Mails to microsoft

[Ted Cabeen]

On 2/10/2017 3:14 AM, Klaus Ethgen wrote:

Never, never ever tell that to your users. Forward is the better idea
for that. Sure, you have to handle the spam yourself.


The challenge that we run into as mail providers is handling the the 
mail that we are uncertain about.  On a consolidated mail system, you 
can deliver the known-ham, discard/bounce the known-spam, and put the 
mail you are uncertain about in the users Spam/Junk folder.  When 
forwarding, I have no ability to pass a message to its new destination 
while noting that I am uncertain about the spamminess of the message and 
that it should be put in a Spam or Junk folder.  I just have to forward 
it on.


--Ted

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop