Re: [mailop] Anyone using clustered DoveCot?

[Dr. Christopher Kunz via mailop]

Am 23.01.21 um 16:38 schrieb Noel Butler via mailop:

Hi Tom,

What did you want to know?

load balancer multi imap, pop3, smtp with dovecot using NFS to EMC 
storage backend works exceptionally well.



Hi,

we've been using dovecot+postfix+nfs+netapp+loadbalancing (3 nodes, 
layer-3 loadbalancing via DSR) for a while now and we keep seeing 
corrupted indexes infrequently. It's always annoying when this happens 
because clients re-download all headers, and we haven't been able to 
pinpoint the reason properly. It's a small setup with hundreds of 
Maildirs (previously we also tried mdbox) and thousands of messages per 
day, so not really a huge thing. The load balancing is mainly for HA 
reasons, not so much for actual load.


Some of the error messages that we see:

Jan 28 08:32:55 mail-3 dovecot: imap(r...@act.ed): Error: 
/mail/domains/act.ed/red/Maildir/dovecot.index log position went 
backwards (2,14824 < 5,22112)
Jan 28 08:30:16 mail-3 dovecot: imap(r...@act.ed): Error: Corrupted 
index cache file 
/mail/domains/act.ed/0/red2/Maildir/dovecot.index.cache: invalid record size


There are some NFSv4 errors, but they do not correspond to the dovecot 
issues:


[2747664.891850] NFS: v4 server returned a bad sequence-id error on an 
unconfirmed sequence 9e035db2c620!


We tried most of the possible remedies from the usual public sources 
(Dovecot wiki, Heinlein Support who have some excellent slide decks out 
there), but nothing helped so we have had a long-standing ticket to 
migrate everything to a director setup.

However it seems like this might not help our case at all?

Maybe someone has some additional pointers what to look at?

Thanks,

chris



OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Jay R. Ashworth via mailop]

- Original Message -
> From: "Dave Crocker via mailop" 

> On 1/27/2021 4:40 AM, Thomas Walter via mailop wrote:
>> My understanding is that a quoted pair can contain characters that
>> otherwise would be treated differently. Characters like spaces, but also
>> angle brackets and such.
>> 
>> So in the following header, the address should be the last part in angle
>> brackets (""), but the first part should be the
>> "name" part, including the angle-brackets and email - "Some Person
>> "?
> 
> That sounds right.
> 
> Relevant ABNF from RFC 5322, where the comments for qtext are probably
> the most helpful:

So you agree with him that an angle-bracketed address *inside quotes* should
be ignored by an MUA -- at least if there's a valid address not inside quotes
in the same header?

Should the MUA go inside the quotes in the header to find one if there isn't
one that's quoted?  Or should it error out as "no address to reply to"?
I would think it should error; the 'protection' of the quoting shouldn't
be conditional.

Sounds like Thomas thinks Tbird has a bug in its header parsing code, and I 
agree with him -- and, I think, you.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Dave Crocker via mailop]

On 1/27/2021 4:40 AM, Thomas Walter via mailop wrote:

My understanding is that a quoted pair can contain characters that
otherwise would be treated differently. Characters like spaces, but also
angle brackets and such.

So in the following header, the address should be the last part in angle
brackets (""), but the first part should be the
"name" part, including the angle-brackets and email - "Some Person
"?



That sounds right.

Relevant ABNF from RFC 5322, where the comments for qtext are probably 
the most helpful:



qtext   =   %d33 / ; Printable US-ASCII
   %d35-91 /  ;  characters not including
   %d93-126 / ;  "\" or the quote character
   obs-qtext

   qcontent=   qtext / quoted-pair

   quoted-string   =   [CFWS]
   DQUOTE *([FWS] qcontent) [FWS] DQUOTE
   [CFWS]



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Problems with Proofpoint?

[Jaren Angerbauer via mailop]

On Wed, Jan 27, 2021 at 2:20 PM Simplelists - Andrew Beverley via mailop <
mailop@mailop.org> wrote:

> Hi,
>
> Is anyone else seeing any problems delivering to domains hosted at
> Proofpoint?
>
> We're seeing most (but not all) of our emails deferred, with a message
> to check the sending IP address at ipcheck.proofpoint.com. When we do
> that, the IP addresses are reported as not blocked.
>
> E.g.
>
> status=deferred (host mx0a-0016c301.pphosted.com[67.231.148.70] refused
> to talk to me: 421 Deferred - see
> https://ipcheck.proofpoint.com/?ip=78.143.254.171)
>
> I've contacted postmas...@proofpoint.com and also the recipient
> customer has contacted them, but just wondering whether this is a
> general issue or just us.
>
> The sending IP addresses in question are 78.143.254.171-174
>
> Thanks,
>
> Andy
>
>
Hi Andy,

Got your first email this morning :)

