Re: A bit off-topic: problems with sending to a Gmail user
On Sat, Mar 12, 2022 at 12:09:01PM +0100, Matthias Apitz wrote: > El día sábado, marzo 12, 2022 a las 10:05:35 +0100, Joerg Dorchain > escribió: > > > Let's go through that: > > > > - An SPF-entry has to be created in the unixarea.de domain, I would assume > > you can do that via the > > interface of 1blu.de > > > > - DKIM-headers can be inserted locally. If you do that with a selector > > under the unixarea.de domain, you > > have to add the corresponding key in the zone. I would assume you can do > > that via the interface of 1blu.de > > Alternatively dkim can be implemented at the 1blu.de MTA, which in turn > > is solely at their discretion. > > > > - Same for a DMARC-entry. > > > > This would make most sense when you enable DNSSEC for the unixarea.de > > domain. Check here: > > https://dnsviz.net/d/unixarea.de/dnssec/ I would assume you can do that via > > the interface of 1blu.de. > > > > Joerg, 1blu is a German ISP where I have rented: > > - a domain 'unixare.de' > - a web space www.unixarea.de on some of its servers > - a mail addr g...@unixarea.de which ends up in mbox on its servers and I can > read mail with IMAP or some webmail software; and I can send mail with > SMTP to one its MTA (smt.1blu.de) > - SSH access to an unpriv account on the server to put/get files to/from > the web space www.unixarea.de > > I have no access to any DNS configurations and so I do not see how to > follow your hints. That then sounds like talking to their support and eventually reconsidering your position to 1blu or gmail. You are definitivly not the only one having problems with mail from or to gmail accounts. Bye, Joerg signature.asc Description: PGP signature
Re: A bit off-topic: problems with sending to a Gmail user
On Sat, Mar 12, 2022 at 09:03:37AM +0100, Matthias Apitz wrote: > > > > I've been seeing a lot of that lately. Google seem to have tightened > > > their email security practice recently. > > > > > > It appears that 1blu is doing something that GMail doesn't like. They > > > probably have a number of users who have the same problem. I would > > > ask them to check their MTA configuration against the section "Make > > > sure your messages are authenticated" in the referenced page > > > (https://support.google.com/mail/answer/81126#authentication). > > > > > > > 550-5.7.26 This message does not have authentication information or > > > > fails to > > > > 550-5.7.26 pass authentication checks. To best protect our users > > > > from spam, the > > > > 550-5.7.26 message has been blocked. Please visit > > > > Authenticated in this context means, you don't have SPF / DKIM / DMARC set > > up. > > > > You can use this service: https://www.mail-tester.com to test your > > setup. It provices you an email address. Send an email to it > > and then your mail and server setup will be evaluated. > > Thank you, Stefan. > > I did such a test and the result can be seen here: > https://www.mail-tester.com/test-ahwup3i9z Let's go through that: - An SPF-entry has to be created in the unixarea.de domain, I would assume you can do that via the interface of 1blu.de - DKIM-headers can be inserted locally. If you do that with a selector under the unixarea.de domain, you have to add the corresponding key in the zone. I would assume you can do that via the interface of 1blu.de Alternatively dkim can be implemented at the 1blu.de MTA, which in turn is solely at their discretion. - Same for a DMARC-entry. This would make most sense when you enable DNSSEC for the unixarea.de domain. Check here: https://dnsviz.net/d/unixarea.de/dnssec/ I would assume you can do that via the interface of 1blu.de. Bye, Joerg signature.asc Description: PGP signature
Re: Using UTC time in Date header
On Sun, May 16, 2021 at 10:32:33AM +1000, raf wrote:
>
> When my workplace switched to office365 (all but me anyway),
> their emails started arriving with UTC date headers. So I
> wrote a procmail recipe to filter incoming emails through
> a little perl script to convert the date header to my timezone.
> it's attached. the local timezone is hardcoded (sorry) but
> can be changed as needed.
Something similiar, just with procmail/formail:
You need Gnu date for this, sorry non-Posix features used.
{
#time in seconds since the epoch (to be rethought before Jan 19 2038 03:14:08)
:0 hi
* ^Date:[ ]*(...?, )?\/[^,]*$
# this blank contains a space and a tab, and yes, there are
strange date: header out there
DATE=| date -d "$MATCH" +%s
# catch unparsable/missing dates
:0 hi
* DATE ?? ^$
DATE=| echo "0"
:0 fwhi
| formail -i "Date: `TZ=America/Los_Angeles date -d @$DATE -R`"
}
Just leave out TZ= to get your default timezone
HTH,
Joerg
signature.asc
Description: PGP signature
Re: Mutt stops showing mail contents
On Fri, Dec 18, 2020 at 02:35:07PM +0100, Josef Wolf wrote: > > On Fri, Dec 18, 2020 at 11:56:47PM +1100, raf wrote: > > On Fri, Dec 18, 2020 at 11:16:23AM +0100, Josef Wolf > > wrote: > > > > Mutt starts up as always and works as expected. But after some time, it > > > stops > > > to show mail contents. It still shows the sidebar with all existing > > > folders > > > and the list of messages in the current folder. But no message bodies or > > > attachments are shown at all. > > > > You might want to check /var/log/kern.log for I/O errors. > > Thanks for the hint, raf. > > I can't find any I/O errors in /var/log/*. Only some informational entries > from smartd to be found there. I had a similiar effect when for obscure reasons /tmp was not writeable. Bye, Joerg signature.asc Description: PGP signature
Re: sendmail in background?
On Sat, Jun 10, 2017 at 04:42:42AM +0800, Yubin Ruan wrote: > Hi mutt users, > > Hmm...do any of you have any solution for sending emails in background > without hanging up your mutt? I am getting annoyed by the delay coming with > mutt's default smtp. I would like to have a sendmail script that would queue > up my all my emails from mutt and send it at proper time and if it fails, it > will notify me with a failure status or failure messages. That sounds like you want to have a MTA which does queuing and is triggered by whatever (e.g. internet up) to run queues. sendmail can do that, but also exim, postfix,... uucp, too, for a honorable mention. Not sure if nullmailer does queueing. Bye, Joerg signature.asc Description: PGP signature
Re: decoding UTF-8
On Tue, Mar 15, 2016 at 01:23:37PM +0100, Gabriel Philippe wrote:
>
> Quite funny, I spent some time on it yesterday...
>
> This is rfc2047 encoding [1]. It can probably use other charsets (not
> only UTF-8).
>
> The best way I found is to pipe it through perl -MEncode -ne 'print
> encode("UTF8",decode("MIME-Header",$_))'. But if Ionel's explanation
> is correct, a simple regexp and base64 -d would be quicker. Don't
> hesitate to give us feedback. :)
Well, while at it with the (in-)famous swiss-army chainsaw, I
came to fixing a few more things on the subject:
$osubject = $subject;
$subject = decode('MIME-Header', $subject);
$subject =~ s/\[.*?\] +//g if @ARGV && $ARGV[0] eq '[]';
$subject =~ s/((Re(\^[2-9]|\[[2-9]\])?|AW|WG|Antw(ort)?)\.?:\s*)+/Re: /ig;
$subject = encode((($subject =~ /[\000-\037\200-\377]/)?'MIME-Q':'UTF8'),
$subject);
print "Subject: $subject\n";
print "X-Original-Subject: $osubject\n" if $subject ne $osubject;
Bye,
Joerg
signature.asc
Description: PGP signature
Re: Multipart MIME
On Mon, Nov 26, 2012 at 09:57:33AM +, Jamie Paul Griffin wrote:
Does anyone have or know of a perl or python script, or even a shell
script, that removes the multipart/(mixed|alternative| ... ) parts of
incoming mail and leaves or converts the message into plain text?
I have two scripts for that. Both are not perfect and sometimes
eat mails or attachments, esp. from MUAs with certain bugs
(specifically Apple mail, html, and attachments are a known
culprit)
The effect comes from inherently from the way is works, it parses
the mime-structures and recreates it, thereby not necessarily
groking all unknowns.
Bye,
Joerg
a) remove text/html part from maultipart/alternativ
# Clean MIME mails
:0 fhbw
* ^Content-Type:.*multipart/
# Apple mail attachment bug
* ! ^X-Mailer: Apple Mail
| fixmail.pl
#!/usr/bin/perl -w
#
# This is a mail filter. Takes multipart from STDIN, deletes
# superfluous MIME-parts and reduces multipart/alternative to
# singlepart, finally writes cleaned MIME mail to STDOUT.
#
# By Boris 'pi' Piwinger 3...@piology.org. Please let me know if you
# improve it or fix bugs.
#
# Based on tinnef.pl (there is not much left, though;-) by Gerd Knorr
# gkn...@berlinonline.de. Get it there: http://www.ch-open.ch/~cho13093/
#
# This code is public domain. It comes with absolutely no warranty.
# If it eats your mails for lunch, that's your problem. If you don't
# like this, don't use it.
#
# Best with Procmail, e.g.:
#
# # Clean MIME mails
# :0
# * ^Content-Type:.*multipart/
# {
# :0c:
# tmp/fixmail
# :0fhbw
# | fixmail.pl
# }
# Save the From line
my$from = STDIN;
# Create parser, we are being daring here (huge mails might cause problems)
use MIME::Parser;
my$done=;
my$parser=MIME::Parser-new;
$parser-output_to_core(1);
my$top=$parser-read(\*STDIN) or die Couldn't parse MIME stream.\n;
$top=analyze($top);
$top-head-add('X-pi-MIME-Parts-removed',$done) if $done;
$top-sync_headers(Length='COMPUTE');
# Print From line
print $from;
$top-print(\*STDOUT);
exit 0;
sub analyze {
my($body,$i)=(@_,0);
my($parts)=$body-{ME_Parts};
if ($body-mime_type eq multipart/alternative) {
# Reduce multipart/alternative
$i=-1;
$i++ until ($$parts[$i]-mime_type eq text/plain || $i==$#{$parts});
if ($$parts[$i]-mime_type eq text/plain) {
@$parts=@$parts[$i];
$done.= multipart/alternative;
}
} else {
# Kill superfluous junk:
# - text/x-vcard
# - application/x-pkcs7-signature
# - application/ms-tnef
# Recursion on multipart
while ($i=$#{$parts}) {
# try pkcs7 for a while (mutt supports it now)
# if ($$parts[$i]-mime_type =~
/(text\/x-vcard|application\/(?:x-pkcs7-signature|ms-tnef))/) {
if ($$parts[$i]-mime_type =~ /(text\/x-vcard|application\/(?:ms-tnef))/)
{
$done.= $1;
splice(@$parts,$i,1);
} elsif ($$parts[$i]-mime_type =~ /^multipart\//) {
$$parts[$i]=analyze($$parts[$i]);
$i++;
} else {$i++}
}
}
$body-{ME_Parts}=$parts;
if ($body-mime_type =~ /^multipart\/related/
$body-head-mime_attr(content-type.type) eq multipart/alternative)
{$body-head-mime_attr(content-type.type = text/plain)}
$body-make_singlepart if $body-parts==1;
return $body;
}
b) adds a plain/text part to html-only mails
# Add text/plain
:0 fhbw
* ^Content-Type:.*text/html
| addtext.pl
#!/usr/bin/perl -w
# This is a mail filter. Takes a mail from STDIN,
# adds a text/plain section to every text/html not in
# multipart/alternative, finally writes cleaned MIME mail to
# STDOUT.
#
# text/plain is generated by lynx -dump
#
# TODO: fix charset
#
# Inspired by fixmail.pl by Boris 'pi' Piwinger
# 3...@piology.org
#
# (c) Joerg Dorchain jo...@dorchain.net
# This code is public domain. It comes with absolutely no warranty.
# If it eats your mails for lunch, that's your problem. If you don't
# like this, don't use it.
#
# Best with Procmail, e.g.:
#
# # Add text/plain
# :0
# * ^Content-Type:.*text/html
# {
# :0c:
# tmp/addtext
# :0fhbw
# | addtext.pl
# }
use IPC::Run qw(run);
# Save the From line
my $from = STDIN;
# Create parser, we are being daring here (huge mails might cause
# problems)
use MIME::Parser;
my $done=;
my $parser=MIME::Parser-new;
$parser-output_to_core(1);
my $top=$parser-read(\*STDIN) or die Couldn't parse MIME stream.\n;
$top = analyse($top);
$top-head-add('X-JD-Mime-Part-added',$done) if $done;
$top-sync_headers(Length='COMPUTE');
# Print From line
print $from;
$top-print(\*STDOUT);
exit 0;
sub analyse {
my ($top) = (@_);
if ($top-is_multipart) {
my ($i,$ti,$hi);
my ($parts) = $top-{ME_Parts};
for($i = 0; $i $#{$parts}; $i++) {
if ($top-effective_type ne multipart/alternative) {
$$parts[$i] = analyse($$parts[$i]);
} else {
if ($$parts[$i]-effective_type eq text/plain) { $ti = $i; }
if ($$parts[$i]-effective_type eq text/html) { $hi = $i; }
}
}
if ($top
Re: mutt and not really read only mailboxes
On Thu, Aug 23, 2012 at 01:49:07PM -0500, Derek Martin wrote: Not really. You can't really fix this. If mutt can't lock the folder then other processes (e.g. the MDA) can change the contents out from under Mutt while it's reading the file, potentially resulting in an inconsistent state. Actually the MTA just appends to the file. It can get messy when a second mutt or so with write access changes the mbox more arbitrarily. But, there's probably not really any good reason to read mail from a read-only NFS mount, so just stop doing that, and your problem should go away. The main reason is to see non-text without IO-redirection. Readonly because I liked to try with least possible privileges. - Dot-locking is (or at least was, and may still be) unreliable over NFS - POSIX locking (i.e. fctnl()) is not. I know. From reading the source, I am more puzzled what is really happening. The mx_lock_file function tries fcntl first, and only if this fails tries dotlocking. fcntl()-locking works at least once upon startup. I'll do more debugging to get more insight into this. Bye, Joerg signature.asc Description: Digital signature
mutt and not really read only mailboxes
Hello, I have a setup where my MTA delivers mail to an mbox file, which then is in turn exported via nfs read only to the client where mutt is running. Main purpose of this construction is viewing certain attachments. While all this works fine the first time mutt is started, after a while there is the situation that new mail arrives, however the mutt instance with the read only filesystem does not notice. Would it be possible to make mutt check for changes to the mailbox, even when this is located on a read-only filesystem? Bye, Joerg signature.asc Description: Digital signature
Re: mutt and not really read only mailboxes
On Thu, Aug 23, 2012 at 10:28:35AM +0200, Christian Brabandt wrote: On Thu, August 23, 2012 08:53, Joerg Dorchain wrote: I have a setup where my MTA delivers mail to an mbox file, which then is in turn exported via nfs read only to the client where mutt is running. Main purpose of this construction is viewing certain attachments. While all this works fine the first time mutt is started, after a while there is the situation that new mail arrives, however the mutt instance with the read only filesystem does not notice. Would it be possible to make mutt check for changes to the mailbox, even when this is located on a read-only filesystem? Try the check_mbox_size option. Does not have any effects. The exported filesystem has relatime option set, which are correct according ls -lu. If just seems that mutt does not check for new mails at all when it considers a mailbox read only. Bye, Joerg signature.asc Description: Digital signature
Re: mutt and not really read only mailboxes
On Thu, Aug 23, 2012 at 11:39:25AM +0200, Joerg Dorchain wrote:
If just seems that mutt does not check for new mails at all when
it considers a mailbox read only.
I need to correct myself: With an strace, I see that mutt does a
stat() on the mbox file with every keypress while in the index
screen, the stat() returns the proper size and times.
However, it then forks the mutt_dotlock process, which fails
because it the filesystem with the mbox is readonly.
The source from mbox.c reads
if (mbox_lock_mailbox (ctx, 0, 0) == -1)
{
mutt_unblock_signals ();
/* we couldn't lock the mailbox, but nothing serious happened:
* probably the new mail arrived: no reason to wait till we can
* parse it: we'll get it on the next pass
*/
return (M_LOCKED);
}
Needless to say the assumption expressed in the comments does not
hold.
Would this finding justify a bug report?
A solution might be to add a special case for following readonly
mailboxes (both read only file and file on read only filesystem),
The rest of the logic in the check_mailbox function is correct
here.
The current workaround of exiting and restarting mutt seems quite
cumbersome to me.
Bye,
Joerg
signature.asc
Description: Digital signature
mailbox updates not followed on ro-nfs
Hello, I am wondering if it is possible to tell mutt to check for updates in mailboxes that are on a read-only nfs share. I have mutt 1.5.21-5 (debian testing) on machines which mounts /var/mail/ readonly via nfs4 from the server where /var/mail/mbox is updated. mutt detects that the mailbox is readonly and prevents any changes to it. However, it does not detect when there are changes by others to the mailbox, especially when new mail arrives. Is it possible to tell mutt somehow to regularly check for updates even for the read-only mailboxes? Bye, Joerg signature.asc Description: Digital signature
