[mailop] Question on presence of sender certificate in an enveloped-data S/MIME bodypart

2018-08-24 Thread Rolf E. Sonneveld

All,

can anyone enlighten me on the following two questions, related to S/MIME:

1. does an S/MIME message with a bodypart labelled
   application/pkcs7-mime and smime-type=enveloped-data
   always/usually/never carry the certificate of the sender?
2. I tried to extract the certificates from the bodypart using:

   openssl pkcs7 -in  -inform DER -print_certs

   I get no errors, but zero output as well. Not sure what I'm doing
   wrong. When trying the following:

   openssl smime -in  -pk7out -out msg.pk7
   openssl asn1parse -in msg.pk7

   I get the ASN1 structure, showing two certificates, one root and one
   intermediate. Can I be sure that the bodypart doesn't carry the
   sender's certificate, or does it depend on the inner structure of
   the .p7m blob?

Thanks,

/rolf


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


Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

2018-08-24 Thread David Hofstee
should have addressed it to Jan...

David H

On Fri, 24 Aug 2018 at 10:07, David Hofstee 
wrote:

> Hi David C,
>
> I've had my dealings with these quote sites... It may apply to you. The
> actions you take seem to target email address validity, but Google cites
> complaints as the issue. None of your answers seem to target the problem of
> "do recipients want the email" effectively imho.
>
> My question would be: Why would the customer ask for an email address if
> the recipient only wants the quote?
> Answer: Because the customer doesn't want to "lose" the recipient.
>
> Question: Does the recipient want anything more than the quote?
> Answer: Likely (s)he does not.
>
> You can:
> - Test this by measuring how many temporary email addresses are in the
> list (e.g. @mailinator.com). If that percentage is relatively high,
> recipients do not trust and/or want to have a relationship with the sender.
> Otherwise they would provide their real email address.
> - Measure this by adding a "complaint" option in the unsubscribe form (so
> you can measure how many recipients didn't want the mails). Be sure to add
> a "free field" so people can explain why. Getting complaints and "the
> story" behind such issues is what deliverability is about... The
> unsubscribe form is by far the most useful tool to understand what
> recipients are thinking.
>
> Bottom line is that unless the recipient wants and expects every email,
> providing him/her with real value, the spam button will be hit... In this
> business case, getting data from the recipient to entice him/her into
> further contact is maybe seen as "aggressive" and people get to vote with
> the spam button.
>
> Yours,
>
>
> David H.
>
> On Thu, 23 Aug 2018 at 21:26, Jan Schapmans 
> wrote:
>
>> Hi David,
>>
>>
>>
>> thank  you very much for your answer.
>>
>>
>>
>> I think you are fully right stating that only changing the sending domain
>> and/or IP addresses won’t help.
>>
>> That’s just why we continue trying other things at the same time
>>
>>- only targeting recent engaged (open/click) users from the last 10
>>days
>>- making sure all clicks on unsubscribe link are processed as an
>>unsubscribe (without the users completely processing the unsubscribe flow)
>>- deduplicate all send outs (we’ve noticed some users are more than
>>once in the system because they’ve filed multiple requests)
>>
>>
>>
>> Only thing missing in their best practices, if we are not missing
>> anything, is that they don’t do double optin. To get them to implement
>> double optin, we are pushing to do this only for Gmail.
>>
>>
>>
>> We are:
>>
>>- using DMARC with reject policy
>>- all emails singed with DKIM
>>- Google postmaster ip reputation BAD, domain reputation BAD &
>>complaint rate ok and of course very low at the end because of no inbox
>>placement.  In the feedback loop there is no mentioning of any identifier
>>you can see below we were in a happy place first, and slowly it got
>>worse & worse
>>- list is acquired by a webform where users request a valuation of
>>their car
>>- customer doesn’t want to do double optin, we are pushing to only
>>implement it for gmail & googlemail addresses.
>>(do you think gmail is also monitoring other domains? google apps?)
>>- spam message says (sorry for the Dutch)
>>
>>
>>
>>
>>
>> kr,
>>
>>
>>
>> Jan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* David Carriger 
>> *Sent:* 22 August 2018 22:13
>> *To:* Jan Schapmans ; mailop@mailop.org
>> *Subject:* Re: Gmail - Anybody out there from Gmail, willing to assist
>> with strange reputation issue
>>
>>
>>
>> Changing the sending domain and the IP addresses won't help at all if you
>> haven't solved the underlying issue, you're just kicking the deliverability
>> can down the road. Is the domain using DMARC to prevent spoofing, and
>> what's the policy? Are all emails signed with DKIM? What does Google
>> Postmaster Tools show for IP reputation, domain reputation, and complaint
>> rates? How is the customer acquiring their list? Are they using double
>> opt-in? When an email goes to the spam folder, does Gmail show a banner
>> saying why it was sent to spam? If so, what's the banner say?
>>
>> Gmail is very good at spam filtering, so your best bet is to assume
>> there's a problem with the sender's practices and work backwards from there.
>> --
>>
>> *From:* mailop  on behalf of Jan Schapmans <
>> jan.schapm...@selligent.com>
>> *Sent:* Wednesday, August 22, 2018 8:25:46 AM
>> *To:* mailop@mailop.org
>> *Subject:* [mailop] Gmail - Anybody out there from Gmail, willing to
>> assist with strange reputation issue
>>
>>
>>
>> Dear Gmail,
>>
>>
>>
>> we are having for a UK customer an inboxing problem with Gmail and only
>> Gmail. Over a month ago we’ve changed their ip addresses, changed their
>> sending domains, started warming up again, all was good until a few week
>> ago: the reputation of ip’s & 

Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

2018-08-24 Thread Vittorio Bertola
> Il 23 agosto 2018 alle 21.10 Jan Schapmans  ha 
> scritto: 
> 
> Only thing missing in their best practices, if we are not missing anything, 
> is that they don’t do double optin. To get them to implement double optin, we 
> are pushing to do this only for Gmail.

Oh well, just a minor thing... :-O

IMHO anyone in Europe - or having significant numbers of European users - not 
using double opt-in on each and every subscription is looking for serious 
trouble, as it will be impossible for you to demonstrate that you acquired 
explicit and unequivocal consent, as required by the GDPR, when adding the 
user's email address to your list. Anyone can just drop by and type any email 
address, which, by chance, is going to be someone else's email address that you 
are going to start spamming. It just takes a few of these people to start 
complaining and you're going not just to be blacklisted, but to get hefty fines 
by the relevant DPA.
 
Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

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


Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

2018-08-24 Thread Stefano Bagnara
On Thu, 23 Aug 2018 at 21:14, Jan Schapmans  wrote:
>
> list is acquired by a webform where users request a valuation of their car
> customer doesn’t want to do double optin, we are pushing to only implement it 
> for gmail & googlemail addresses.
> (do you think gmail is also monitoring other domains? google apps?)

So, what does it happen when the user fill in the webform?
You simply put the email in the DB and use it later? Or what else?

But yes, doing "non confirmed" opt-in today is risky, and you just
discovered some of them: just report back to the customer and let him
decide if he still wants single opt-in even if this means "junk
folder".

And yes, GSuite domains all counts in the reputation for Google, so if
you have inboxing issues to Gmail you most likely can see them on
GSuite domains too. There are a lot of business domains there, today
and if you want to treat them differently from other you'll have to
start collecting the MX for each domain and add rules for MXes.

Stefano

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


Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

2018-08-24 Thread Philip Paeps

On 2018-08-23 19:10:50 (+), Jan Schapmans wrote:
Only thing missing in their best practices, if we are not missing 
anything, is that they don't do double optin. To get them to implement 
double optin, we are pushing to do this only for Gmail.


So your customer is a spammer.

Unless you confirm opt-in, you have no way of knowing that your email is 
wanted.  If it's not wanted, it's spam.


* Google postmaster ip reputation BAD, domain reputation BAD & 
complaint rate ok and of course very low at the end because of no 
inbox placement.  In the feedback loop there is no mentioning of any 
identifier


you can see below we were in a happy place first, and slowly it got 
worse & worse


The system is working well.

* list is acquired by a webform where users request a valuation of 
their car


People can input any address they like in this form.  Unless you confirm 
opt-in, you have no way of knowing if that address wants your email.  


Any email you send to an address that hasn't requested it is spam.


 * customer doesn't want to do double optin


Get rid of the customer.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

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