Will respond to you in a bit.

Thanks,

--Jaren
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Problems with Proofpoint?

[Simplelists - Andrew Beverley via mailop]

On Wed, 27 Jan 2021 14:24:17 -0700 Jaren Angerbauer wrote:
> Got your first email this morning :)
> 
> Will respond to you in a bit.

Brilliant, thanks Jaren. Sorry, I didn't want to assume you were on
standby for an instant response ;-)

Andy
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Problems with Proofpoint?

[Simplelists - Andrew Beverley via mailop]

Hi,

Is anyone else seeing any problems delivering to domains hosted at
Proofpoint?

We're seeing most (but not all) of our emails deferred, with a message
to check the sending IP address at ipcheck.proofpoint.com. When we do
that, the IP addresses are reported as not blocked.

E.g.

status=deferred (host mx0a-0016c301.pphosted.com[67.231.148.70] refused
to talk to me: 421 Deferred - see
https://ipcheck.proofpoint.com/?ip=78.143.254.171)

I've contacted postmas...@proofpoint.com and also the recipient
customer has contacted them, but just wondering whether this is a
general issue or just us.

The sending IP addresses in question are 78.143.254.171-174

Thanks,

Andy
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Spectrum postmaster/contact

[Rob Schneider via mailop]

Does anyone know how to contact Spectrum postmaster or can they contact me off 
list?  I've tried postmaster@spectrum and 
unbl...@charter.com and neither appears to be 
functioning.  We have a client getting the following bounce error, which seems 
a little backwards:
"This email account has been blocked from sending emails due to suspicious 
activity. Blocks will expire based on the nature of the activity. If you're a 
Spectrum customer, change all of your Spectrum passwords to secure your account 
and then contact us."

They are using their own sending domain, not a Spectrum one, so there's no 
Spectrum account sending.  We're not showing any complaints and they're on a 
dedicated IP.  It's mostly *.rr.com we're getting these bounces on.

Thanks,
Rob

This e-mail is from Mapp Digital and its international legal entities and may 
contain information that is confidential or proprietary.
If you are not the intended recipient, do not read, copy or distribute the 
e-mail or any attachments. Instead, please notify the sender and delete the 
e-mail and any attachments.
Please consider the environment before printing. Thank you.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] RFCs on quoted pairs in From:?

[Thomas Walter via mailop]

Hello everyone,

I have a question regarding the standards on mail headers, specifically
quoted-pairs in the From: header line.

My understanding is that a quoted pair can contain characters that
otherwise would be treated differently. Characters like spaces, but also
angle brackets and such.

So in the following header, the address should be the last part in angle
brackets (""), but the first part should be the
"name" part, including the angle-brackets and email - "Some Person
"?

From: "Some Person " 

I am asking, because for a while now we have seen lots of phishing
emails hiding their sender address behind an additional email address in
the name. Which works really well in mail clients only showing the name
part otherwise - not pointing fingers, but I hate that...

While playing with this I noticed that Thunderbird shows the full header
field without quotes and replies go to the first address - even though I
thought that is just the "name/description/comment" part?

And I wonder if that is an issue or if I just get the quoted-pairs part
of the RFCs wrong.

Same with comment braces like this:

From: (Some Person ) 

Thunderbird replies to "(Some Person " in that case.

Is either correct?

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Laura Atkins via mailop]

> On 27 Jan 2021, at 11:56, Peter Nicolai Mathias Hansteen via mailop 
>  wrote:
> 
> 
> 
>> 27. jan. 2021 kl. 12:23 skrev Laura Atkins via mailop > >:
>> 
>>> I know it sounds like a chore, but I would start by ensuring that the hosts 
>>> involved do meet the minimum standards such as having a valid reverse 
>>> lookup.
>>> 
>> This is one of those checkbox things I do recommend, but my experience is 
>> that Google is pretty forgiving of technical nits like this. And when they 
>> do have problems with how your IP address is configured they outright reject 
>> the mail, not accept it and drop it in the bulk folder. 
> 
> Interestingly, IIRC last time somebody in my immediate surroundings was bit 
> by Googgle’s policies on this, it looked like while they are fairly forgiving 
> for IPv4 hosts, they are very much not forgiving of any errors or deviations 
> as soon as delivery is attempted over IPv6. 

This is very true. Most folks who are accepting mail over IPv6 expect the 
technical setup to be impeccably clean. They’ll accept sloppy setup from IPv4 
and block sloppy setup from IPv6. But, again, they’re more likely to just 
reject the mail outright rather than accepting it and dropping it in the bulk 
folder. 

> There is no easy way to tell from here whether this is a factor here, though.

Not without a lot more access to information and a lot more investment of time. 
Figuring out what’s going on in situations like this is a major piece of what 
folks hire me to do professionally. I’ve shared how I’d approach it and things 
I’d look at, but more than that I can’t do here. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Peter Nicolai Mathias Hansteen via mailop]

> 27. jan. 2021 kl. 12:23 skrev Laura Atkins via mailop :
> 
>> I know it sounds like a chore, but I would start by ensuring that the hosts 
>> involved do meet the minimum standards such as having a valid reverse lookup.
>> 
> This is one of those checkbox things I do recommend, but my experience is 
> that Google is pretty forgiving of technical nits like this. And when they do 
> have problems with how your IP address is configured they outright reject the 
> mail, not accept it and drop it in the bulk folder.

Interestingly, IIRC last time somebody in my immediate surroundings was bit by 
Googgle’s policies on this, it looked like while they are fairly forgiving for 
IPv4 hosts, they are very much not forgiving of any errors or deviations as 
soon as delivery is attempted over IPv6.

There is no easy way to tell from here whether this is a factor here, though.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Laura Atkins via mailop]

> On 27 Jan 2021, at 10:26, Peter N. M. Hansteen via mailop  
> wrote:
> On 1/27/21 10:39 AM, postmaster outspot via mailop wrote:
> 
>> Google postmaster reports a bad reputation for outspot.fr 
>>  already since April 2020. The other domains are fine.
> One oddity I notice about that domain is that it has apparently handed over 
> incoming mail to google, but has a whole raft of other domains trusted by 
> inclusion in the SPF record. That might be one thing that does not help your 
> rating in Google's eyes. 
> 
That SPF record doesn’t look like a problem to me. A lot of folks have multiple 
outbound services that they use and includes to outside services are very 
common. 
> Also, the inclusion of "spf2.0/pra" which is seen as deprecated by most is 
> likely not helping and might even confuse some systems.
> 
This also isn’t really a problem to me. I’ve seen tons of domains that still 
have SenderID records and it doesn’t harm deliverability at all.
> And yet again, one of the pitfalls of including the SPF info domains possibly 
> run by others in yours increases your risk of suffering from any of their 
> potential screwups such as hosts among your allowed senders lacking proper 
> reverse lookup (which is one thing Google and others tend to frown upon quite 
> intensely).
> 
> I know it sounds like a chore, but I would start by ensuring that the hosts 
> involved do meet the minimum standards such as having a valid reverse lookup.
> 
This is one of those checkbox things I do recommend, but my experience is that 
Google is pretty forgiving of technical nits like this. And when they do have 
problems with how your IP address is configured they outright reject the mail, 
not accept it and drop it in the bulk folder. 

They use recipient feedback and interaction with mail as the primary driver of 
their delivery decisions.  
>> Are there any other solutions or direct contact points for this issue?
> I strongly suspect than anybody who manages to track down an actual person in 
> there would be quite firmly advised to not relay any such information to 
> others.
> 

As I tell clients, Google doesn’t really have knobs or buttons where individual 
google employees can adjust delivery for specific domains. Overall, you’ve got 
to cope with the ML filters and that means sending mail the recipients want and 
interact with in a way that tells google this mail should be delivered to the 
inbox (or promotions or update or whatever tab). 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Peter N. M. Hansteen via mailop]

On 1/27/21 10:39 AM, postmaster outspot via mailop wrote:
> Google postmaster reports a bad reputation for outspot.fr
>  already since April 2020. The other domains are fine.

One oddity I notice about that domain is that it has apparently handed
over incoming mail to google, but has a whole raft of other domains
trusted by inclusion in the SPF record. That might be one thing that
does not help your rating in Google's eyes.

Also, the inclusion of "spf2.0/pra" which is seen as deprecated by most
is likely not helping and might even confuse some systems.

And yet again, one of the pitfalls of including the SPF info domains
possibly run by others in yours increases your risk of suffering from
any of their potential screwups such as hosts among your allowed senders
lacking proper reverse lookup (which is one thing Google and others tend
to frown upon quite intensely).

I know it sounds like a chore, but I would start by ensuring that the
hosts involved do meet the minimum standards such as having a valid
reverse lookup.

> Are there any other solutions or direct contact points for this issue?

