Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Alessandro Vesely via mailop]

On Mon 13/Dec/2021 18:51:48 +0100 Brandon Long wrote:

On Mon, Dec 13, 2021 at 9:46 AM Slavko via mailop  wrote:

Dňa Mon, 13 Dec 2021 18:19:07 +0100 Alessandro Vesely via mailop 
 napísal:


Is it customary to reject messages with multiple addresses in From:?
Why?


AFAIK, DMARC works with only one From: address, thus sites which
are verifying DMARC tends to reject multiple addresses in it.


Basically, yes, DMARC doesn't handle multiple from addresses, otherwise one
could do From: m...@whatever.com, accou...@google.com and which domain would
this be considered from?  I guess one could evaluate DMARC for both.



Evaluating both doesn't make much sense, because a DMARC receiver is actually 
verifying proper sending from the author's domain.  The author who added one or 
more coauthors in the From: line is still sending through her usual MUA and 
submission server.  Thus that's the only domain which is worth verifying.


A Sender: line should point to the right domain.  However, I'd propose that the 
sender be the first address in the From: line, which grants visibility and 
simplifies verifiers' code.




We also reject multiple From headers, which is much more common but
basically always an error or spam.



Yes, that's explicitly forbidden and a known DKIM vulnerability (DKIM signers 
should specify From: twice in h=).



Best
Ale
--








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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

>>Note that to validate the message, the app needs access to not only the 
>>signed header fields, but also the body, that the value of bh= is based upon.

Of course. That’s why I suggested that content validation should be ignored. 
Only headers should be validated.
Since the content is "signed" using bh= hash, the hash can be ignored and 
everything else can be validated.

This of course puts some responsibility on the user that is scanning the QR 
code, to ensure the details (from, to, date, subject) matches up with the email 
they are seeing on the screen, and that "date" is not too far in the past, so 
the QR code is not stolen from a legitimate email.

Since the To: header field is included in DKIM and QR code, it would mean a 
fraudster somehow needs to be able to gain access to the victim's mailbox to be 
able to mint a email that matches a QR code.

The idea here is that a end-user should be able to scan'n'verify a email by 
QR-code and not have to worry about phishing. Since the details about who 
signed the email and the data in email comes out in clear, it will be very 
evident if a emai from a bank is signed by "russianwebhost.ru" or similar and 
thus alert the user about phishing.

>> can implement new standards 

Its about excluding the client and the receiving server from the equation. If 
anyone - regardless of email operator or receiving server or client - can 
download a app and scan a QR code to ensure an email is not phishing, I think 
it gets traction, especially since the QR code would be visible in email, 
people would look up "Why does all email from Paypal now include a QR code" and 
they find out about the verification.

>>Are there still so many MUAs with no DKIM add-on?

MUAs need to include it per default for it to get traction.

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

Re: [mailop] [E] Re: Seeking route to AT Fraud on a weekend

[Lili Crowley via mailop]

Please contact me off list. I may be able to find the right team there.

Thanks!

On Mon, Dec 13, 2021 at 5:35 PM Michael Rathbun via mailop <
mailop@mailop.org> wrote:

> On Sun, 12 Dec 2021 08:42:23 + (GMT), Andrew C Aitchison via mailop
>  wrote:
>
> >Can your wife ask Frisco law enforcement to watch the address ?
>
> As noted:  nope.
>
> >If this were under UK law, the package would now belong to her, not AT
> >- which is a complication that works in the thieves favour in this sort
> of
> >crime.
> >You have an advantage in this case in that you know in advance that you
> >have title to the to-be-stolen object.
>
> Indeed.  Since AT Global Fraud department has been unreachable for
> several
> years, according to online gripes, and no other interesting avenues
> existed, I
> told FedEx to give me status notifications, and a friend of ours was
> available
> to sail by the address and snaffle the parcel within a few minutes of it
> being
> dropped.  It will be in our possession, if all goes well, in a couple days.
>
> It turns out that AT requires much more stringent personal
> identification to
> shut down a fraudulent account than to establish a fraudulent account.
>
> mdr
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.mailop.org_listinfo_mailop=DwIGaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=5Ps6gqx3JusivGVI-U9_l6qlVACXvsBn54y9pSHmSYw=0LQPDmA7sW_ey9xANwK28Im2KLCSxivAxauBmKx8bY1CUkExIFZd9kbg-hBh3YUp=U0_j8C_0RMk70b8S_6eMgHez8erTiMNtfn76zKScXUo=
>
-- 
Lili Crowley

she/her
Postmaster
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Seeking route to AT Fraud on a weekend

[Michael Rathbun via mailop]

On Sun, 12 Dec 2021 08:42:23 + (GMT), Andrew C Aitchison via mailop
 wrote:

>Can your wife ask Frisco law enforcement to watch the address ?

As noted:  nope.

>If this were under UK law, the package would now belong to her, not AT
>- which is a complication that works in the thieves favour in this sort of 
>crime.
>You have an advantage in this case in that you know in advance that you
>have title to the to-be-stolen object.

Indeed.  Since AT Global Fraud department has been unreachable for several
years, according to online gripes, and no other interesting avenues existed, I
told FedEx to give me status notifications, and a friend of ours was available
to sail by the address and snaffle the parcel within a few minutes of it being
dropped.  It will be in our possession, if all goes well, in a couple days.

It turns out that AT requires much more stringent personal identification to
shut down a fraudulent account than to establish a fraudulent account.

mdr

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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Dan Mahoney via mailop]

> On Dec 13, 2021, at 1:55 PM, Vsevolod Stakhov via mailop  
> wrote:
> 
> On 13/12/2021 17:19, Alessandro Vesely via mailop wrote:
>> Hi,
>> I assume everybody knows that RFC 5322 allows multiple mailboxes in the 
>> From: field.  This feature existed in RFC822 already.  I think it is to be 
>> used for those cases where multiple persons are authoring a message, albeit 
>> adding the list of coauthors is usually not done.  This message is an 
>> example.  How many rejects does it yield?
>> Gmail reacts like so:
>> Action: failed
>> Status: 5.0.0
>> Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
>> Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with multiple 
>> addresses in From:
>> 550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp
>> Is it customary to reject messages with multiple addresses in From:?  Why?
>> Best
>> Ale
> 
> 
> This is a clear case where RFC is wrong and bogus when one takes into 
> consideration other Internet standards, for example DMARC or even DKIM. There 
> is also a clear way to implement the behaviour you've described without such 
> a violation: just add a Reply-To header with multiple addresses.
> 
> Rspamd has a high score rule to penalize messages with multiple from, as I've 
> seen just spam with multiple from headers in practice like other people in 
> this mailing list.

Yeah, the university edge-case was one I could think of where for 
academic/journalistic reasons both a student and professor would be 
co-authoring/co-publishing a thing.  (Naming order is distinct enough (and 
matters) in that field, but I'll totally admit it's an extreme outlier).

-Dan

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

[mailop] Telenor.net/ Online.no Contact

[Kent McGovern via mailop]

If there is someone from Telenor.net/Online.no that could help with a
deliverability issue could you please contact me off list? One of our
senders is seeing an increase in reputation related bounces and we haven't
had any luck reaching someone through the normal channels to look into it.

Thanks,

Kent McGovern
Sr.Deliverability Strategist
Sparkpost
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Vsevolod Stakhov via mailop]

On 13/12/2021 17:19, Alessandro Vesely via mailop wrote:

Hi,

I assume everybody knows that RFC 5322 allows multiple mailboxes in the 
From: field.  This feature existed in RFC822 already.  I think it is to 
be used for those cases where multiple persons are authoring a message, 
albeit adding the list of coauthors is usually not done.  This message 
is an example.  How many rejects does it yield?


Gmail reacts like so:

Action: failed
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with 
multiple addresses in From:

     550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp


Is it customary to reject messages with multiple addresses in From:?  Why?


Best
Ale



This is a clear case where RFC is wrong and bogus when one takes into 
consideration other Internet standards, for example DMARC or even DKIM. 
There is also a clear way to implement the behaviour you've described 
without such a violation: just add a Reply-To header with multiple 
addresses.


Rspamd has a high score rule to penalize messages with multiple from, as 
I've seen just spam with multiple from headers in practice like other 
people in this mailing list.

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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Brandon Long via mailop]

Original-From: Alessandro Vesely , Coauthor Test <
u...@example.com>

(mailop list rewrote the from)

On Mon, Dec 13, 2021 at 11:32 AM Jaroslaw Rafa via mailop 
wrote:

> Dnia 13.12.2021 o godz. 18:19:07 Alessandro Vesely via mailop pisze:
> >
> > I assume everybody knows that RFC 5322 allows multiple mailboxes in the
> > From: field.  This feature existed in RFC822 already.  I think it is to
> be
> > used for those cases where multiple persons are authoring a message,
> > albeit adding the list of coauthors is usually not done.  This message is
> > an example.  How many rejects does it yield?
>
> Where does this message have multiple addresses in the "From:" field? I see
> only one:
>
> > From: Alessandro Vesely via mailop 
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Dan Mahoney via mailop]

> On Dec 13, 2021, at 9:44 AM, Slavko via mailop  wrote:
> 
> Signed PGP part
> Hi,
> 
> Dňa Mon, 13 Dec 2021 18:19:07 +0100 Alessandro Vesely via mailop
>  napísal:
> 
>> Is it customary to reject messages with multiple addresses in From:?
>> Why?
> 
> AFAIK, DMARC works with only one From: address, thus sites which
> are verifying DMARC tends to reject multiple addresses in it.

Dmarc works with multiple froms only in the case where the froms are in the 
same sending domain.

https://github.com/trusteddomainproject/OpenDMARC/blob/master/SECURITY/CVE-2019-16378

-Dan

> 
> regards
> 
> -- 
> Slavko
> https://www.slavino.sk
> 
> 

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

Re: [mailop] [E] Attempting to resolve a mailing list deliverability issue (Windstream / Spectrum / Juno / Yahoo)

[Lili Crowley via mailop]

Hey Chad -

Please contact me off list. I can help with Yahoo/AOL.

Thanks!

Lili Crowley

she/her
Postmaster





On Mon, Dec 13, 2021 at 2:25 PM Chad Dailey via mailop 
wrote:

> Hello--
>
> In the past month or so, a decade-old mailing list that I administer has
> been running into deliverability issues.  I'm reaching out to mailop
> because I'm at wits' end for figuring this out.  I'll outline what I
> believe to be useful background information below.  Hopefully someone can
> offer suggestions for next steps, even better would be contact from admin
> peeps of the networks that are rejecting list messages, but I'll take what
> I can get.  Please feel free to reach out on the list or PM me if you need
> additional information.
>
> Some details about the list:  MPA is the name of the list, hosted at
> accelix.net
> ,
> our longtime listserv provider.  We're pretty low traffic, a few to dozens
> of messages a month, with 73 unique email addresses signed up to receive
> traffic.  Membership has very low churn, most are very long term
> subscribers.  The oldest subscriptions were added manually, but we've since
> moved to invite / COI for all new subscribers as of a few years ago.  We
> perform an annual cull of recipient addresses that no longer wish to retain
> list membership, no response to the out of band message earns a drop from
> the list.  In addition, the listserv will also disable subscriptions that
> encounter repeated bounces.  Admittedly, bounce settings are pretty
> generous, but are configured that way due to subscriber ISP / mail
> providers that are less than reliable (welcome to the middle of nowhere).
> I've checked Spamhaus and a couple other public RBLs, and didn't find any
> negative reputation hits for the server.  List info can be found here:
> http://mm.accelix.net/mailman/listinfo/mpa
> 
>
> I thought maybe our website domain name change (it's in the message
> footer) was a factor, perhaps triggering a keyword string hit, but that
> four letter string was in the old domain name too.  I hesitate to mention
> the string here for fear of getting snagged again and preventing this
> message from reaching the admins that I really need to see it.  Hint:  it's
> shorthand for the folks that engineer noisy, colorful aerial displays on
> holidays, especially on Independence Day here in the 'states.
>
> According to the bounce messages, Spectrum (subscriber emails on Charter
> and RoadRunner domains) says we've got an AUP violation (AUP#In-1190), but
> I can't find anything in their ToS / AUP that would get us booted,
> Windstream says we're spamming.  Juno and Yahoo are apparently dropping
> messages silently, or their feedback isn't making it into bounce
> processing.  Of course, none of them will talk to me because I'm not their
> actual customer, and 'Shave and a haircut' doesn't open any doors.
>
> I have encouraged our users to reach out to their providers, and write
> mail filters for the listserv if they are able, but I have low confidence
> in those functions.  I'd rather fix the root of the problem instead.
>
> __
>
> Windstream reject messages:
>
>- The following addresses had permanent fatal errors -
> 
> (reason: 554 5.7.1 [VI-1] Message blocked due to spam content in the
> message.)
>
>- Transcript of session follows -
> ... while talking to mx01.windstream.net
> 
> .:
> >>> DATA
> <<< 554 5.7.1 [VI-1] Message blocked due to spam content in the message.
> 554 5.0.0 Service unavailable
>
> __
>
> Spectrum reject messages:
>
>- The following addresses had permanent fatal errors -
> 
> (reason: 552 5.2.0  sender rejected. Please
> see https://www.spectrum
> .net/support/internet/understanding-email-error-codes
> 
> for more information. AUP#In-1190)
>
>- 

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Jaroslaw Rafa via mailop]

Dnia 13.12.2021 o godz. 18:19:07 Alessandro Vesely via mailop pisze:
> 
> I assume everybody knows that RFC 5322 allows multiple mailboxes in the
> From: field.  This feature existed in RFC822 already.  I think it is to be
> used for those cases where multiple persons are authoring a message,
> albeit adding the list of coauthors is usually not done.  This message is
> an example.  How many rejects does it yield?

Where does this message have multiple addresses in the "From:" field? I see
only one:

> From: Alessandro Vesely via mailop 
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Attempting to resolve a mailing list deliverability issue (Windstream / Spectrum / Juno / Yahoo)

[Chad Dailey via mailop]

Hello--

In the past month or so, a decade-old mailing list that I administer has
been running into deliverability issues.  I'm reaching out to mailop
because I'm at wits' end for figuring this out.  I'll outline what I
believe to be useful background information below.  Hopefully someone can
offer suggestions for next steps, even better would be contact from admin
peeps of the networks that are rejecting list messages, but I'll take what
I can get.  Please feel free to reach out on the list or PM me if you need
additional information.

Some details about the list:  MPA is the name of the list, hosted at
accelix.net, our longtime listserv provider.  We're pretty low traffic, a
few to dozens of messages a month, with 73 unique email addresses signed up
to receive traffic.  Membership has very low churn, most are very long term
subscribers.  The oldest subscriptions were added manually, but we've since
moved to invite / COI for all new subscribers as of a few years ago.  We
perform an annual cull of recipient addresses that no longer wish to retain
list membership, no response to the out of band message earns a drop from
the list.  In addition, the listserv will also disable subscriptions that
encounter repeated bounces.  Admittedly, bounce settings are pretty
generous, but are configured that way due to subscriber ISP / mail
providers that are less than reliable (welcome to the middle of nowhere).
I've checked Spamhaus and a couple other public RBLs, and didn't find any
negative reputation hits for the server.  List info can be found here:
http://mm.accelix.net/mailman/listinfo/mpa

I thought maybe our website domain name change (it's in the message footer)
was a factor, perhaps triggering a keyword string hit, but that four letter
string was in the old domain name too.  I hesitate to mention the string
here for fear of getting snagged again and preventing this message from
reaching the admins that I really need to see it.  Hint:  it's shorthand
for the folks that engineer noisy, colorful aerial displays on holidays,
especially on Independence Day here in the 'states.

According to the bounce messages, Spectrum (subscriber emails on Charter
and RoadRunner domains) says we've got an AUP violation (AUP#In-1190), but
I can't find anything in their ToS / AUP that would get us booted,
Windstream says we're spamming.  Juno and Yahoo are apparently dropping
messages silently, or their feedback isn't making it into bounce
processing.  Of course, none of them will talk to me because I'm not their
actual customer, and 'Shave and a haircut' doesn't open any doors.

I have encouraged our users to reach out to their providers, and write mail
filters for the listserv if they are able, but I have low confidence in
those functions.  I'd rather fix the root of the problem instead.

__

Windstream reject messages:

   - The following addresses had permanent fatal errors -

(reason: 554 5.7.1 [VI-1] Message blocked due to spam content in the
message.)

   - Transcript of session follows -
... while talking to mx01.windstream.net.:
>>> DATA
<<< 554 5.7.1 [VI-1] Message blocked due to spam content in the message.
554 5.0.0 Service unavailable

__

Spectrum reject messages:

   - The following addresses had permanent fatal errors -

(reason: 552 5.2.0  sender rejected. Please
see https://www.spectrum
.net/support/internet/understanding-email-error-codes for more information.
AUP#In-1190)

   - Transcript of session follows -
... while talking to mx0.charter.net.:
>>> DATA
<<< 552 5.2.0  sender rejected. Please see
https://www.spectrum.net/support/internet/understanding-email-error-codes
for more information. AUP#In-1190
554 5.0.0 Service unavailable

__

Thank you for your attention,
Chad Dailey
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Brandon Long via mailop]

On Mon, Dec 13, 2021 at 9:46 AM Slavko via mailop  wrote:

> Hi,
>
> Dňa Mon, 13 Dec 2021 18:19:07 +0100 Alessandro Vesely via mailop
>  napísal:
>
> > Is it customary to reject messages with multiple addresses in From:?
> > Why?
>
> AFAIK, DMARC works with only one From: address, thus sites which
> are verifying DMARC tends to reject multiple addresses in it.
>

Basically, yes, DMARC doesn't handle multiple from addresses, otherwise one
could do From: m...@whatever.com, accou...@google.com and which domain would
this
be considered from?  I guess one could evaluate DMARC for both.

We also reject multiple From headers, which is much more common but
basically always an error or spam.

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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Slavko via mailop]

Hi,

Dňa Mon, 13 Dec 2021 09:51:48 -0800 Brandon Long 
napísal:

> Basically, yes, DMARC doesn't handle multiple from addresses,
> otherwise one could do From: m...@whatever.com, accou...@google.com and
> which domain would this
> be considered from?  I guess one could evaluate DMARC for both.
> 

Sure, one can evaluate both, but which policy have to be followed, if
one will be eg. reject and other success?

Especially, if the failing will be bank.com and success will be
attacker.com? IMO, this will negate DMARC's purpose.

regards

-- 
Slavko
https://www.slavino.sk


pgpF0kSkdIK4j.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Jan-Pieter Cornet via mailop]

On 13-12-21 18:52, Franck Martin via mailop wrote:


I checked it way back, and nearly all the cases were due to configuration 
errors on the sender part.

It is not a feature that is actively used in the wild. I don’t know of any 
email client that allows you to do that. So someone needs to craft a specific 
message and inject it.

Now, when DMARC was brought in, having 2 different domains in the RFC 5322 
from: does not allow DMARC to function. Technically, DMARC can work if all the 
domains in the RFC5322 from are the same, but I guess it is just easier to 
reject such message as the impact is close to zero and often multiple From is 
just a strong signal of badness/spam.


I agree with Franck.

Multiple addresses in the From: is extremely rare. At XS4ALL, we've been 
rejecting such messages since we implemented DMARC in 2012. The only rejects I 
ever saw were from misconfigured senders. We received zero complaints in the 9 
years we've been doing this.

Or rather, now that I look at the code... we reject messages with multiple 
addresses in the From: provided they are from different domains. Note that we 
always reject, even if none of the domains have dmarc records. But, again, I 
haven't seen it happen.

--
Jan-Pieter Cornet
"Any sufficiently advanced incompetence is indistinguishable from malice."
- Grey's Law



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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Franck Martin via mailop]

Hi,

I checked it way back, and nearly all the cases were due to configuration 
errors on the sender part.

It is not a feature that is actively used in the wild. I don’t know of any 
email client that allows you to do that. So someone needs to craft a specific 
message and inject it.

Now, when DMARC was brought in, having 2 different domains in the RFC 5322 
from: does not allow DMARC to function. Technically, DMARC can work if all the 
domains in the RFC5322 from are the same, but I guess it is just easier to 
reject such message as the impact is close to zero and often multiple From is 
just a strong signal of badness/spam.

If you know of an active useful use case, I’m curious.

From: mailop  on behalf of Alessandro Vesely via 
mailop 
Date: Monday, December 13, 2021 at 09:23
To: mailop 
Subject: [mailop] Gmail rejects multiple From:'s. Who else?
Hi,

I assume everybody knows that RFC 5322 allows multiple mailboxes in the From: 
field.  This feature existed in RFC822 already.  I think it is to be used for 
those cases where multiple persons are authoring a message, albeit adding the 
list of coauthors is usually not done.  This message is an example.  How many 
rejects does it yield?

Gmail reacts like so:

Action: failed
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with multiple 
addresses in From:
 550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp


Is it customary to reject messages with multiple addresses in From:?  Why?


Best
Ale
--






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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Slavko via mailop]

Hi,

Dňa Mon, 13 Dec 2021 18:19:07 +0100 Alessandro Vesely via mailop
 napísal:

> Is it customary to reject messages with multiple addresses in From:?
> Why?

AFAIK, DMARC works with only one From: address, thus sites which
are verifying DMARC tends to reject multiple addresses in it.

regards

-- 
Slavko
https://www.slavino.sk


pgpxlHNecMD6g.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Alexey Shpakovsky via mailop]

On Mon, December 13, 2021 17:56, Alessandro Vesely via mailop wrote:
> Are there still so many MUAs
> with no DKIM add-on?  Or is it because people is not free to install them?

Maybe they don't prioritize DKIM over other MUA features. Personally I
have a friend who uses Gmail on his phone, which doesn't show him DKIM
verification results (although Gmail server adds a relevant header), so he
asks everyone to send S/MIME-signed messages to him.

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

[mailop] Gmail rejects multiple From:'s. Who else?

[Alessandro Vesely via mailop]

Hi,

I assume everybody knows that RFC 5322 allows multiple mailboxes in the From: 
field.  This feature existed in RFC822 already.  I think it is to be used for 
those cases where multiple persons are authoring a message, albeit adding the 
list of coauthors is usually not done.  This message is an example.  How many 
rejects does it yield?

Gmail reacts like so:

Action: failed
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with multiple 
addresses in From:
550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp


Is it customary to reject messages with multiple addresses in From:?  Why?


Best
Ale
--






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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Alessandro Vesely via mailop]

On Sun 12/Dec/2021 00:33:12 +0100 Sebastian Nielsen via mailop wrote:


An user scanning such a QR code, would then look at phone screen, and then look 
on computer screen.



Note that to validate the message, the app needs access to not only the signed 
header fields, but also the body, that the value of bh= is based upon.




I do agree that email clients should do DKIM validation, but getting every email client 
to do DKIM validation is a pretty tricky part. If the client software and receiving 
server can be left out of equation, then this could appear as apps in app-store where you 
easily can download a "DKIM-QR validator" like you can download a covidpass 
scanner from app store today, and if this gets traction enough, the feature would get 
implemented in phone's native cameras like Samsung has.



As a user of a Nokia 2760, I'm astonished and amused by this idea that 
smartphones apps (IPhone, Android, Pinephone, ...) can implement new standards 
more easily and faster than PCs (and servers).  Are there still so many MUAs 
with no DKIM add-on?  Or is it because people is not free to install them?



Best
Ale
--





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

[mailop] scarlet.be contact ?

[Pascal HOARAU via mailop]

Hello,


We've some issues delivering to Scarlet.
Is there anyone from there on here or anyone have suggestions on how to reach 
them?

The abuse mailbox (ab...@scarlet.biz) does not work.
The online support answered they need a customer number and the message asked 
to reply to no_re...@scarlet.be (...)

Thanks !

Regards,
Pascal

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