[Mimedefang] Sendmail source (was Re: helo callback)
On Tue, 18 Nov 2014 14:51:14 -0500 "Dale Moore" wrote: > The routine in sendmail/srvrstmp.c where I suspect the bug > resides is a small 2800 lines long. Ah, you think it's 2800 lines long. Run it through the C preprocessor to expand all the horrible macros. The MILTER_REPLY macro alone is more than 60 lines long. Sendmail source code should be in a text book, in the "cautionary tales" chapter. :) Regards, David. (I guess I shouldn't complain that much... I do use it after all!) ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] helo callback
> Check the Sendmail source. It seems to me that the version I checked > (8.14.5) lets the HELO go by successfully even if the milter says not to. Yep. 8.14.9 still has the bug that I see first referenced back in 2004. The routine in sendmail/srvrstmp.c where I suspect the bug resides is a small 2800 lines long. I'll be happy to see what I can accomplish. Dale Moore ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] $Sender -> Return-Path
On Tue, 18 Nov 2014 12:01:27 +0100 Fredrik Pettai wrote: > It turns out that $Sender isn't the email address of From: header in > those cases, instead $Sender is set to the email address of the > Return-Path header. Strictly speaking, $Sender is whatever the other end used in the MAIL From:<...> SMTP command. MIMEDefang has worked this way since the very beginning. > I guess the question is if it's possible to avoid having Return-Path > ending up in $Sender, or if we should do the matching against > "$Sender" (or something else) in a different way? (We don't want to > put in all possible Return-Path email addresses in the $Sender > matching) You need to parse the headers yourself to pick out the From: header sender; you can open the file "./HEADERS" and pick out the address. Alternatively, I believe you can get the header with: $entity->head->get('From') where $entity is the top-level MIME entity passed to filter_begin or filter_end. To extract just the mail address and not any extraneous text on the From: line, you can use the Perl module Mail::Address which has a parse() method. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] $Sender -> Return-Path
On Nov 18, 2014, at 12:01 , Fredrik Pettai wrote: > > We noted that this filter function didn't work although both the criterias > seemed to be true. It turns out that $Sender isn't the email address of From: > header in those cases, instead $Sender is set to the email address of the > Return-Path header. Maybe this has always been the case, and we where just > lucky until now… Ok, I get it. $Sender is set to what comes from MAIL FROM: < … > command, nothing else. So we'll have to rewrite our filter to match at From: too… /P ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] $Sender -> Return-Path
Hi, We have a simple filter function that looks at $Sender (for a group senders addresses) and in the subject or body (for a specific word), and if both the criterias are true then the $Subject is altered (a prefix is added). sub filter { my($entity, $fname, $ext, $type) = @_; return if message_rejected(); # Avoid unnecessary work if ($Sender =~ /(\?|\?)/) { if ($Subject =~ /MATCHINGSTRING/i) { action_change_header('Subject', "[PREFIX]$Subject"); } else { my $io; if ($io = $entity->open("r")) { while (defined($_ = $io->getline)) { if (/MATCHINGSTRING/i) { action_change_header('Subject', "[PREFIX]$Subject"); last; } } $io->close; } } } return action_accept(); } We noted that this filter function didn't work although both the criterias seemed to be true. It turns out that $Sender isn't the email address of From: header in those cases, instead $Sender is set to the email address of the Return-Path header. Maybe this has always been the case, and we where just lucky until now… I guess the question is if it's possible to avoid having Return-Path ending up in $Sender, or if we should do the matching against "$Sender" (or something else) in a different way? (We don't want to put in all possible Return-Path email addresses in the $Sender matching) /P ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang