spf helo pass

[Peter]

On 1/01/22 9:57 pm, Benny Pedersen wrote:
> its basicly just statistik you say above

You seem to think you can just ARC sign the message and everything will 
be rosy.  This is not the case, ARC needs to be implemented on the 
receiver side or it will be completely ignored.  It will takes yeras for 
it to be widely adopted.

>> 1.  Check the inbound SPF, DKIM and DMARC and reject the mail if it
>> doesn't pass.
> 
> check spf helo, spf mfrom, check dkim, check arc in that order, but do 
> not reject, current its only meta data collected to dmarc policy with 
> can reject if sender wants it rejected, but this should relly not be 
> rejected if its arc-signed / arc-sealed, this indicate a maillist where 
> reject is not best way to solve spamming

Sure check for ARC as well.  The point is to reject anything that might 
be SPAM because you are going to be DKIM signing it yourself and you 
don't want to be forwarding SPAM.

>> 2.  Other anti-spam measures to try to absolutely minimize the amount
>> of SPAM that you end up forwarding.
> 
> its possible to unsubscribe

So you expect a spammer to unsubscribe?

> makes things worse
> makes things worse

And yet as I said, it's the only way to guarantee that the message will 
pass on the recipient side.  ARC won't do that.  I didn't say it was a 
great solution, I said it's the *only* solution.

>> 5.  Do any other alterations, such as adding list-* headers modifying
>> the Subject: header, etc.
> 
> does not break dkim when adding new headers, but change signed headers does

Wrong.  Adding headers *can* break dkim.  This is because the lack of 
headers or NULL headers can be signed.

>> 6.  DKIM sign the message from the domain you rewrote the From: header 
>> to.
> 
> perfect forged mail can be tested in dkim adsp

Which is why you check the original signature and reject if it doesn't pass.

>> 7.  Rewrite the envelope sender to your domain name.
> 
> normal for maillists, does not break spf specs

It's something that you have to explicitly tell your MTA to do, and it 
certainly wasn't "normal" before SPF was a thing.

>> 8.  Send out the message.
> 
> and hope for no spf helo, spf pass if its spam :)

Again, why you try to reject SPAM to begin with.

>> The above assumes properly implemented SPF, DKIM and DMARC records for
>> your domain.
> 
> define properly

I'm not going to go into that level of detail here.  There are many many 
resources on the internet which can tell you how to set up these thigns 
properly.

>> That is the *only* way you can be fully certain that the forwarded
>> message will pass SPF, DKIM and DMARC checks and therefore have the
>> best chances of being received by the recipient.  Anything else relies
>> on implementation specifics of the sender and/or the recipient MTAs
>> which may or may not make that possible.
> 
> you need more meta data on diffrent maillists if you write this above

Nope, this has nothing to do with the mail list.  This has to do with 
different practices of the sending MTA and recipient MTA.  The mail list 
sits in-between the two and must reconcile with various different 
policies of the sender (which can be determined) and how the recipient 
will check those policies (which generally cannot be determined).

> we are OFF Topic, take debate offline from maillist

By all means.  Just stop trying to claim that ARC will solve all the 
problems, it won't.  I realize that mailing lists likely do not want to 
implement all of the above steps, but ARC is not a magic bullet that can 
fix the issues shown, there is no magic bullet and so you either accept 
that a number of messages will, depending on circumstances, not make it 
to the recipient, or you take drastic measures to resign everything so 
that the recipient MTA is happy.


Peter