I strongly suspect than anybody who manages to track down an actual
person in there would be quite firmly advised to not relay any such
information to others.

- Peter

-- 

Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[postmaster outspot via mailop]

Hi Laura,

Thanks for the quick response.
Her is a graph for the specific .fr domain and the sends and click for the
gmail domain.

[image: Screenshot 2021-01-27 at 11.30.58.png]
You can see a peak at the beginning of April, this is the double sending,
at the same time you see a very large drop in the number of clicks and
these numbers havent increased since then.

answer on B) We have already experimented with decreasing the volume, as
you can see in the graph.
answer on D) This domain and IP addresses are only used by our organisation.

I have also checked the full content of the mail and compared this to the
other domains and no content difference is present.

Thanks for the further feedback.
Jonas

Op wo 27 jan. 2021 om 10:55 schreef Laura Atkins :

>
>
> On 27 Jan 2021, at 09:39, postmaster outspot via mailop 
> wrote:
>
> Dear all,
>
> I am the IT manager of a eCommerce company in Belgium.
> Google postmaster reports a bad reputation for outspot.fr already since
> April 2020. The other domains are fine. The bad reputation at google
> postmaster might be triggered because of a partial double mail sending from
> our side due to an error in our system in that time, which caused members
> to receive the same email twice.
>
>
> Google doesn’t remember for that long. I sincerely doubt that the problem
> is a single double mailing 9 months ago.
>
> From that moment our deliverability of the mails have decreased and
> stayed low sinds then.
> We already have done the following:
> - send an explanation in this form:
> https://support.google.com/mail/contact/bulk_send_new, already a few time
> over the month. But no changes are made.
>
>
> Likely because the double send isn’t the problem.
>
> Are there any other solutions or direct contact points for this issue?
>
>
> A) Ensure that your mail is actually going to bulk. I had one client that
> had a bad / medium reputation at Google, but their mail was actually
> inboxing for the most part. We spent a lot of time trying to fix the
> reputation without success but it didn’t matter as they were reaching the
> folks they needed to reach.
>
> B) Cut way back on your mail to google. Stop sending to anyone who is
> currently receiving the mail in their bulk folder. About the only way to
> know who’s getting mail in bulk is to focus on those folks who are opening
> or clicking on mail. Send only to people who have opened or clicked in the
> recent past (you can pick the timeline, but I don’t recommend going back
> more than 90 days for this). Do this for a minimum of a month.
>
> C) Monitor both delivery and your reputation. The reputation graphs at
> google are a lagging indicator and they take between 3 and 4 weeks to
> reflect changes in behavior.
>
> D) Investigate what mail that you don’t know is using your domain and
> ensure they implement the same level of hygine.
>
> laura
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Laura Atkins via mailop]

> On 27 Jan 2021, at 09:39, postmaster outspot via mailop  
> wrote:
> 
> Dear all,
> 
> I am the IT manager of a eCommerce company in Belgium.
> Google postmaster reports a bad reputation for outspot.fr 
>  already since April 2020. The other domains are fine. 
> The bad reputation at google postmaster might be triggered because of a 
> partial double mail sending from our side due to an error in our system in 
> that time, which caused members to receive the same email twice. 

Google doesn’t remember for that long. I sincerely doubt that the problem is a 
single double mailing 9 months ago. 

> From that moment our deliverability of the mails have decreased and stayed 
> low sinds then.
> We already have done the following:
> - send an explanation in this form: 
> https://support.google.com/mail/contact/bulk_send_new 
> , already a few time 
> over the month. But no changes are made.

Likely because the double send isn’t the problem. 

> Are there any other solutions or direct contact points for this issue?

A) Ensure that your mail is actually going to bulk. I had one client that had a 
bad / medium reputation at Google, but their mail was actually inboxing for the 
most part. We spent a lot of time trying to fix the reputation without success 
but it didn’t matter as they were reaching the folks they needed to reach. 

B) Cut way back on your mail to google. Stop sending to anyone who is currently 
receiving the mail in their bulk folder. About the only way to know who’s 
getting mail in bulk is to focus on those folks who are opening or clicking on 
mail. Send only to people who have opened or clicked in the recent past (you 
can pick the timeline, but I don’t recommend going back more than 90 days for 
this). Do this for a minimum of a month. 

C) Monitor both delivery and your reputation. The reputation graphs at google 
are a lagging indicator and they take between 3 and 4 weeks to reflect changes 
in behavior. 

D) Investigate what mail that you don’t know is using your domain and ensure 
they implement the same level of hygine. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop