mail loss / dump at mx.google.com

The situation: I did some travel booking via an internet travel agency. They are basically reachable by e-mail (telephony is rather difficult).

Three weeks ago I got mail from them concerning a reservation change, and I wrote back with the requested feedback.
Yesterday I got mail from them that they utterly expect my feedback (which obviousely hadn't reached them). I wrote again.

Today I thought, for safety I should undergo the hazzle and call them by phone. It came out that neither of the two mails had reached them..

So I checked back with my mail provider, and he gave me the log entries for both of the mails. They had been delivered to aspmx.l.google.com with dsn=2.0.0, state=Sent (OK).

So, according to the rules, the next step would be to interrogate the postmaster of that aspmx.l.google.com shop, and get him figure out what has happened.
(That the mails were considered spam is not an option, because they carried a proper References: header with the MsgId of the agency's original mail.)

Now the bad thing is, that aspmx.l.google.com dump doesn't even have a postmaster! Mails to there come back as "nonexistent user", and, to add insult to incompetence, they point to this webpage for help: https://support.google.com/mail/answer/6596

So, they appear to throw away mails, and don't have anybody responsible for their mail server. :(
Anybody knowing a way to reach them?
 
Yes, trev, this would -formally- be the last resort. But this should lead to somebody responsible for the domain/DNS service (and probably IP routing. AutonomousSystem management, and all that stuff). That's not actually E-Mail - E-Mail is a separate service and can (and does!) connect to systems that do not even have Internet.

So, I do expect if somebody operates a public mail exchange, that they have someone who is reachable and responsible for that service. And traditionally that is the postmaster.
And if a mail exchange does not have a postmaster, then that is, per definition, an unmaintained mail exchange.

BTW: I think it was in this forum where people asked how to set up a mail server, and other people answered that this is not so easy a task, and why not just pay of an offered mail service and let other people do the work.

Well then, we begin to see the outcome of that: if a thing is run commercially, then a cost/benefit ratio applies. And that translates to: how much malfunction can we entertain until losses from customer reaction will eat up the money saved? And exactly that much malfunction will happen.
Or in other words: one will rather invest in advertising than in proper engineering.
 
you could test mail flow .. unfortunately there's not enough info to determine why ..

drill aspmx.l.google.com
should resolve to A 74.125.195.26

telnet 74.125.195.26 25
Trying 74.125.142.26...
Connected to ie-in-f26.1e100.net.
Escape character is '^]'.
220 mx.google.com ESMTP x19si3744323pll.406 - gsmtp
helo localhost
rcpt to: test@domain.com. (use the original email address) this is the envelope to
(if it fails right here, then the user does not exist as a valid recipient). if you get a blank line .. continue
DATA
subject: test message
from: sanata@thenorthpole.com (can use your own email, but its the DATA from so doesn't really matter)
<press enter>
this is a test message from santa
<blank line>
.<enter>

should say message sent or message failed..
as a general rule
if sent then the email box exists and the message was delivered.. if it errors out, chances are your ip has some sort of reputation issue or some other specific reason your connection was dropped.

My guess is the original message you replied to was either generated by an account with no smtp address (like a bulk mail, or some process on their web site) or delivered by a 3rd party such as mailchimp where they stuff email addys into .. it's not uncommon for companies to use auto generated emails and in some cases configure it incorrectly or create a reply to that doesn't exist .. etc

another thing, if you have the original message headers.. verify the path
look for received by: towards the top of the headers.. go down to the last one, and work your way back up to the top.

BTW: I think it was in this forum where people asked how to set up a mail server, and other people answered that this is not so easy a task, and why not just pay of an offered mail service and let other people do the work.

email is the most f*cked up service .. there are to many people that have no idea what they are doing and should never ever attempt to set up an email server ... as a general rule this comment is more to protect people from themselves .. its real easy to get yourself blacklisted, or added to a botnet, or used to relay spam or deliver malware ...
 
you could test mail flow .. unfortunately there's not enough info to determine why ..

Yessir! :), I did this, rightaway when I had that TravelShop on the line, they asked if I had a second mailaddy, so I gave them an address on my jail with fixed IP. Their mail came in, and my answer reached them immediately (even although it carried lots of crap headers since mail's not currently configured on that jail).
So I'm essantially able to send mail to them, and they are able to receive mails - only something in the channel seems to drop/loose some of the mails.

I guess your messages are in Spam folder of agency and they do not check it.

I'd say that's quite possible and wouldn't surprise me.
Then the question is what kind of contract they have, and who would then be responsible for spam detection. This is not just a user having a google mail account via web - it's a company, so they would have some kind of SLA about who is doing what.
I don't care about such business crap, but if I were to have a shop, and the main communcation channel to my customers were E-mail, then I would do a good deal in caring about how that channel works, because I'm dependent on my customers reaching me.

And, if that spam detector -whoever may operate it- creates a false positive on a mail which is a reply to their outgoing correspondence, carries the proper "Re: " subject, carries the filekey for the booking in the subject, has proper References: and In-Reply-To: headers, well, then it's quite broken. Wouldn't surprize me either, have seen all kind of things...
 
More fun here:

telnet 74.125.195.26 25
Trying 74.125.142.26...
Connected to ie-in-f26.1e100.net.
Escape character is '^]'.
220 mx.google.com ESMTP x19si3744323pll.406 - gsmtp[/cmd]

RFC 5321:
Note: all the greeting-type replies have the official name (the
fully-qualified primary domain name) of the server host as the first
word following the reply code. Sometimes the host will have no
meaningful name. See Section 4.1.3 for a discussion of alternatives
in these situations.

In this case the host certainly does have a meaningful domain name. But "mx.google.com" isn't that name; it is something that doesn't even exist.

RFC 5321 is still absolutely strict about the postmaster requirement - no exceptions there, except not receiving mails at all. And I tried to reach a postmaster @mx.google.com (which is no host address at all, of any kind) and @aspmx.l.google.com (which is the hostname targeted by the MX record). The first was unparseable, the second came back after a while as nonexistent user.
RFC 5321 says:
Any system that includes an SMTP server supporting mail relaying or
delivery MUST support the reserved mailbox "postmaster" as a case-
insensitive local name. This postmaster address is not strictly
necessary if the server always returns 554 on connection opening (as
described in Section 3.1). The requirement to accept mail for
postmaster implies that RCPT commands that specify a mailbox for
postmaster at any of the domains for which the SMTP server provides
mail service, as well as the special case of "RCPT TO:<Postmaster>"
(with no domain specification), MUST be supported.
 
unfortunately your quotes are not quite what your thinking ..

the mta banner only needs to exist .. it doesn't have to even be resolve, however if it doesn't .. most mtas will automatically drop the connection.. in googles case they have literally thousands of MTA's all sharing the same mx names .. then they host the dns with the elastic ips so they resolve properly.. this is quite normal .. you will never see a google mta hostname.

the second part about postmaster is a little more obscure ... it is true that "a" postmaster account must exist.. but the account only needs to exist as a "service" account to the MTA
it could be anything you like.. by default its been postmaster for like the last 30 years..

the "postmaster" account does not need to accept mail, it only needs to be able to send mail for the purpose of bouncing mail that is not deliverable, returning mail that has expired from a mail queue or generate emails for the service itself. applications like exchange automatically create mailboxes and rules for a postmaster account..

in your case the "best" case scenario would be to have the entire verbose message log from end to end.. with the very last line saying as you already posted .. "250 sent". there should be an ip address after that .. it looks like you originally posted that...

all that means the message left your isp, was delivered to google, and google passed it off to whatever that ip address downstream was .. if that's the IP/domain you sent the mail to.. then 6502's assumption that they destroyed your message is probably correct .. that could be for a number of reasons such as.... misconfigured spam device, an undeliverable mailbox, outlook or exchange rules .. or even something like the address is not routable .. etc..
 
unfortunately your quotes are not quite what your thinking ..

the mta banner only needs to exist .. it doesn't have to even be resolve, however if it doesn't .. most mtas will automatically drop the connection..

Alright, the only thing that must be sent is the 220 and a space, that should suffice. But if there is a name following, that should be a valid domain name.

the second part about postmaster is a little more obscure ... it is true that "a" postmaster account must exist.. but the account only needs to exist as a "service" account to the MTA
it could be anything you like.. by default its been postmaster for like the last 30 years..

I don't read that. I read that the literal string "postmaster", in upper or lowercase, is required to be a reachable mailbox. The only other option is to not operate SMTP.

the "postmaster" account does not need to accept mail, it only needs to be able to send mail for the purpose of bouncing mail that is not deliverable, returning mail that has expired from a mail queue or generate emails for the service itself.

Sorry, no. This is done by the "mailer-daemon" user, on regular instances of sendmail (i.e. FreeBSD, so just try it out), and even by Google. The 'Postmaster' user is there to receive these notices of failed mails (and act upon them).

applications like exchange automatically create mailboxes and rules for a postmaster account..

Eh, that doesn't parse: exchange with what applications?

in your case the "best" case scenario would be to have the entire verbose message log from end to end.. with the very last line saying as you already posted .. "250 sent". there should be an ip address after that .. it looks like you originally posted that...

all that means the message left your isp, was delivered to google, and google passed it off to whatever that ip address downstream was ..

I don't know what google does or have. It appears to me (just assumptions) that this aspmx.l.google.com is the mailserver for a business mail exchange offering (probably cloud). How this might work, if the mail is then forwarded to the customer's premises and further processed there, or if the customer just gets web access to some cloud MUA, I have no idea. It is certainly all virtualized, but that doesn't concern me, because that does not make a logical difference.
In the end the relevant question simply is: do we have reliable mail services, or is mail delivery a matter of luck?

And concerning the verbose message log: every sendmailer does that by default; You find Yours in /var/log/maillog. Just like every webserver access is usually fully logged, every transferred mail is fully logged.
 
In the end the relevant question simply is: do we have reliable mail services, or is mail delivery a matter of luck?

I have run into so many misconfigured mail/DNS servers (including eg large multi-national insurance companies, many third-party service companies and even a web host) that mail delivery is indeed sometimes a matter of luck. That said, in the vast majority of cases mail delivery just works as intended.
 
Then the question is what kind of contract they have, and who would then be responsible for spam detection. This is not just a user having a google mail account via web - it's a company, so they would have some kind of SLA about who is doing what.
I used to work for a company, which got 50 business email accounts from Google at the time when they were generously giving out such business packages for free. That company is still using it. There is NO responsible person, they just use those accounts as regular personal gmail accounts. Some users may not even know about Spam folder since it's "hidden" somewhere down the left pane's list.
 
I used to work for a company, which got 50 business email accounts from Google at the time when they were generously giving out such business packages for free. That company is still using it. There is NO responsible person, they just use those accounts as regular personal gmail accounts. Some users may not even know about Spam folder since it's "hidden" somewhere down the left pane's list.

Ah, thanks for that info. Lets try and digest that: 1) the "business package" is basically just a kind of web mail account like the popular one (probably with some added features and functions). 2) There is probably some feature to administer the bunch, but somebody at the customer's would need to do that. 3) The customer believes that they have no work with mail and need no skill for mail because that's what they're buying (instead of investing in it themselves). 4) Google only provides automation, which reaches only so far as they have bothered to understand the RFC in order to implement ist (which usually translates to: not very far).

It appears to me that most of the internet business works on the premise that those who have a limited understanding of the technology make money off those who have even less clue.
 
There is probably some feature to administer the bunch, but somebody at the customer's would need to do that.
Sure! I also have such Google account (although don't use it on regular basis). There are many tools for administering in their web-GUI.

I can describe even a worse scenario. I know several people running small businesses, who get a domain name and simply set up email forwarding from such business account to their personal account: me@mycoolbusiness.com -> name.surname@gmail.com. Although e.g. Google and GoDaddy provide a possibility to forward detected spam, it's not obvious for inexperienced users how to do that. Other providers (e.g. Yandex) don't even have such possibility. So, the detected spam remains in their business account and they don't bother to check it from time to time. They think that their Outlook/Thunderbird's Spam/Junk folders capture all spam.
 
Back
Top