Re: [Discuss] Verizon blacklisted me
On August 9, 2014, Tom Metro wrote: Out of curiosity, do you have residential or business class service? Residential. Regardless, it sounds like it would be worth your while to boost the logging level on Postfix and see what is going on in the transaction. Thanks for the suggestion - will do. I also second Bill Bogstad's recommendation to do a sanity check by trying to relay mail through Verizon directly from a mainstream mail client, like Thunderbird. Thanks (to Bill as well). I just tried it with Thunderbird, which reports, Login to server smtp.verizon.net failed. -- Dan Barrett dbarr...@blazemonger.com ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Mailcheck not showing new mail
On 8/9/2014 11:06 PM, Tom Metro wrote: Bill Horne wrote: I'm calling mailcheck -cs from my login script... I presume this mailcheck: http://manpages.ubuntu.com/manpages/precise/man1/mailcheck.1.html (There seem to be several tools with that name.) That's the one. ...but it is reporting No new mail when it shouldn't be. You have new mail in /var/mail/moder8 moder8@telecom:~$ mailcheck -cs No new mail. My .mailcheckrc file has my home mailbox listed. The first message, presumably produced by 'mail', is reported on your spool file, not Maildirs in your home directory. You say .mailcheckrc specifies your home mailbox. What exactly do you mean by that? To match 'mail' I'd expect it to be: /var/mail/$(USER) It's /var/mail/moder8, which is the actual name, but it's in there. ... oops, wait: I just noticed that the file name is .mailcheckr. Home Simpson mode=on D-Oh! (Slaps head) /simpson Hey, just a sec: The result of running mailcheck -cs without a local .mailcheckrc is no new mail. when there is mail in the mailbox, and no output when the mailbox is empty. It *is* paying attention to the mail spool, albeit not in the way I want. What's up with that? Also check to see if /etc/mailcheckrc exists and see what it points to. (If it does not already, it should probably contain a path, as I show above, that matches the convention of where inboxes are stored on your system.) Another puzzle: on Ubuntu 14.04 LTS, it's all commented out. There is an entry that looks like #/var/spool/mail/$(USER) ( /var/spool/mail is a link to ../mail) ... but nothing actually enabled, for that or other options. (brief pause while Bill corrects short circuit in operator) Now, with a properly named .mailcheckrc file, it seems to do what it should. My question remains, though, why it would be able to tell the difference between a spool file with anything in it, or nothing in it, but not signal if the file has new mail? Bill -- E. William Horne William Warren Consulting 339-364-8487 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Mailcheck not showing new mail
Bill Horne wrote: The result of running mailcheck -cs without a local .mailcheckrc is no new mail. when there is mail in the mailbox, and no output when the mailbox is empty. It *is* paying attention to the mail spool, albeit not in the way I want. What's up with that? ...why it would be able to tell the difference between a spool file with anything in it, or nothing in it, but not signal if the file has new mail? With Maildir detecting new mail is simply a matter of looking for the presence of files in a 'new' subdirectory. If I recall, with mbox files the file has to be parsed and the headers of each message examined. There needs to be coordination between how the MUA marks messages as read and the mail checking tool. Maybe there is a disagreement between mailcheck and your MUA. The documentation on mailcheck seems sparse. It doesn't even state what the default behavior is if there are no config files. To understand what it is doing would require using strace and/or examining the source. (I'd try running strace -o/tmp/mailcheck ... then grep /tmp/mailcheck for /var to see what spool files it is accessing. If you spot an open() syscall, it'll return a file descriptor, and then you can look for subsequent syscalls (like read() and stat()) on that descriptor to see what it is doing with the file.) Also check to see if /etc/mailcheckrc exists and see what it points to. Another puzzle: on Ubuntu 14.04 LTS, it's all commented out. There is an entry that looks like #/var/spool/mail/$(USER) By convention, a commented out config line often will indicate the compiled-in defaults. (You can confirm that by running something like strings /usr/bin/mailcheck | fgrep /var and see if it spits out a similar looking path.) That would imply it should work as expected without altering /etc/mailcheckrc or adding an rc file. But you're saying you didn't get the expected behavior until you added /var/mail/moder8 to .mailcheckrc? -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Mailcheck not showing new mail
Bill Horne wrote:
The result of running mailcheck -cs without a local .mailcheckrc is
no new mail. when there is mail in the mailbox, and no output when the
mailbox is empty. It *is* paying attention to the mail spool, albeit not
in the way I want. What's up with that?
...why it would be able to tell the difference between a spool file
with anything in it, or nothing in it, but not signal if the file
has new mail?
With Maildir detecting new mail is simply a matter of looking for the
presence of files in a 'new' subdirectory. If I recall, with mbox
files the file has to be parsed and the headers of each message
examined. There needs to be coordination between how the MUA marks
messages as read and the mail checking tool. Maybe there is a
disagreement between mailcheck and your MUA.
The documentation on mailcheck seems sparse. It doesn't even state
what the default behavior is if there are no config files. To
understand what it is doing would require using strace and/or
examining the source.
(I'd try running strace -o/tmp/mailcheck ... then grep
/tmp/mailcheck for /var to see what spool files it is accessing. If
you spot an open() syscall, it'll return a file descriptor, and then
you can look for subsequent syscalls (like read() and stat()) on that
descriptor to see what it is doing with the file.)
Here's the output file after I renamed .mailcheckrc: /etc/mailcheckrc has only
comments.
execve(/usr/bin/mailcheck, [mailcheck], [/* 21 vars */]) = 0
brk(0) = 0x82c000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4dca743000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24081, ...}) = 0
mmap(NULL, 24081, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dca73d000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320\37\2\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0
mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f4dca15d000
mprotect(0x7f4dca319000, 2093056, PROT_NONE) = 0
mmap(0x7f4dca518000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7f4dca518000
mmap(0x7f4dca51e000, 17088, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dca51e000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4dca73c000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4dca73a000
arch_prctl(ARCH_SET_FS, 0x7f4dca73a740) = 0
mprotect(0x7f4dca518000, 16384, PROT_READ) = 0
mprotect(0x7f4dca745000, 4096, PROT_READ) = 0
munmap(0x7f4dca73d000, 24081) = 0
brk(0) = 0x82c000
brk(0x84d000) = 0x84d000
open(/home/moder8/.mailcheckrc, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/etc/mailcheckrc, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1446, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4dca742000
read(3, # mailcheckrc\tDefault configurat..., 4096) = 1446
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f4dca742000, 4096)= 0
exit_group(0) = ?
+++ exited with 0 +++
... and here's the output file after .mailcheckrc was restored:
execve(/usr/bin/mailcheck, [mailcheck], [/* 21 vars */]) = 0
brk(0) = 0x1643000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f19bdc0
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24081, ...}) = 0
mmap(NULL, 24081, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f19bdbfa000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320\37\2\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0
mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f19bd61a000
mprotect(0x7f19bd7d6000, 2093056, PROT_NONE) = 0
mmap(0x7f19bd9d5000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7f19bd9d5000
mmap(0x7f19bd9db000, 17088, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =
